linux-kernel - Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor Identification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87fuesnax7.fsf@xmission.com>
Date:   Wed, 21 Jun 2017 19:06:12 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Christoph Hellwig <hch@....de>,
        Johannes Thumshirn <jthumshirn@...e.de>,
        Sagi Grimberg <sagi@...mberg.me>,
        Linux Kernel Mailinglist <linux-kernel@...r.kernel.org>,
        Linux NVMe Mailinglist <linux-nvme@...ts.infradead.org>,
        Keith Busch <keith.busch@...el.com>,
        Hannes Reinecke <hare@...e.de>,
        Max Gurtovoy <maxg@...lanox.com>
Subject: Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor Identification

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> On Fri, Jun 16, 2017 at 6:58 PM, Christoph Hellwig <hch@....de> wrote:
>> On Fri, Jun 16, 2017 at 11:48:32AM +0200, Johannes Thumshirn wrote:
>>> >
>>> > Yeah, it's actually there, but for some reason find on sysfs
>>> > behaves strange:
>>> >
>>> > root@...tvm:~# find /sys -name uuid
>>> > root@...tvm:~# cat /sys/class/nvme/nvme2/nvme2n1/uuid
>>> > 6665a65b-f42f-469b-800e-a047238649eb
>>>
>>> Wasn't there something that find on sysfs isn't reliable?
>>
>> Looks like it.  Which is a pitty.
>
> Hmm. The *traditional* reason for this particular 'find' oddity is
> that find has an optimization which will look at the nlink count of a
> directory to decide how many subdirectories it can have.
>
> So when 'find' then traverses the directory tree, once it has found
> all the subdirectories it expects, it will stop traversing any further
> subdirectories.
>
> The reason for this is that it can then avoid doing the 'lstat()' on
> each directory entry to even figure out what kind of file it is (ie
> directory vs regular file etc). I forget the exact rules, but it
> basically depends on nlink being "2+umber of subdirectories". I wonder
> if the sysfs code gets this wrong for some cases.
>
> All the directories I have on the laptop I'm on right now get it
> right, but maybe nvme triggers something.
>
> You can check with some silly shell scripts, and do things like
>
>     stat -c %h /sys/class/nvme
>
> and then compare that to the number of subdirectories (the link count
> should be 2 higher - the parent entry and the '.' entry).
>
> The traditional *fix* for this is to just set "nlink" to 1 for a
> directory, which tells 'find' to not use this optimization. That's
> what filesystems like VFAT do, that don't count subdirectories. But
> sysfs should get the directory count right.
>
> I can't imagine any other reason why 'find' would screw up.

Definitely worth looking at.

There is only one code path for that in kernfs/sysfs so I don't think
you can mess that up.

I suspect find is getting confused by something more subtle.  Perhaps a
symlink.  /sys/class/nvme/ ought to be be filled with symlinks to other
locations in sysfs.  Which could be part of the challenge.

Perhaps find /sys/ behaves differently than find /sys..

It might be worth running "find /sys | grep uuid" and see if your file
turns up.

After the work I did cleaning up sysfs to support network namespaces
find really ought to work properly on sysfs.  inotify is likely to have
problems but find should work.

Eric