Bug 211605

That's not the right fix ;) but thanks for the bug report, looks like this was an oversight when attr2/noattr2 were deprecated, we'll get it fixed up.

On Sun, Feb 07, 2021 at 05:06:36AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=211605
> 
>             Bug ID: 211605
>            Summary: Re-mount XFS causes "noattr2 mount option is
>                     deprecated" warning
>            Product: File System
>            Version: 2.5
>     Kernel Version: 5.10.13
>           Hardware: All
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: low
>           Priority: P1
>          Component: XFS
>           Assignee: filesystem_xfs@kernel-bugs.kernel.org
>           Reporter: cuihao.leo@gmail.com
>         Regression: No
> 
> Created attachment 295103 [details]
>   --> https://bugzilla.kernel.org/attachment.cgi?id=295103&action=edit
> proposed fix
> 
> After recent kernel update, I notice "XFS: noattr2 mount option is
> deprecated."
> kernel message every time I shutdown the system. It turns out that remounting
> a
> XFS causes the warning.
> 
> Steps to Reproduce:
> 1) Mount a XFS and remount it with different options:
> > $ mount some_xfs.img /mnt/test
> > $ mount -o remount,ro /mnt/test
> 2) Check kernel message. Remounting causes a line of warning:
> > XFS: noattr2 mount option is deprecated.

That sounds like a mount(1) bug, not a kernel bug. Something is
adding the "noattr2" option to the remount line. Running you test
on my system doesn't show that warning. I'm running a 5.11-rc5 kernel
and:

$ mount -V
mount from util-linux 2.36 (libmount 2.36.0: selinux, smack, btrfs, namespaces, assert, debug)
$

And there is no such "noattr2 is deprecated" output. What version of
mount are you running?

What we really need from your system is debug that tells us exactly
what the mount option string that the mount command is handing the
mount syscall.

> I had checked my fstab and kernel params and didn't found any use of "attr2"
> option. It doesn't break things, but is a little confusing.

"attr2" != "noattr2"

The kernel is warning about a mount option being specified that
isn't even in the set emitted in /proc/mounts. Nor is it on your
command line. Yet the kernel is warning about it, and that implies
that mount has passed it to the kernel incorrectly.

Cheers,

Dave.

I think we do have a buglet here, but I can't explain how you are getting "noattr2"

Can you rerun the test with more info, i.e.:

$ mount -V
$ mount some_xfs.img /mnt/test
$ grep /mnt/test /proc/mounts
$ strace -emount -v mount -o remount,ro /mnt/test

so we can see the mount version, the contents of /proc/mounts, and what gets sent to the mount syscall?

On 2/7/21 4:15 PM, Dave Chinner wrote:
> On Sun, Feb 07, 2021 at 05:06:36AM +0000, bugzilla-daemon@bugzilla.kernel.org
> wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=211605
>>
>>             Bug ID: 211605
>>            Summary: Re-mount XFS causes "noattr2 mount option is
>>                     deprecated" warning
>>            Product: File System
>>            Version: 2.5
>>     Kernel Version: 5.10.13
>>           Hardware: All
>>                 OS: Linux
>>               Tree: Mainline
>>             Status: NEW
>>           Severity: low
>>           Priority: P1
>>          Component: XFS
>>           Assignee: filesystem_xfs@kernel-bugs.kernel.org
>>           Reporter: cuihao.leo@gmail.com
>>         Regression: No
>>
...

> The kernel is warning about a mount option being specified that
> isn't even in the set emitted in /proc/mounts. Nor is it on your
> command line. Yet the kernel is warning about it, and that implies
> that mount has passed it to the kernel incorrectly.

I am confused about how "noattr2" showed up.

But we do still emit "attr2" in /proc/mounts, and a remount will complain
about /that/, so we do need to stop emitting deprecated options in /proc/mounts.

# mount /dev/pmem0p1 /mnt/test
# grep pmem /proc/mounts 
/dev/pmem0p1 /mnt/test xfs rw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0
# mount -o remount,ro /mnt/test
# dmesg | tail -n 1
[346311.064017] XFS: attr2 mount option is deprecated.

Pavel, can you fix this up, since your patch did the deprecations? I guess we
missed this on review.

Ideally the xfs(5) man page in xfsprogs should be updated as well to reflect the
deprecated items.


