<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in internal.h</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>93fd0d46 - vfs: Remove invalidate_inodes()</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#93fd0d46</link>
        <description>vfs: Remove invalidate_inodes()The function can be replaced by evict_inodes. The only difference isthat evict_inodes() skips the inodes with positive refcount withouttouching -&gt;i_lock, but they are equivalent as evict_inodes() repeats therefcount check after having grabbed -&gt;i_lock.Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;Link: https://lore.kernel.org/r/20250307144318.28120-2-jack@suse.czSigned-off-by: Christian Brauner &lt;brauner@kernel.org&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Fri, 07 Mar 2025 14:43:19 +0000</pubDate>
        <dc:creator>Jan Kara &lt;jack@suse.cz&gt;</dc:creator>
    </item>
<item>
        <title>e8358845 - file: add fput and file_ref_put routines optimized for use when closing a fd</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#e8358845</link>
        <description>file: add fput and file_ref_put routines optimized for use when closing a fdVast majority of the time closing a file descriptor also operates on thelast reference, where a regular fput usage will result in 2 atomics.This can be changed to only suffer 1.See commentary above file_ref_put_close() for more information.Signed-off-by: Mateusz Guzik &lt;mjguzik@gmail.com&gt;Link: https://lore.kernel.org/r/20250305123644.554845-2-mjguzik@gmail.comSigned-off-by: Christian Brauner &lt;brauner@kernel.org&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Wed, 05 Mar 2025 12:36:41 +0000</pubDate>
        <dc:creator>Mateusz Guzik &lt;mjguzik@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>45135229 - pidfs: record exit code and cgroupid at exit</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#45135229</link>
        <description>pidfs: record exit code and cgroupid at exitRecord the exit code and cgroupid in release_task() and stash in structpidfs_exit_info so it can be retrieved even after the task has beenreaped.Link: https://lore.kernel.org/r/20250305-work-pidfs-kill_on_last_close-v3-5-c8c3d8361705@kernel.orgReviewed-by: Jeff Layton &lt;jlayton@kernel.org&gt;Reviewed-by: Oleg Nesterov &lt;oleg@redhat.com&gt;Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Wed, 05 Mar 2025 10:08:15 +0000</pubDate>
        <dc:creator>Christian Brauner &lt;brauner@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>da06e3c5 - fs: don&apos;t needlessly acquire f_lock</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#da06e3c5</link>
        <description>fs: don&apos;t needlessly acquire f_lockBefore 2011 there was no meaningful synchronization betweenread/readdir/write/seek. Only in commitef3d0fd27e90 (&quot;vfs: do (nearly) lockless generic_file_llseek&quot;)synchronization was added for SEEK_CUR by taking f_lock aroundvfs_setpos().Then in 2014 full synchronization between read/readdir/write/seek wasadded in commit 9c225f2655e3 (&quot;vfs: atomic f_pos accesses as per POSIX&quot;)by introducing f_pos_lock for regular files with FMODE_ATOMIC_POS andfor directories. At that point taking f_lock became unnecessary for suchfiles.So only acquire f_lock for SEEK_CUR if this isn&apos;t a file that would haveacquired f_pos_lock if necessary.Link: https://lore.kernel.org/r/20250207-daten-mahlzeit-99d2079864fb@braunerSigned-off-by: Christian Brauner &lt;brauner@kernel.org&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Fri, 07 Feb 2025 14:10:33 +0000</pubDate>
        <dc:creator>Christian Brauner &lt;brauner@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>29d80d50 - open: Fix return type of several functions from long to int</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#29d80d50</link>
        <description>open: Fix return type of several functions from long to intFix the return type of several functions from long to int to match its actual behavior. These functions only return int values. This change improvestype consistency across the filesystem code and aligns the function signature with its existing implementation and usage.Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;Signed-off-by: Yuichiro Tsuji &lt;yuichtsu@amazon.com&gt;Link: https://lore.kernel.org/r/20250121070844.4413-2-yuichtsu@amazon.comSigned-off-by: Christian Brauner &lt;brauner@kernel.org&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Tue, 21 Jan 2025 07:08:22 +0000</pubDate>
        <dc:creator>Yuichiro Tsuji &lt;yuichtsu@amazon.com&gt;</dc:creator>
    </item>
