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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 16 Jun 2017 22:28:28 +0900
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Christoph Hellwig <hch@....de>
Cc:     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

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.

                    Linus