On Fri, Oct 23, 2026 at 06:11:09PM +0200, Christophe JAILLET wrote:
> Le 02/10/2026 à 03:40, Alison Schofield a écrit :
> > On Fri, Sep 11, 2026 at 01:55:43PM +0530, Hemanth Selam wrote:
> > > pmem_attach_disk() allocates the gendisk with blk_alloc_disk() and hands
> > > it to devres only once device_add_disk() has succeeded. Until that
> > > point the probe path owns the disk itself, which is why every failure
> > > after the allocation jumps to the out: label and puts it there.
> > >
> > > The devm_init_badblocks() failure returns directly instead, so the disk
> > > allocated a few lines earlier is never released. Nothing releases it
> > > afterwards either: the devres action that would have done so has not
> > > been registered yet, so unbinding the namespace or destroying it does
> > > not reach the disk, and it stays allocated along with its queue and its
> > > bdev inode until the machine is rebooted.
> > >
> > > devm_init_badblocks() only fails when a single page allocation fails, so
> > > reaching this at all needs memory exhaustion during namespace probe, and
> > > because device_add_disk() has not run there is nothing user visible left
> > > behind: no device node, no sysfs entry, only the leaked memory.
> > >
> > > Release the gendisk through the existing cleanup path on this failure.
> > >
> > > Fixes: 3dd60fb9d95d ("nvdimm/pmem: stop using q_usage_count as external
> > > pgmap refcount")
> > > Signed-off-by: Hemanth Selam <[email protected]>
> >
> >
> > Applied to libnvdimm-for-next:
> > https://git.kernel.org/nvdimm/nvdimm/c/855a46681e0b
>
> Hi,
>
> For the records and if it sounds better patch, see [1] which propagates the
> error code from devm_init_badblocks() instead of hard-coding a -ENOMEM;
>
> CJ
>
> [1]:
> https://lore.kernel.org/lkml/f1933a01d9cefe24970ee93d741babb8fe9c1b32.1636219557.git.christophe.jail...@wanadoo.fr/
>
Hi CJ,
I'm thinking the best way forward is to rebase and send a v2 of your patch
from 2021 for upstream review.
-- Alison