<item>
        <title>37c4a959 - statmount: allow to retrieve idmappings</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#37c4a959</link>
        <description>statmount: allow to retrieve idmappingsThis adds the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP options.It allows the retrieval of idmappings via statmount().Currently it isn&apos;t possible to figure out what idmappings are applied toan idmapped mount. This information is often crucial. Before statmount()the only realistic options for an interface like this would have been toadd it to /proc/&lt;pid&gt;/fdinfo/&lt;nr&gt; or to expose it in/proc/&lt;pid&gt;/mountinfo. Both solution would have been pretty ugly andwould&apos;ve shown information that is of strong interest to someapplication but not all. statmount() is perfect for this.The idmappings applied to an idmapped mount are shown relative to thecaller&apos;s user namespace. This is the most useful solution that doesn&apos;trisk leaking information or confuse the caller.For example, an idmapped mount might have been created with thefollowing idmappings:    mount --bind -o X-mount.idmap=&quot;0:10000:1000 2000:2000:1 3000:3000:1&quot; /srv /optListing the idmappings through statmount() in the same context shows:    mnt_id:        2147485088    mnt_parent_id: 2147484816    fs_type:       btrfs    mnt_root:      /srv    mnt_point:     /opt    mnt_opts:      ssd,discard=async,space_cache=v2,subvolid=5,subvol=/    mnt_uidmap[0]: 0 10000 1000    mnt_uidmap[1]: 2000 2000 1    mnt_uidmap[2]: 3000 3000 1    mnt_gidmap[0]: 0 10000 1000    mnt_gidmap[1]: 2000 2000 1    mnt_gidmap[2]: 3000 3000 1But the idmappings might not always be resolvable in the caller&apos;s usernamespace. For example:    unshare --user --map-rootIn this case statmount() will skip any mappings that fil to resolve inthe caller&apos;s idmapping:    mnt_id:        2147485087    mnt_parent_id: 2147484016    fs_type:       btrfs    mnt_root:      /srv    mnt_point:     /opt    mnt_opts:      ssd,discard=async,space_cache=v2,subvolid=5,subvol=/The caller can differentiate between a mount not being idmapped and amount that is idmapped but where all mappings fail to resolve in thecaller&apos;s idmapping by check for the STATMOUNT_MNT_{G,U}IDMAP flag beingraised but the number of mappings in -&gt;mnt_{g,u}idmap_num being zero.Note that statmount() requires that the whole range must be resolvablein the caller&apos;s user namespace. If a subrange fails to map it will stilllist the map as not resolvable. This is a practical compromise to avoidhaving to find which subranges are resovable and wich aren&apos;t.Idmappings are listed as a string array with each mapping separated byzero bytes. This allows to retrieve the idmappings and immediately usethem for writing to e.g., /proc/&lt;pid&gt;/{g,u}id_map and it also allow forsimple iteration like:    if (stmnt-&gt;mask &amp; STATMOUNT_MNT_UIDMAP) {            const char *idmap = stmnt-&gt;str + stmnt-&gt;mnt_uidmap;            for (size_t idx = 0; idx &lt; stmnt-&gt;mnt_uidmap_nr; idx++) {                    printf(&quot;mnt_uidmap[%lu]: %s\n&quot;, idx, idmap);                    idmap += strlen(idmap) + 1;            }    }Link: https://lore.kernel.org/r/20250204-work-mnt_idmap-statmount-v2-2-007720f39f2e@kernel.orgReviewed-by: Jeff Layton &lt;jlayton@kernel.org&gt;Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Tue, 04 Feb 2025 11:27:47 +0000</pubDate>
        <dc:creator>Christian Brauner &lt;brauner@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>88a20626 - kill getname_statx_lookup_flags()</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#88a20626</link>
        <description>kill getname_statx_lookup_flags()LOOKUP_EMPTY is ignored by the only remaining user, and withoutthat &apos;getname_&apos; prefix makes no sense.Remove LOOKUP_EMPTY part, rename to statx_lookup_flags() and makestatic.  It most likely is _not_ statx() specific, either, butthat&apos;s the next step.Reviewed-by: Christian Brauner &lt;brauner@kernel.org&gt;Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Fri, 20 Sep 2024 04:38:59 +0000</pubDate>
        <dc:creator>Al Viro &lt;viro@zeniv.linux.org.uk&gt;</dc:creator>
    </item>
