All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hao Ge <hao.ge@linux.dev>
To: Suren Baghdasaryan <surenb@google.com>
Cc: David Howells <dhowells@redhat.com>,
	Paulo Alcantara <pc@manguebit.org>,
	"Christian Brauner (Amutable)" <brauner@kernel.org>,
	netfs@lists.linux.dev, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Erhard Furtner <erhard_f@mailbox.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH] netfs: Fix missing alloc tagging of direct mempool allocations
Date: Wed, 23 Sep 2026 14:20:19 +0800	[thread overview]
Message-ID: <02a218c8-b655-4e6d-a6db-b35e178eef3d@linux.dev> (raw)
In-Reply-To: <CAJuCfpEFxn6peTwkE=orOuhSBchmuziYK1Xt75iwJo59rqYUQA@mail.gmail.com>

Hi Suren

Thanks for your review.

On 2026/9/23 11:06, Suren Baghdasaryan wrote:
> On Mon, Sep 21, 2026 at 7:37 PM Hao Ge <hao.ge@linux.dev> wrote:
>>
>> 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=y 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_hook
>>
>> 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 the new
>> netfs_mempool_alloc_noreserve() helper.  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 <erhard_f@mailbox.org>
>> Closes: https://lore.kernel.org/all/0b004319-9ef7-437c-a4dd-174d6a9a83db@mailbox.org/
>> Tested-by: Erhard Furtner <erhard_f@mailbox.org>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Hao Ge <hao.ge@linux.dev>
>> ---
>>  fs/netfs/internal.h       | 3 +++
>>  fs/netfs/objects.c        | 4 ++--
>>  fs/netfs/rolling_buffer.c | 2 +-
>>  3 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/netfs/internal.h b/fs/netfs/internal.h
>> index c79c8e69d60c..08ba7f0ebff0 100644
>> --- a/fs/netfs/internal.h
>> +++ b/fs/netfs/internal.h
>> @@ -45,6 +45,9 @@ extern mempool_t netfs_request_pool;
>>  extern mempool_t netfs_subrequest_pool;
>>  extern mempool_t netfs_folioq_pool;
>>
>> +#define netfs_mempool_alloc_noreserve(_pool, _gfp)                             \
>> +       alloc_hooks((_pool)->alloc(_gfp, (_pool)->pool_data))
> 
> I think this macro should reside in include/linux/mempool.h and not be
> netfs-specific. Something like:
> 
> #define mempool_alloc_noreserve(_pool, _gfp)                             \
>        alloc_hooks((_pool)->alloc(_gfp, (_pool)->pool_data))
>

Sure. I kept it in netfs initially since we're the only ones calling ->alloc() directly today,
but it is indeed a better fit for mempool.h. 
Will fix that in v2.

Thanks
Best Regards
Hao

>> +
>>  #ifdef CONFIG_PROC_FS
>>  static inline void netfs_proc_add_rreq(struct netfs_io_request *rreq)
>>  {
>> diff --git a/fs/netfs/objects.c b/fs/netfs/objects.c
>> index 7f6a3e912602..0b509c93d4af 100644
>> --- a/fs/netfs/objects.c
>> +++ b/fs/netfs/objects.c
>> @@ -34,7 +34,7 @@ struct netfs_io_request *netfs_alloc_request(struct address_space *mapping,
>>
>>                 rreq = mempool_alloc(mempool, gfp);
>>         } else {
>> -               rreq = mempool->alloc(gfp, mempool->pool_data);
>> +               rreq = netfs_mempool_alloc_noreserve(mempool, gfp);
>>                 if (!rreq)
>>                         return ERR_PTR(-ENOMEM);
>>         }
>> @@ -214,7 +214,7 @@ struct netfs_io_subrequest *netfs_alloc_subrequest(struct netfs_io_request *rreq
>>         struct kmem_cache *cache = mempool->pool_data;
>>
>>         if (rreq->gfp == GFP_KERNEL)
>> -               subreq = mempool->alloc(rreq->gfp, mempool->pool_data);
>> +               subreq = netfs_mempool_alloc_noreserve(mempool, rreq->gfp);
>>         else
>>                 subreq = mempool_alloc(mempool, rreq->gfp);
>>         if (!subreq)
>> diff --git a/fs/netfs/rolling_buffer.c b/fs/netfs/rolling_buffer.c
>> index 424e77a9a109..54867ceaa205 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;
>>
>>         if (gfp == GFP_KERNEL)
>> -               fq = netfs_folioq_pool.alloc(gfp, netfs_folioq_pool.pool_data);
>> +               fq = netfs_mempool_alloc_noreserve(&netfs_folioq_pool, gfp);
>>         else
>>                 fq = mempool_alloc(&netfs_folioq_pool, gfp);
>>         if (fq) {
>> --
>> 2.25.1
>>
>>

      reply	other threads:[~2026-09-23  6:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22  2:35 [PATCH] netfs: Fix missing alloc tagging of direct mempool allocations Hao Ge
2026-09-23  3:06 ` Suren Baghdasaryan
2026-09-23  6:20   ` Hao Ge [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=02a218c8-b655-4e6d-a6db-b35e178eef3d@linux.dev \
    --to=hao.ge@linux.dev \
    --cc=brauner@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=erhard_f@mailbox.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfs@lists.linux.dev \
    --cc=pc@manguebit.org \
    --cc=stable@vger.kernel.org \
    --cc=surenb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.