On 4/24/25 4:45 AM, Ondrej Mosnacek wrote: > On Thu, Apr 24, 2025 at 12:37 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: >> >> On Tue, Apr 15, 2025 at 5:22 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: >>> On Tue, Apr 15, 2025 at 10:06 AM Li Lingfeng <lilingfeng3@xxxxxxxxxx> wrote: >>>> >>>> Hi, >>>> Thank you for reporting this issue and sharing the detailed reproducer. >>>> Apologies for the gap in my knowledge regarding security_label. >>>> Would need some time to study its implementation in the security subsystem. >>>> >>>> To begin validating the problem, I attempted to run the reproducer on >>>> Fedora 26(with kernel -- master 8ffd015db85f). However, I didn't observe >>>> the reported mislabeling of the root directory. >>> >>> Hm... Fedora 26 is *very* outdated and not maintained any more - I'd >>> recommend using 41, which is the current latest stable release. Hard >>> to say if it affects the reproducibility of this bug, but it's always >>> possible that userspace is also somehow involved. >>> >>>> >>>> The modifications introduced by commit fc2a169c56de specifically affect >>>> scenarios where the /proc/net/rpc/xxx/flush interface is frequently >>>> invoked within a 1-second window. During the reproducer execution, I >>>> indeed observed repeated calls to this flush interface, though I'm >>>> currently uncertain about its precise impact on the security_label >>>> mechanism. >>>> [ 124.108016][ T2754] call write_flush >>>> [ 124.108878][ T2754] call write_flush >>>> [ 124.147886][ T2757] call write_flush >>>> [ 124.148604][ T2757] call write_flush >>>> [ 124.149258][ T2757] call write_flush >>>> [ 124.149911][ T2757] call write_flush >>>> >>>> Once I have a solid understanding of the security_label mechanism, I will >>>> conduct a more thorough analysis. >>> >>> I'm not sure how the two affect each other either... It almost looks >>> like the last mount command somehow ends up mounting the "old" export >>> without security_label in some cases, even though the exportfs >>> commands that re-export the dir without security_label had completed >>> successfully by that time. >>> >>> Thank you for looking into it! >> >> I just wanted to check and see how things were progressing? I haven't >> noticed any failures lately on my Fedora Rawhide + patches kernel >> builds, but I wasn't sure if the problem had been fixed or if I've >> just been really lucky :) > > I can still reproduce the bug on the latest Fedora Rawhide kernel > (6.15.0-0.rc3.20250422gita33b5a08cbbd.29.fc43.x86_64), which is based > on commit a33b5a08cbbdd7aadff95f40cbb45ab86841679e in Linus' tree. > > Can we perhaps have the commit reverted for now while the bug is being > investigated? The change doesn't look essential and should be easy to > reintroduce once the bug is addressed. I've queued up a patch to revert fc2a169c56de in the nfsd-fixes tree for v6.15-rc. -- Chuck Lever