<item>
        <title>0158005a - replace do_getxattr() with saner helpers.</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#0158005a</link>
        <description>replace do_getxattr() with saner helpers.similar to do_setxattr() in the previous commit...Reviewed-by: Christian Brauner &lt;brauner@kernel.org&gt;Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Thu, 26 Sep 2024 21:07:15 +0000</pubDate>
        <dc:creator>Al Viro &lt;viro@zeniv.linux.org.uk&gt;</dc:creator>
    </item>
<item>
        <title>66d7ac6b - replace do_setxattr() with saner helpers.</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#66d7ac6b</link>
        <description>replace do_setxattr() with saner helpers.io_uring setxattr logics duplicates stuff from fs/xattr.c; providesaner helpers (filename_setxattr() and file_setxattr() resp.) anduse them.NB: putname(ERR_PTR()) is a no-opSigned-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Thu, 26 Sep 2024 03:57:57 +0000</pubDate>
        <dc:creator>Al Viro &lt;viro@zeniv.linux.org.uk&gt;</dc:creator>
    </item>
<item>
        <title>a10c4c5e - new helper: import_xattr_name()</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#a10c4c5e</link>
        <description>new helper: import_xattr_name()common logics for marshalling xattr names.Reviewed-by: Christian Brauner &lt;brauner@kernel.org&gt;Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Thu, 26 Sep 2024 18:11:52 +0000</pubDate>
        <dc:creator>Al Viro &lt;viro@zeniv.linux.org.uk&gt;</dc:creator>
    </item>
<item>
        <title>537c7662 - fs: rename struct xattr_ctx to kernel_xattr_ctx</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#537c7662</link>
        <description>fs: rename struct xattr_ctx to kernel_xattr_ctxRename the struct xattr_ctx to increase distinction with the about to beadded user API struct xattr_args.No functional change.Suggested-by: Christian Brauner &lt;brauner@kernel.org&gt;Signed-off-by: Christian G&#246;ttsche &lt;cgzones@googlemail.com&gt;Link: https://lore.kernel.org/r/20240426162042.191916-2-cgoettsche@seltendoof.deReviewed-by: Jan Kara &lt;jack@suse.cz&gt;Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Fri, 26 Apr 2024 16:20:15 +0000</pubDate>
        <dc:creator>Christian G&#246;ttsche &lt;cgzones@googlemail.com&gt;</dc:creator>
    </item>
