CVE-2026-98920: netfs: Fix missing alloc tagging of direct mempool allocations

In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix missing alloc tagging of direct mempool allocations

Commit 1d78d56c43ef ("netfs: Fix folioqueue ENOMEM in writeback by adding a mempool") added a mempool for the folioqueues and made the request, subrequest and folioqueue allocations distinguish between writeback and everything else. Writeback is part of memory reclaim and must not fail due to ENOMEM, so it allocates under GFPNOFS through mempoolalloc(), which may dip into the pool's reserve and, if that runs empty, wait for elements to be returned. The GFPKERNEL paths, which can return -ENOMEM to their callers, invoke the pool's ->alloc() callback directly instead.

The direct call, however, skips the allochooks() wrapper that the mempoolalloc() macro provides. The pool callbacks, mempoolallocslab() and mempoolkmalloc(), call kmemcacheallocnoprof() and kmallocnoprof() and rely on current->alloctag having been set by the caller. With CONFIGMEMALLOCPROFILINGDEBUG=y this leads to

current->alloctag not set WARNING: ./include/linux/alloctag.h:161 at alloctaggingslaballochook alloctag was not set WARNING: ./include/linux/alloctag.h:166 at alloctaggingslabfreehook

at allocation and free time respectively, as reported when reading files on a CIFS mount. The allocations are also missing from /proc/allocinfo.

Wrap the direct ->alloc() invocations in allochooks() with a new mempoolallocnoreserve() helper in include/linux/mempool.h, next to the other allochooks()-wrapped macros such as mempoolalloc(). The GFPKERNEL paths keep their failable allocation semantics, they just get tagged now.