Re: [PATCH] dlm: don't put an uninitialized lockspace kobject on error

[Alexander Aring]

Hi,

On Mon, Oct 19, 2026 at 2:49 PM Sanan Hasanov <sanan.hasanou@xxxxxxxxx> wrote:
>
> From: Sanan Hasanov <sanan.hasanov@xxxxxxx>
>
> Commit 8a4cf500f1dd ("dlm: drop kobject release callback handling")
> dropped the do_unreg flag from new_lockspace() and made the out_lsfree
> error label call kobject_put(&ls->ls_kobj) unconditionally. But ls_kobj
> is only initialized by kobject_init_and_add() after the callback
> workqueue and dlm_recoverd have been started, so every failure before
> that point puts a kobject that was never initialized:
>
>   dlm: ls_6035_1: can't start dlm_callback -12
>   kobject: '(null)' (ffff888027a28088): is not initialized, yet kobject_put() is being called.
>   WARNING: lib/kobject.c:736 at kobject_put+0x66/0x550 lib/kobject.c:734
>   Call Trace:
>    new_lockspace fs/dlm/lockspace.c:617 [inline]
>    __dlm_new_lockspace+0x1714/0x1cd0 fs/dlm/lockspace.c:638
>    device_create_lockspace+0xc7/0x350 fs/dlm/user.c:414
>    device_write+0x872/0xed0 fs/dlm/user.c:606
>    vfs_write+0x296/0xba0 fs/read_write.c:685
>
> syzbot hits this by sending SIGKILL to a task creating a lockspace
> through /dev/dlm-control, so that alloc_ordered_workqueue() in
> dlm_callback_start() fails to create its rescuer thread. The same
> happens if rhashtable_init(), the ls_recover_buf allocation or
> dlm_recoverd_start() fail.
>
> Bring the flag back so the kobject is only put once
> kobject_init_and_add() has been called. Since the kobject no longer
> frees the lockspace, kfree(ls) still runs on every error path.
>
> Fixes: 8a4cf500f1dd ("dlm: drop kobject release callback handling")
> Reported-by: syzbot+b2b8d04ec4914f618d23@xxxxxxxxxxxxxxxxxxxxxxxxx
> Closes: https://syzkaller.appspot.com/bug?extid=b2b8d04ec4914f618d23
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Sanan Hasanov <sanan.hasanov@xxxxxxx>

Acked-by: Alexander Aring <aahringo@xxxxxxxxxx>

Thanks.

This patch conflicts with another patch that is probably not going
through the dlm tree. It will not fix this issue [0]

I think it's best to wait and queue your fix until it's through, and
then we can rebase your patch.

- Alex

[0] https://lore.kernel.org/gfs2/20261027223847.652884-6-irogers@xxxxxxxxxx/