<item>
        <title>1934b212 - file: reclaim 24 bytes from f_owner</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#1934b212</link>
        <description>file: reclaim 24 bytes from f_ownerWe do embedd struct fown_struct into struct file letting it take up 32bytes in total. We could tweak struct fown_struct to be more compact butreally it shouldn&apos;t even be embedded in struct file in the first place.Instead, actual users of struct fown_struct should allocate the structon demand. This frees up 24 bytes in struct file.That will have some potentially user-visible changes for the ownershipfcntl()s. Some of them can now fail due to allocation failures.Practically, that probably will almost never happen as the allocationsare small and they only happen once per file.The fown_struct is used during kill_fasync() which is used by e.g.,pipes to generate a SIGIO signal. Sending of such signals is conditionalon userspace having set an owner for the file using one of the F_OWNERfcntl()s. Such users will be unaffected if struct fown_struct isallocated during the fcntl() call.There are a few subsystems that call __f_setown() expectingfile-&gt;f_owner to be allocated:(1) tun devices    file-&gt;f_op-&gt;fasync::tun_chr_fasync()    -&gt; __f_setown()    There are no callers of tun_chr_fasync().(2) tty devices    file-&gt;f_op-&gt;fasync::tty_fasync()    -&gt; __tty_fasync()       -&gt; __f_setown()    tty_fasync() has no additional callers but __tty_fasync() has. Note    that __tty_fasync() only calls __f_setown() if the @on argument is    true. It&apos;s called from:    file-&gt;f_op-&gt;release::tty_release()    -&gt; tty_release()       -&gt; __tty_fasync()          -&gt; __f_setown()    tty_release() calls __tty_fasync() with @on false    =&gt; __f_setown() is never called from tty_release().       =&gt; All callers of tty_release() are safe as well.    file-&gt;f_op-&gt;release::tty_open()    -&gt; tty_release()       -&gt; __tty_fasync()          -&gt; __f_setown()    __tty_hangup() calls __tty_fasync() with @on false    =&gt; __f_setown() is never called from tty_release().       =&gt; All callers of __tty_hangup() are safe as well.From the callchains it&apos;s obvious that (1) and (2) end up getting calledvia file-&gt;f_op-&gt;fasync(). That can happen either through the F_SETFLfcntl() with the FASYNC flag raised or via the FIOASYNC ioctl(). IfFASYNC is requested and the file isn&apos;t already FASYNC thenfile-&gt;f_op-&gt;fasync() is called with @on true which ends up causing both(1) and (2) to call __f_setown().(1) and (2) are the only subsystems that call __f_setown() from thefile-&gt;f_op-&gt;fasync() handler. So both (1) and (2) have been updated toallocate a struct fown_struct prior to calling fasync_helper() toregister with the fasync infrastructure. That&apos;s safe as they both callfasync_helper() which also does allocations if @on is true.The other interesting case are file leases:(3) file leases    lease_manager_ops-&gt;lm_setup::lease_setup()    -&gt; __f_setown()    Which in turn is called from:    generic_add_lease()    -&gt; lease_manager_ops-&gt;lm_setup::lease_setup()       -&gt; __f_setown()So here again we can simply make generic_add_lease() allocate structfown_struct prior to the lease_manager_ops-&gt;lm_setup::lease_setup()which happens under a spinlock.With that the two remaining subsystems that call __f_setown() are:(4) dnotify(5) socketsBoth have their own custom ioctls to set struct fown_struct and bothhave been converted to allocate a struct fown_struct on demand fromtheir respective ioctls.Interactions with O_PATH are fine as well e.g., when opening a /dev/ttyas O_PATH then no file-&gt;f_op-&gt;open() happens thus no file-&gt;f_owner isallocated. That&apos;s fine as no file operation will be set for those andthe device has never been opened. fcntl()s called on such things willjust allocate a -&gt;f_owner on demand. Although I have zero idea why&apos;d youcare about f_owner on an O_PATH fd.Link: https://lore.kernel.org/r/20240813-work-f_owner-v2-1-4e9343a79f9f@kernel.orgReviewed-by: Jeff Layton &lt;jlayton@kernel.org&gt;Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Fri, 09 Aug 2024 16:00:01 +0000</pubDate>
        <dc:creator>Christian Brauner &lt;brauner@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>460695a2 - nsfs: add open_namespace()</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#460695a2</link>
        <description>nsfs: add open_namespace()and call it from open_related_ns().Link: https://lore.kernel.org/r/20240627-work-pidfs-v1-3-7e9ab6cc3bb1@kernel.orgReviewed-by: Jeff Layton &lt;jlayton@kernel.org&gt;Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;Reviewed-by: Alexander Mikhalitsyn &lt;aleksandr.mikhalitsyn@canonical.com&gt;Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Thu, 27 Jun 2024 14:11:41 +0000</pubDate>
        <dc:creator>Christian Brauner &lt;brauner@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>0ef625bb - vfs: support statx(..., NULL, AT_EMPTY_PATH, ...)</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#0ef625bb</link>
        <description>vfs: support statx(..., NULL, AT_EMPTY_PATH, ...)The newly used helper also checks for empty (&quot;&quot;) paths.NULL paths with any flag value other than AT_EMPTY_PATH go the usualroute and end up with -EFAULT to retain compatibility (Rust is abusingcalls of the sort to detect availability of statx).This avoids path lookup code, lockref management, memory allocation andin case of NULL path userspace memory access (which can be quiteexpensive with SMAP on x86_64).Benchmarked with statx(..., AT_EMPTY_PATH, ...) running on SapphireRapids, with the &quot;&quot; path for the first two cases and NULL for the lastone.Results in ops/s:stock:     4231237pre-check: 5944063 (+40%)NULL path: 6601619 (+11%/+56%)Signed-off-by: Mateusz Guzik &lt;mjguzik@gmail.com&gt;Link: https://lore.kernel.org/r/20240625151807.620812-1-mjguzik@gmail.comTested-by: Xi Ruoyao &lt;xry111@xry111.site&gt;[brauner: use path_mounted() and other tweaks]Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Tue, 25 Jun 2024 15:18:06 +0000</pubDate>
        <dc:creator>Mateusz Guzik &lt;mjguzik@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>9a87907d - ovl: implement tmpfile</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#9a87907d</link>
        <description>ovl: implement tmpfileCombine inode creation with opening a file.There are six separate objects that are being set up: the backing inode,dentry and file, and the overlay inode, dentry and file.  Cleanup in caseof an error is a bit of a challenge and is difficult to test, so carefulreview is needed.All tmpfile testcases except generic/509 now run/pass, and no regressionsare observed with full xfstests.Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;Reviewed-by: Amir Goldstein &lt;amir73il@gmail.com&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Thu, 02 May 2024 18:35:57 +0000</pubDate>
        <dc:creator>Miklos Szeredi &lt;mszeredi@redhat.com&gt;</dc:creator>
    </item>
