Re: [PATCH 2/2] pidfd: add pidfdfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 20 May 2024 at 12:01, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> So how about just a patch like this?  It doesn't do anything
> *internally* to the inodes, but it fixes up what we expose to user
> level to make it look like lsof expects.

Note that the historical dname for those pidfs files was
"anon_inode:[pidfd]", and that patch still kept the inode number in
there, so now it's "anon_inode:[pidfd-XYZ]", but I think lsof is still
happy with that.

Somebody should check.

I also wrote some kind of tentative commit log for this:

    fs/pidfs: make 'lsof' happy with our inode changes

    pidfs started using much saner inodes in commit b28ddcc32d8f ("pidfs:
    convert to path_from_stashed() helper"), but that exposed the fact that
    lsof had some knowledge of just how odd our old anon_inode usage was.

    For example, legacy anon_inodes hadn't even initialized the inode type
    in the inode mode, so everything had a type of zero.

    So sane tools like 'stat' would report these files as "weird file", but
    'lsof' instead used that (together with the name of the link in proc) to
    notice that it's an anonymous inode, and used it to detect pidfd files.

    Let's keep our internal new sane inode model, but mask the file type
    bits at 'stat()' time in the getattr() function we already have, and by
    making the dentry name match what lsof expects too.

    This keeps our internal models sane, but should make user space see the
    same old odd behavior.

    Reported-by: Jiri Slaby <jirislaby@xxxxxxxxxx>
    Link: https://lore.kernel.org/all/a15b1050-4b52-4740-a122-a4d055c17f11@xxxxxxxxxx/
    Link: https://github.com/lsof-org/lsof/issues/317
    Cc: Christian Brauner <brauner@xxxxxxxxxx>
    Cc: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>
    Cc: Seth Forshee <sforshee@xxxxxxxxxx>
    Cc: Tycho Andersen <tycho@tycho.pizza>
    Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>

but I haven't actually committed it to my main tree, since I'd hope to
get Ack's for it (and testing).

Or does somebody have any other ideas? I think that patch is fairly
clean, even if the *reason* for the patch is odd as heck.

           Linus




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux