From nobody Thu Sep 24 13:37:01 2026 Received: from mta1.migadu.com (out-89.mta1.migadu.com [95.215.58.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 21768430CD7 for ; Wed, 23 Sep 2026 06:37:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.89 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790145431; cv=none; b=AodA+G/F/2UueGpZRcQcZYj2asKWaDE1bSGw8SwVlbN91rpU6AsktjoB28gC2Wj+/2j2+flcGOpAs/wXEkWT2UvIHL6OY9LWLlVxfYL4CHugTrAcVzg4CpEkPBmYMtKlWuVWRCrsbIpjhfxJQOr6BGOwGmKs7vFPB43kV165Udk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790145431; c=relaxed/simple; bh=q6FUjfAvrde7ObIfU3V3bTgB9v/JDqJhh9doDVfzOdI=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=T6e5nMgTE2ilYHeJ5glbJxlqP/cCvbX5Ig7nobEPIZgQX0uUpDUa5nfAmEdLJs+EDkneLoexVOpTnJZekMgFNBHZQbWcpOTFHwQ2CyN0gDGalGQI8UV5ucU0++h+EIZGjQI+D8RUY0Co4KH+03/Ni8MP42fV/IzMY0ONw8Y1Few= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=YrsfIawT; arc=none smtp.client-ip=95.215.58.89 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="YrsfIawT" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=q6FUjfAvrde7ObIfU3V3bTgB9v/JDqJhh9doDVfzOdI=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1790145425; v=1; x=1790750225; b=YrsfIawTM4dJ2cxEBQ6nGgUQLQf+evC8T7fQ111YlZpIMVYNHFGXiYpBo97U1iN171gnOqsy cOal7C4xbrzeeNTmG5j7dLfUrYf25luNdyiL74daiGSkzLmjflZ9VaJyFwoLeGsYp+U7pJgXqIw WRoO50eXkj1KCeRXbeyO4rL8= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 7a7d515496bbdaf5; Wed, 23 Sep 2026 06:37:02 +0000 X-Mizu-Trace-ID: 7a7d515496bbdaf5 X-Migadu-Flow: FLOW_OUT From: Hao Ge To: David Howells , Paulo Alcantara , Vlastimil Babka , Harry Yoo , Andrew Morton , Hao Li , Christoph Lameter , David Rientjes , Roman Gushchin , "Christian Brauner (Amutable)" , Suren Baghdasaryan Cc: netfs@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Hao Ge , Erhard Furtner , stable@vger.kernel.org Subject: [PATCH v2] netfs: Fix missing alloc tagging of direct mempool allocations Date: Wed, 23 Sep 2026 14:37:59 +0800 Message-Id: <20260923063759.34667-1-hao.ge@linux.dev> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Commit 1d78d56c43ef ("netfs: Fix folio_queue ENOMEM in writeback by adding a mempool") added a mempool for the folio_queues and made the request, subrequest and folio_queue allocations distinguish between writeback and everything else. Writeback is part of memory reclaim and must not fail due to ENOMEM, so it allocates under GFP_NOFS through mempool_alloc(), which may dip into the pool's reserve and, if that runs empty, wait for elements to be returned. The GFP_KERNEL paths, which can return -ENOMEM to their callers, invoke the pool's ->alloc() callback directly instead. The direct call, however, skips the alloc_hooks() wrapper that the mempool_alloc() macro provides. The pool callbacks, mempool_alloc_slab() and mempool_kmalloc(), call kmem_cache_alloc_noprof() and kmalloc_noprof() and rely on current->alloc_tag having been set by the caller. With CONFIG_MEM_ALLOC_PROFILING_DEBUG=3Dy this leads to current->alloc_tag not set WARNING: ./include/linux/alloc_tag.h:161 at __alloc_tagging_slab_alloc_= hook alloc_tag was not set WARNING: ./include/linux/alloc_tag.h:166 at __alloc_tagging_slab_free_h= ook 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 alloc_hooks() with a new mempool_alloc_noreserve() helper in include/linux/mempool.h, next to the other alloc_hooks()-wrapped macros such as mempool_alloc(). The GFP_KERNEL paths keep their failable allocation semantics, they just get tagged now. Fixes: 1d78d56c43ef ("netfs: Fix folio_queue ENOMEM in writeback by adding = a mempool") Reported-by: Erhard Furtner Closes: https://lore.kernel.org/all/0b004319-9ef7-437c-a4dd-174d6a9a83db@ma= ilbox.org/ Tested-by: Erhard Furtner Suggested-by: Suren Baghdasaryan Cc: stable@vger.kernel.org Signed-off-by: Hao Ge Acked-by: Vlastimil Babka (SUSE) --- Changes in v2: - Move the alloc_hooks() wrapper from fs/netfs/internal.h into include/linux/mempool.h as mempool_alloc_noreserve(), per Suren's suggestion, so it is not netfs-specific. v1 Link: https://lore.kernel.org/all/20260922023541.51532-1-hao.ge@linux.de= v/ --- fs/netfs/objects.c | 4 ++-- fs/netfs/rolling_buffer.c | 2 +- include/linux/mempool.h | 7 +++++++ 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/fs/netfs/objects.c b/fs/netfs/objects.c index 7f6a3e912602..ad549daa9c79 100644 --- a/fs/netfs/objects.c +++ b/fs/netfs/objects.c @@ -34,7 +34,7 @@ struct netfs_io_request *netfs_alloc_request(struct addre= ss_space *mapping, =20 rreq =3D mempool_alloc(mempool, gfp); } else { - rreq =3D mempool->alloc(gfp, mempool->pool_data); + rreq =3D mempool_alloc_noreserve(mempool, gfp); if (!rreq) return ERR_PTR(-ENOMEM); } @@ -214,7 +214,7 @@ struct netfs_io_subrequest *netfs_alloc_subrequest(stru= ct netfs_io_request *rreq struct kmem_cache *cache =3D mempool->pool_data; =20 if (rreq->gfp =3D=3D GFP_KERNEL) - subreq =3D mempool->alloc(rreq->gfp, mempool->pool_data); + subreq =3D mempool_alloc_noreserve(mempool, rreq->gfp); else subreq =3D mempool_alloc(mempool, rreq->gfp); if (!subreq) diff --git a/fs/netfs/rolling_buffer.c b/fs/netfs/rolling_buffer.c index 424e77a9a109..d30d5ef6d86e 100644 --- a/fs/netfs/rolling_buffer.c +++ b/fs/netfs/rolling_buffer.c @@ -29,7 +29,7 @@ struct folio_queue *netfs_folioq_alloc(unsigned int rreq_= id, gfp_t gfp, struct folio_queue *fq; =20 if (gfp =3D=3D GFP_KERNEL) - fq =3D netfs_folioq_pool.alloc(gfp, netfs_folioq_pool.pool_data); + fq =3D mempool_alloc_noreserve(&netfs_folioq_pool, gfp); else fq =3D mempool_alloc(&netfs_folioq_pool, gfp); if (fq) { diff --git a/include/linux/mempool.h b/include/linux/mempool.h index a0fa6d43e0dc..6da502aef2f7 100644 --- a/include/linux/mempool.h +++ b/include/linux/mempool.h @@ -70,6 +70,13 @@ int mempool_alloc_bulk_noprof(struct mempool *pool, void= **elem, #define mempool_alloc_bulk(...) \ alloc_hooks(mempool_alloc_bulk_noprof(__VA_ARGS__)) =20 +/* + * Allocate a new element without dipping into the pool's reserves or + * waiting. Returns NULL on failure. + */ +#define mempool_alloc_noreserve(_pool, _gfp) \ + alloc_hooks((_pool)->alloc(_gfp, (_pool)->pool_data)) + void *mempool_alloc_preallocated(struct mempool *pool) __malloc; void mempool_free(void *element, struct mempool *pool); unsigned int mempool_free_bulk(struct mempool *pool, void **elem, --=20 2.25.1