<item>
        <title>9d9539db - pidfs: remove config option</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#9d9539db</link>
        <description>pidfs: remove config optionAs Linus suggested this enables pidfs unconditionally. A key property toretain is the ability to compare pidfds by inode number (cf. [1]).That&apos;s extremely helpful just as comparing namespace file descriptors byinode number is. They are used in a variety of scenarios where they needto be compared, e.g., when receiving a pidfd via SO_PEERPIDFD from asocket to trivially authenticate a the sender and various otheruse-cases.For 64bit systems this is pretty trivial to do. For 32bit it&apos;s slightlymore annoying as we discussed but we simply add a dumb ida basedallocator that gets used on 32bit. This gives the same guarantees aboutinode numbers on 64bit without any overflow risk. Practically, we&apos;llnever run into overflow issues because we&apos;re constrained by the numberof processes that can exist on 32bit and by the number of open filesthat can exist on a 32bit system. On 64bit none of this matters andthings are very simple.If 32bit also needs the uniqueness guarantee they can simply parse thecontents of /proc/&lt;pid&gt;/fd/&lt;nr&gt;. The uniqueness guarantees have avariety of use-cases. One of the most obvious ones is that they willmake pidfiles (or &quot;pidfdfiles&quot;, I guess) reliable as the uniqueidentifier can be placed into there that won&apos;t be reycled. Also afrequent request.Note, I took the chance and simplified path_from_stashed() even further.Instead of passing the inode number explicitly to path_from_stashed() welet the filesystem handle that internally. So path_from_stashed() endsup even simpler than it is now. This is also a good solution allowingthe cleanup code to be clean and consistent between 32bit and 64bit. Thecleanup path in prepare_anon_dentry() is also switched around so we putthe inode before the dentry allocation. This means we only have to callthe cleanup handler for the filesystem&apos;s inode data once and can rely-&gt;evict_inode() otherwise.Aside from having to have a bit of extra code for 32bit it actually endsup a nice cleanup for path_from_stashed() imho.Tested on both 32 and 64bit including error injection.Link: https://github.com/systemd/systemd/pull/31713 [1]Link: https://lore.kernel.org/r/20240312-dingo-sehnlich-b3ecc35c6de7@braunerSigned-off-by: Christian Brauner &lt;brauner@kernel.org&gt;Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Tue, 12 Mar 2024 09:39:44 +0000</pubDate>
        <dc:creator>Christian Brauner &lt;brauner@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>e9c5263c - libfs: improve path_from_stashed()</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#e9c5263c</link>
        <description>libfs: improve path_from_stashed()Right now we pass a bunch of info that is fs specific which doesn&apos;t makea lot of sense and it bleeds fs sepcific details into the generichelper. nsfs and pidfs have slightly different needs when initializinginodes. Add simple operations that are stashed in sb-&gt;s_fs_info thatboth can implement. This also allows us to get rid of cleaning upreferences in the caller. All in all path_from_stashed() becomes waysimpler.Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Fri, 01 Mar 2024 09:26:03 +0000</pubDate>
        <dc:creator>Christian Brauner &lt;brauner@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>2558e3b2 - libfs: add stashed_dentry_prune()</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#2558e3b2</link>
        <description>libfs: add stashed_dentry_prune()Both pidfs and nsfs use a memory location to stash a dentry for reuse byconcurrent openers. Right now two customdentry-&gt;d_prune::{ns,pidfs}_prune_dentry() methods are needed that dothe same thing. The only thing that differs is that they need to get tothe memory location to store or retrieve the dentry from differently.Fix that by remember the stashing location for the dentry indentry-&gt;d_fsdata which allows us to retrieve it in dentry-&gt;d_prune. Thatin turn makes it possible to add a common helper that pidfs and nsfs canboth use.Link: https://lore.kernel.org/r/CAHk-=wg8cHY=i3m6RnXQ2Y2W8psicKWQEZq1=94ivUiviM-0OA@mail.gmail.comSigned-off-by: Christian Brauner &lt;brauner@kernel.org&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Wed, 21 Feb 2024 08:59:51 +0000</pubDate>
        <dc:creator>Christian Brauner &lt;brauner@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>b28ddcc3 - pidfs: convert to path_from_stashed() helper</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#b28ddcc3</link>
        <description>pidfs: convert to path_from_stashed() helperMoving pidfds from the anonymous inode infrastructure to a separate tinyin-kernel filesystem similar to sockfs, pipefs, and anon_inodefs causesselinux denials and thus various userspace components that make heavyuse of pidfds to fail as pidfds used anon_inode_getfile() which aren&apos;tsubject to any LSM hooks. But dentry_open() is and that would causeregressions.The failures that are seen are selinux denials. But the core failure isdbus-broker. That cascades into other services failing that depend ondbus-broker. For example, when dbus-broker fails to start polkit and allthe others won&apos;t be able to work because they depend on dbus-broker.The reason for dbus-broker failing is because it doesn&apos;t handle failuresfor SO_PEERPIDFD correctly. Last kernel release we introducedSO_PEERPIDFD (and SCM_PIDFD). SO_PEERPIDFD allows dbus-broker and polkitand others to receive a pidfd for the peer of an AF_UNIX socket. This isthe first time in the history of Linux that we can safely authenticateclients in a race-free manner.dbus-broker immediately made use of this but messed up the errorchecking. It only allowed EINVAL as a valid failure for SO_PEERPIDFD.That&apos;s obviously problematic not just because of LSM denials but becauseof seccomp denials that would prevent SO_PEERPIDFD from working; or anyother new error code from there.So this is catching a flawed implementation in dbus-broker as well. Ithas to fallback to the old pid-based authentication when SO_PEERPIDFDdoesn&apos;t work no matter the reasons otherwise it&apos;ll always risk suchfailures. So overall that LSM denial should not have caused dbus-brokerto fail. It can never assume that a feature released one kernel ago likeSO_PEERPIDFD can be assumed to be available.So, the next fix separate from the selinux policy update is to try andfix dbus-broker at [3]. That should make it into Fedora as well. Inaddition the selinux reference policy should also be updated. See [4]for that. If Selinux is in enforcing mode in userspace and it encountersanything that it doesn&apos;t know about it will deny it by default. And thepolicy is entirely in userspace including declaring new types for stufflike nsfs or pidfs to allow it.For now we continue to raise S_PRIVATE on the inode if it&apos;s a pidfsinode which means things behave exactly like before.Link: https://bugzilla.redhat.com/show_bug.cgi?id=2265630Link: https://github.com/fedora-selinux/selinux-policy/pull/2050Link: https://github.com/bus1/dbus-broker/pull/343 [3]Link: https://github.com/SELinuxProject/refpolicy/pull/762 [4]Reported-by: Nathan Chancellor &lt;nathan@kernel.org&gt;Link: https://lore.kernel.org/r/20240222190334.GA412503@dev-arch.thelio-3990XLink: https://lore.kernel.org/r/20240218-neufahrzeuge-brauhaus-fb0eb6459771@braunerSigned-off-by: Christian Brauner &lt;brauner@kernel.org&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Mon, 19 Feb 2024 15:30:57 +0000</pubDate>
        <dc:creator>Christian Brauner &lt;brauner@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>07fd7c32 - libfs: add path_from_stashed()</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/fs/internal.h#07fd7c32</link>
        <description>libfs: add path_from_stashed()Add a helper for both nsfs and pidfs to reuse an already stashed dentryor to add and stash a new dentry.Link: https://lore.kernel.org/r/20240218-neufahrzeuge-brauhaus-fb0eb6459771@braunerSigned-off-by: Christian Brauner &lt;brauner@kernel.org&gt;

            List of files:
            /linux-6.15/fs/internal.h</description>
        <pubDate>Sun, 18 Feb 2024 13:50:13 +0000</pubDate>
        <dc:creator>Christian Brauner &lt;brauner@kernel.org&gt;</dc:creator>
    </item>
</channel>
</rss>
