Re: kernfs: kernfs_drain()'s fast-path decision reads the active count without acquire ordering -- on weakly-ordered architectures the forced ->release()/unmap can be skipped

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Nov 11, 2026 at 03:30:11PM +0800, 徐晗翔 wrote:
> kernfs_drain() (fs/kernfs/dir.c:508-551) decides whether it must
> drain open files with the fast-path test "atomic_read(&kn->active)
> == KN_DEACTIVATED_BIAS && !kernfs_should_drain_open_files(kn)" --
> both a plain atomic_read (relaxed) and an unlocked read of
> kn->attr.open / on->nr_mmapped / on->nr_to_release.  The writer side
> (the last active holder) releases correctly -- its writes to
> attr.open/counter happen under the hash lock, followed by the fully
> ordered atomic_dec_return() that wakes the drain waiter
> (dir.c:491-495) -- but on the READER side there is no acquire edge
> on any fast path: the early-return branch (:522-524), the
> wait_event's non-sleeping first check (:537-538), and the slow-loop
> checks where the waker has not yet touched the queue lock.  The
> phase-1 BIAS add is itself a relaxed atomic_add (:1563), and the
> kernfs_rwsem write lock the remover holds has no intersection with
> the putter.  On a weakly-ordered architecture (arm64, powerpc,
> riscv; x86-TSO is immune because plain load-load does not reorder),
> the remover can therefore observe "active drained" WITHOUT observing
> the racing opener's attr.open/nr_to_release/nr_mmapped updates, skip
> kernfs_drain_open_files() entirely, and leave the mandatory
> ->release() and unmap_mapping_range() to be deferred to the last fd
> close.  Consequences under current semantics: no memory corruption
> (of->kn/inode stay pinned through the dentry chain; the close path
> performs the release and decrements then, and the accounting WARN
> never fires) -- the observable effects are a delayed
> cgroup_file_release()/put_cgroup_ns() (a cgroup-namespace reference
> pinned for the lifetime of a leaked-open fd) and a skipped
> unmap_mapping_range() (mmap'ed vmas survive until their next fault
> takes the kernfs fault path and SIGBUSes, safely).  I verified the
> RACE itself dynamically on a stock Linux 7.3 KCSAN kernel: a
> cgroup2-slot hammer (attached) produced 17 captures of exactly the
> target race pair -- kernfs_fop_release (the nr_to_release--
> writer, inlined in the close path) vs kernfs_should_drain_open_files
> (read), with the reader stack at kernfs_drain+0xba, which I mapped
> back to dir.c:522-524 (the early-return decision) via objdump (the
> cmp $0x80000001 / KN_DEACTIVATED_BIAS immediate).  The consequence
> itself needs a weakly-ordered machine plus a microsecond window, so
> I did not and could not trigger it on x86 -- the report is therefore
> a memory-ordering fix with (a) the race pair proven to occur as a
> matter of course on x86, (b) an LKMM litmus showing the outcome is
> Allowed on linux-kernel.cat and Never on x86-TSO (available; please
> run it), and (c) a one-line fix that closes all three fast paths.

<snip>

This is a wall of LLM text that isn't useful to anyone, sorry.

Please just submit normal patches, as our documentation asks for.

thanks,

greg k-h