-Eric

Sorry guys. I realized that I copy the wrong line of kernel message...

I meant to say I got "attr2 mount option is deprecated" warning when "attr2" option is nowhere used...
not "noattr2"... "noattr2" one is only triggered when I was doing more tests.



More information about my mount command. I am using Arch Linux's stock one:
$ mount -V
mount from util-linux 2.36.1 (libmount 2.36.1: btrfs, namespaces, assert, debug)
$ pacman -Q util-linux 
util-linux 2.36.1-4

On Sun, Feb 07, 2021 at 04:53:34PM -0600, Eric Sandeen wrote:
> On 2/7/21 4:15 PM, Dave Chinner wrote:
> > On Sun, Feb 07, 2021 at 05:06:36AM +0000,
> bugzilla-daemon@bugzilla.kernel.org wrote:
> >> https://bugzilla.kernel.org/show_bug.cgi?id=211605
> >>
> >>             Bug ID: 211605
> >>            Summary: Re-mount XFS causes "noattr2 mount option is
> >>                     deprecated" warning
> >>            Product: File System
> >>            Version: 2.5
> >>     Kernel Version: 5.10.13
> >>           Hardware: All
> >>                 OS: Linux
> >>               Tree: Mainline
> >>             Status: NEW
> >>           Severity: low
> >>           Priority: P1
> >>          Component: XFS
> >>           Assignee: filesystem_xfs@kernel-bugs.kernel.org
> >>           Reporter: cuihao.leo@gmail.com
> >>         Regression: No
> >>
> ...
> 
> > The kernel is warning about a mount option being specified that
> > isn't even in the set emitted in /proc/mounts. Nor is it on your
> > command line. Yet the kernel is warning about it, and that implies
> > that mount has passed it to the kernel incorrectly.
> 
> I am confused about how "noattr2" showed up.
> 
> But we do still emit "attr2" in /proc/mounts, and a remount will complain
> about /that/, so we do need to stop emitting deprecated options in
> /proc/mounts.

No, it does not warn on my systems about attr2, either. Like I said,
there are no warnings on remount at all because mount it not passing
the /proc/mounts information back into the kernel:

# strace -emount -v mount -o remount,ro /mnt/scratch
mount("/dev/vdc", "/mnt/scratch", 0x561f3b93c690, MS_RDONLY|MS_REMOUNT, NULL) = 0
#

This really looks like a mount version/distro issue, not a kernel
issue...

Cheers,

Dave.

On 2/7/21 4:53 PM, Eric Sandeen wrote:
> 
> Pavel, can you fix this up, since your patch did the deprecations? I guess we
> missed this on review.

Scratch that, Dave points out that they need to stay until they are removed.
 
> Ideally the xfs(5) man page in xfsprogs should be updated as well to reflect
> the
> deprecated items.

man page probably should still be updated tho (unless I missed a patch...)

-Eric

I have the same issue. I am using Arch Linux too.

Even if I do not use "defaults" for xfs in /etc/fstab I still find the attr2 mount option in /proc/mounts:

fstab:
UUID=xxx-xxx-xxx / xfs  rw,noatime,inode64,logbufs=8,logbsize=32k,noquota 0 1

/proc/mounts:
/dev/nvme0n1p2 / xfs rw,noatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0

Having "attr2" in /proc/mounts is OK. We will have a fix to suppress the warning on remount.

Hello,

upstream kernel now contains following commits:

92cf7d36384b9 xfs: Skip repetitive warnings about mount options
0f98b4ece18da xfs: rename variable mp to parsing_mp

This should fix the reported problem. Can we close the bug now?

Yep!

I have the same issue.

Kernel in use: 5.11.0-17-generic
O.S.: Lubuntu 21.04

fstab file:
UUID=xxxx-xxxx                            /boot/efi      vfat    umask=0077 0 2
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx swap           swap    defaults   0 0
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /              xfs     defaults   0 1
/swapfile                                 swap           swap    defaults   0 0
LABEL=Crucial2,5" /mnt/Crucial2,5" auto nosuid,nodev,nofail,x-gvfs-show 0 0

What's the current status of this bug?

Hi Victor,

I'm not sure I follow - but as you can see the bug status is: 'RESOLVED CODE_FIX' and the fix is in upstream tag v5.13-rc1 .