Re: [PATCH] gfs2: fix duplicate kmem_cache name on concurrent mounts

On Wed, Mar 25, 2026 at 11:28 PM Andrew Price <[email protected]> wrote:
>
> On 25/03/2026 06:05, Deepanshu Kartikey wrote:
> > When gfs2_fill_super() creates the per-filesystem bufdata cache, it
> > uses sd_fsname as part of the cache name:
> >
> >   sdp->sd_bufdata = kmem_cache_create("gfs2-bufdata/<fsname>", ...);
> >
> > At this point sd_fsname is set from sd_table_name (e.g. "syz:syz"),
> > which is the same for all concurrent mounts of the same device.
> > The unique suffix (.s for spectator, .N for journal ID) is only
> > added to sd_fsname AFTER wait_on_journal() completes, since the
> > journal ID is assigned by the locking subsystem during mount.
> >
> > With multiple concurrent mounts of the same device (as triggered by
> > syzkaller with procs:5), multiple calls to gfs2_fill_super() all try
> > to create a cache named "gfs2-bufdata/syz:syz" before any of them
> > reaches the point where sd_fsname becomes unique, triggering:
> >
> >   kmem_cache of name 'gfs2-bufdata/syz:syz' already exists
> >   WARNING: mm/slab_common.c:112
> >
> > Fix this by moving the bufdata cache creation to after
> > wait_on_journal() completes and sd_fsname has been updated with its
> > unique suffix. Also move the fail_bufdata cleanup label accordingly
> > in the error unwind path.
>
> I don't think the description is accurate as the patch moves the kmem_cache_create() to after the gfs2_sys_fs_add(), which fails the mount cleanly on a duplicate lock table instead of triggering a warning.
>
> That said, 767e4de3ffce ("gfs2: per-filesystem bufdata cache") is likely to get pulled out of for-next as it was more of a debugging aid so it's probably not worth a v2.
>
> Andy
>

Hi Andy,

Thank you for the explanation.

I went back and traced through the code more carefully. The real
protection comes from gfs2_sys_fs_add() which calls
kobject_init_and_add() with sd_table_name — this fails cleanly
when a duplicate mount is attempted since the sysfs path already
exists.

The bug was that kmem_cache_create() was called BEFORE
gfs2_sys_fs_add(), so concurrent mounts both created a cache
with the same name before either reached the duplicate check.
Moving the cache creation to after gfs2_sys_fs_add() means
duplicate mounts are rejected cleanly there first.

I also understand now why sd_fsname uniqueness is not the real
fix — with lock_nolock, ls_jid comes from mount options and
can be the same (jid=0) for all concurrent mounts, so
sd_fsname would still be "syz:syz.0" for all of them.

Thanks for your time,
Deepanshu Kartikey