Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Chris Roy]

[-- Attachment #1: Type: text/plain, Size: 8056 bytes --]

On Thu, Sep 17, 2026 at 13:05:00 +0530, Greg KH wrote:
> Did you forget the Assisted-by: tag?
>
> Make the comments make sense please. That's the problem of using a LLM :(

Fair. v3 adds Assisted-by and rewrites those comments.
Same approach as v2 otherwise. syzbot tested v2 cleanly on this bug.

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master

Please consider for linux-mtd.

On Thu, 17 Sept 2026 at 13:05, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Sep 17, 2026 at 12:14:05PM +0530, Chris Roy wrote:
> > On Wed, 9 Sep 2026 08:19:24 -0700, syzbot wrote:
> > > syzbot found the following issue on:
> > > ...
> > > possible deadlock in ovl_create_object
> >
> > Follow-up / v2.
> >
> > v1 deferred the open with schedule_work() and an on-stack work_struct.
> > That cleared the lockdep cycle, but syzbot reported an ODEBUG warning
> > under CONFIG_DEBUG_OBJECTS_WORK.
> >
> > v2 uses a dedicated ordered workqueue and heap-allocated work, keeps a
> > module reference across the deferred open, flushes the queue before
> > exit, and serializes setup on the worker under a local mutex.
> >
> > Local testing with the C reproducer (LOCKDEP + DEBUG_OBJECTS_WORK):
> > unpatched hits the circular locking warning; v2 is clean.
> >
> > #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
> >
> > Please consider the patch for linux-mtd.
> >
> > On Thu, 17 Sept 2026 at 03:22, syzbot
> > <syzbot+7cab6a19619f1b8efc00@syzkaller.appspotmail.com> wrote:
> > >
> > > Hello,
> > >
> > > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > > WARNING: ODEBUG bug in lookup_object_or_alloc
> > >
> > > ODEBUG: object ffffc90007cdf850 is on stack ffffc90007cd8000, but NOT annotated.
> > > ------------[ cut here ]------------
> > > 1
> > > WARNING: lib/debugobjects.c:672 at debug_object_is_on_stack lib/debugobjects.c:672 [inline], CPU#0: syz-executor162/6029
> > > WARNING: lib/debugobjects.c:672 at lookup_object_or_alloc.part.0.cold+0x19/0x40 lib/debugobjects.c:705, CPU#0: syz-executor162/6029
> > > Modules linked in:
> > > CPU: 0 UID: 0 PID: 6029 Comm: syz-executor162 Not tainted syzkaller #0 PREEMPT(full)
> > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> > > RIP: 0010:debug_object_is_on_stack lib/debugobjects.c:672 [inline]
> > > RIP: 0010:lookup_object_or_alloc.part.0.cold+0x19/0x40 lib/debugobjects.c:705
> > > Code: c4 60 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 83 c5 01 89 2d a0 1f 7d 1a 4c 89 e6 48 c7 c7 c0 39 62 8c e8 21 ae eb ff 90 <0f> 0b 90 e9 82 31 fe 03 83 c5 01 89 2d 7f 1f 7d 1a 49 39 c4 73 da
> > > RSP: 0018:ffffc90007cdf6c0 EFLAGS: 00010082
> > > RAX: 0000000000000050 RBX: ffff88802cb1d738 RCX: 0000000000000000
> > > RDX: 0000000000000050 RSI: ffffffff81ea1339 RDI: fffff52000f9bec9
> > > RBP: 0000000000000001 R08: 0000000000000007 R09: 0000000000000000
> > > R10: 8000000000000001 R11: 0000000000000001 R12: ffffc90007cdf850
> > > R13: ffff888034204b00 R14: 0000000000000000 R15: 0000000000000000
> > > FS:  00005555811b5400(0000) GS:ffff8880d5b57000(0000) knlGS:0000000000000000
> > > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > CR2: 00005555811b8778 CR3: 000000002bbd8000 CR4: 0000000000352ef0
> > > Call Trace:
> > >  <TASK>
> > >  lookup_object_or_alloc lib/debugobjects.c:682 [inline]
> > >  __debug_object_init+0x2a9/0x3d0 lib/debugobjects.c:798
> > >  __init_work+0x51/0x60 kernel/workqueue.c:697
> > >  block2mtd_setup_defer+0xd7/0x1d0 drivers/mtd/devices/block2mtd.c:504
> > >  block2mtd_setup+0x9c/0x1e0 drivers/mtd/devices/block2mtd.c:529
> > >  param_attr_store+0x199/0x300 kernel/params.c:591
> > >  module_attr_store+0x58/0x80 kernel/params.c:906
> > >  sysfs_kf_write+0xf2/0x150 fs/sysfs/file.c:145
> > >  kernfs_fop_write_iter+0x3e0/0x5f0 fs/kernfs/file.c:345
> > >  iter_file_splice_write+0x830/0x10b0 fs/splice.c:736
> > >  do_splice_from fs/splice.c:936 [inline]
> > >  do_splice+0x109c/0x1fa0 fs/splice.c:1349
> > >  __do_splice+0x33b/0x370 fs/splice.c:1431
> > >  __do_sys_splice fs/splice.c:1634 [inline]
> > >  __se_sys_splice fs/splice.c:1616 [inline]
> > >  __x64_sys_splice+0x187/0x250 fs/splice.c:1616
> > >  do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
> > >  do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
> > >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> > > RIP: 0033:0x7fa1c31b3437
> > > Code: 48 89 fa 4c 89 df e8 98 1d 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
> > > RSP: 002b:00007ffce5a2ac20 EFLAGS: 00000202 ORIG_RAX: 0000000000000113
> > > RAX: ffffffffffffffda RBX: 00005555811b5400 RCX: 00007fa1c31b3437
> > > RDX: 0000000000000005 RSI: 0000000000000000 RDI: 0000000000000003
> > > RBP: 00007fa1c31ec0fe R08: 0000000000000026 R09: 0000000000000000
> > > R10: 0000000000000000 R11: 0000000000000202 R12: 00005555811b7770
> > > R13: 0000000000000026 R14: 00007ffce5a2aca0 R15: 0000000000000002
> > >  </TASK>
> > >
> > >
> > > Tested on:
> > >
> > > commit:         238650ef Merge tag 'powerpc-7.3-4' of git://git.kernel..
> > > git tree:       upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=143de115580000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=8c5c3949d762a91f
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=7cab6a19619f1b8efc00
> > > compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> > > patch:          https://syzkaller.appspot.com/x/patch.diff?x=17ade115580000
> > >
>
> > From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
> > From: Chris Roy <iam@thechris.in>
> > Date: Thu, 17 Sep 2026 00:00:00 +0000
> > Subject: [PATCH v2] mtd: block2mtd: defer device open out of param/sysfs write
> >
> > block2mtd_setup() opens the named block device (VFS path walk) while
> > still under param_lock and kernfs_fop_write_iter. When that write
> > arrives via splice, a pipe mutex is held as well. That nests under
> > locks already ordered the other way with overlay sb_writers /
> > ovl_i_mutex and triggers lockdep, for example:
> >
> >   sb_writers -> pipe -> kernfs/param -> ovl_i_mutex -> sb_writers
> >
> > Drop param_lock and run setup on a dedicated ordered workqueue so the
> > open is not nested under that stack. Keep the call synchronous with
> > wait_for_completion().
> >
> > Changes since v1:
> > - allocate work on the heap (v1 tripped DEBUG_OBJECTS_WORK)
> > - use a dedicated ordered workqueue instead of system_wq
> > - hold a module reference across the deferred open
> > - flush and destroy the workqueue before exit teardown
> > - serialize setup2 on the worker under block2mtd_mutex
> > - keep early-boot paramline updates under that mutex
> >
> > Reported-by: syzbot+7cab6a19619f1b8efc00@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=7cab6a19619f1b8efc00
> > Signed-off-by: Chris Roy <iam@thechris.in>
> > ---
> >  drivers/mtd/devices/block2mtd.c | 121 ++++++++++++++++++++----
> >  1 file changed, 103 insertions(+), 18 deletions(-)
>
> Did you forget the Assisted-by: tag?
>
> >
> > --- a/drivers/mtd/devices/block2mtd.c
> > +++ b/drivers/mtd/devices/block2mtd.c
> > @@ -27,6 +27,8 @@
> >  #include <linux/init.h>
> >  #include <linux/mtd/mtd.h>
> >  #include <linux/mutex.h>
> > +#include <linux/workqueue.h>
> > +#include <linux/completion.h>
> >  #include <linux/mount.h>
> >  #include <linux/slab.h>
> >  #include <linux/major.h>
> > @@ -45,6 +47,13 @@
> >
> >  /* Static info about the MTD, used in cleanup_module */
> >  static LIST_HEAD(blkmtd_device_list);
> > +/*
> > + * Serializes setup/teardown (including list updates). Never held by a
> > + * task that also holds param_lock / kernfs / pipe locks across a VFS open:
> > + * deferred setup runs on block2mtd_wq instead.
>
> Make the comments make sense please.  That's the problem of using a LLM :(
>
> thanks,
>
> greg k-h

[-- Attachment #2: 0001-mtd-block2mtd-defer-device-open-out-of-param-sysfs-w.patch --]
[-- Type: text/x-diff, Size: 5697 bytes --]

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Chris Roy <iam@thechris.in>
Date: Thu, 17 Sep 2026 00:00:00 +0000
Subject: [PATCH v3] mtd: block2mtd: defer device open out of param/sysfs write

block2mtd_setup() opens the named block device while still under
param_lock, and on the sysfs write path under kernfs (and possibly a
splice pipe lock). That nests VFS locking the wrong way relative to
overlayfs and trips lockdep.

Drop param_lock and run setup on a dedicated ordered workqueue. Keep
the call synchronous with wait_for_completion(). Allocate the work on
the heap so DEBUG_OBJECTS_WORK stays quiet.

Changes since v2:
- rewrite the new comments to match the rest of the file

Changes since v1:
- heap-allocated work (v1 tripped DEBUG_OBJECTS_WORK)
- dedicated ordered workqueue instead of system_wq
- module reference across the deferred open
- flush/destroy the workqueue before exit teardown
- serialize setup2 on the worker under block2mtd_mutex
- early-boot paramline updates under that mutex

Reported-by: syzbot+7cab6a19619f1b8efc00@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7cab6a19619f1b8efc00
Assisted-by: Mistral, Qwen
Signed-off-by: Chris Roy <iam@thechris.in>
---
 drivers/mtd/devices/block2mtd.c | 118 ++++++++++++++++++++-----
 1 file changed, 98 insertions(+), 20 deletions(-)

--- a/drivers/mtd/devices/block2mtd.c
+++ b/drivers/mtd/devices/block2mtd.c
@@ -27,6 +27,8 @@
 #include <linux/init.h>
 #include <linux/mtd/mtd.h>
 #include <linux/mutex.h>
+#include <linux/workqueue.h>
+#include <linux/completion.h>
 #include <linux/mount.h>
 #include <linux/slab.h>
 #include <linux/major.h>
@@ -45,6 +47,9 @@
 
 /* Static info about the MTD, used in cleanup_module */
 static LIST_HEAD(blkmtd_device_list);
+/* Protects blkmtd_device_list and early-boot paramline updates */
+static DEFINE_MUTEX(block2mtd_mutex);
+static struct workqueue_struct *block2mtd_wq;
 
 
 static struct page *page_read(struct address_space *mapping, pgoff_t index)
@@ -461,31 +466,89 @@
 	return 0;
 }
 
+struct block2mtd_setup_work {
+	struct work_struct work;
+	struct completion done;
+	char *val;
+	int ret;
+};
+
+static void block2mtd_setup_workfn(struct work_struct *work)
+{
+	struct block2mtd_setup_work *w =
+		container_of(work, struct block2mtd_setup_work, work);
+
+	mutex_lock(&block2mtd_mutex);
+	w->ret = block2mtd_setup2(w->val);
+	mutex_unlock(&block2mtd_mutex);
+	complete(&w->done);
+}
+
+/* Queue setup2 on block2mtd_wq; caller holds a module ref until return */
+static int block2mtd_setup_defer(const char *val)
+{
+	struct block2mtd_setup_work *w;
+	int ret;
+
+	if (!block2mtd_wq)
+		return -ENODEV;
+
+	w = kzalloc(sizeof(*w), GFP_KERNEL);
+	if (!w)
+		return -ENOMEM;
+
+	w->val = kstrdup(val, GFP_KERNEL);
+	if (!w->val) {
+		kfree(w);
+		return -ENOMEM;
+	}
+
+	init_completion(&w->done);
+	INIT_WORK(&w->work, block2mtd_setup_workfn);
+	queue_work(block2mtd_wq, &w->work);
+	wait_for_completion(&w->done);
+
+	ret = w->ret;
+	kfree(w->val);
+	kfree(w);
+	return ret;
+}
 
 static int block2mtd_setup(const char *val, const struct kernel_param *kp)
 {
-#ifdef MODULE
-	return block2mtd_setup2(val);
-#else
-	/* If more parameters are later passed in via
-	   /sys/module/block2mtd/parameters/block2mtd
-	   and block2mtd_init() has already been called,
-	   we can parse the argument now. */
-
-	if (block2mtd_init_called)
-		return block2mtd_setup2(val);
-
-	/* During early boot stage, we only save the parameters
-	   here. We must parse them later: if the param passed
-	   from kernel boot command line, block2mtd_setup() is
-	   called so early that it is not possible to resolve
-	   the device (even kmalloc() fails). Deter that work to
-	   block2mtd_setup2(). */
+	int ret = 0;
 
-	strscpy(block2mtd_paramline, val, sizeof(block2mtd_paramline));
+	if (!try_module_get(kp->mod))
+		return -ENODEV;
 
-	return 0;
+	/* Do not open a block device under param_lock */
+	kernel_param_unlock(kp->mod);
+
+#ifndef MODULE
+	mutex_lock(&block2mtd_mutex);
+	if (!block2mtd_init_called) {
+		/* Early boot: cannot resolve block devices yet. */
+		strscpy(block2mtd_paramline, val, sizeof(block2mtd_paramline));
+		mutex_unlock(&block2mtd_mutex);
+		kernel_param_lock(kp->mod);
+		module_put(kp->mod);
+		return 0;
+	}
+	mutex_unlock(&block2mtd_mutex);
 #endif
+
+	if (block2mtd_wq) {
+		ret = block2mtd_setup_defer(val);
+	} else {
+		/* Pre-init (e.g. insmod args): safe to run setup2 here */
+		mutex_lock(&block2mtd_mutex);
+		ret = block2mtd_setup2(val);
+		mutex_unlock(&block2mtd_mutex);
+	}
+
+	kernel_param_lock(kp->mod);
+	module_put(kp->mod);
+	return ret;
 }
 
 
@@ -496,10 +559,17 @@
 {
 	int ret = 0;
 
+	block2mtd_wq = alloc_ordered_workqueue("block2mtd", 0);
+	if (!block2mtd_wq)
+		return -ENOMEM;
+
 #ifndef MODULE
+	mutex_lock(&block2mtd_mutex);
 	if (strlen(block2mtd_paramline))
 		ret = block2mtd_setup2(block2mtd_paramline);
+	/* Avoid racing sysfs with the early paramline */
 	block2mtd_init_called = 1;
+	mutex_unlock(&block2mtd_mutex);
 #endif
 
 	return ret;
@@ -510,9 +580,16 @@
 {
 	struct list_head *pos, *next;
 
-	/* Remove the MTD devices */
+	if (block2mtd_wq) {
+		flush_workqueue(block2mtd_wq);
+		destroy_workqueue(block2mtd_wq);
+		block2mtd_wq = NULL;
+	}
+
+	mutex_lock(&block2mtd_mutex);
 	list_for_each_safe(pos, next, &blkmtd_device_list) {
 		struct block2mtd_dev *dev = list_entry(pos, typeof(*dev), list);
+
 		block2mtd_sync(&dev->mtd);
 		mtd_device_unregister(&dev->mtd);
 		mutex_destroy(&dev->write_mutex);
@@ -522,6 +599,7 @@
 		list_del(&dev->list);
 		block2mtd_free_device(dev);
 	}
+	mutex_unlock(&block2mtd_mutex);
 }
 
 late_initcall(block2mtd_init);

[-- Attachment #3: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+7cab6a19619f1b8efc00@syzkaller.appspotmail.com
Tested-by: syzbot+7cab6a19619f1b8efc00@syzkaller.appspotmail.com

Tested on:

commit:         238650ef Merge tag 'powerpc-7.3-4' of git://git.kernel..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=165358c9580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=8c5c3949d762a91f
dashboard link: https://syzkaller.appspot.com/bug?extid=7cab6a19619f1b8efc00
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=117a3bf9580000

Note: testing is done by a robot and is best-effort only.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Jörn Engel]

On Thu, Sep 17, 2026 at 01:28:22PM +0530, Chris Roy wrote:
>
>  drivers/mtd/devices/block2mtd.c | 118 ++++++++++++++++++++-----
>  1 file changed, 98 insertions(+), 20 deletions(-)
[...]
>  /* Static info about the MTD, used in cleanup_module */
>  static LIST_HEAD(blkmtd_device_list);
> +/* Protects blkmtd_device_list and early-boot paramline updates */
> +static DEFINE_MUTEX(block2mtd_mutex);
> +static struct workqueue_struct *block2mtd_wq;

This is just awful taste.  You are inside a file called "block2mtd".
The prefix to the mutex an workqueue add absolutely nothing.  Calling
them just plain "mutex" and "wq" would have been a better choice.

Good names should tell the human reader something.  What is the mutex
protecting?  What is the purpose of the workqueue?  Pick a name that
gives us some information like that, please!


You seem to have used AI to write this code, so the bad name choice was
presumably also done by AI.  But you are still associating your own good
name with the code.  You should try not to harm your good name by
letting things like this slide through unchallenged.

Jörn

--
Do not stop an army on its way home.
-- Sun Tzu

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

AW: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Richard Weinberger]

Am Thu, Sep 17, 2026, 20:16 schrieb Jörn Engel <joern@barelysecure.org>:
> On Thu, Sep 17, 2026 at 01:28:22PM +0530, Chris Roy wrote:
> >
> >  drivers/mtd/devices/block2mtd.c | 118 ++++++++++++++++++++-----
> >  1 file changed, 98 insertions(+), 20 deletions(-)
> [...]
> >  /* Static info about the MTD, used in cleanup_module */
> >  static LIST_HEAD(blkmtd_device_list);
> > +/* Protects blkmtd_device_list and early-boot paramline updates */
> > +static DEFINE_MUTEX(block2mtd_mutex);
> > +static struct workqueue_struct *block2mtd_wq;
> 
> This is just awful taste.  You are inside a file called "block2mtd".
> The prefix to the mutex an workqueue add absolutely nothing.  Calling
> them just plain "mutex" and "wq" would have been a better choice.
> 
> Good names should tell the human reader something.  What is the mutex
> protecting?  What is the purpose of the workqueue?  Pick a name that
> gives us some information like that, please!
> 
> 
> You seem to have used AI to write this code, so the bad name choice was
> presumably also done by AI.  But you are still associating your own good
> name with the code.  You should try not to harm your good name by
> letting things like this slide through unchallenged.

While we're here, maybe it's time to add a decent configfs interface to
this driver instead of configuring through module parameters.
That way also multiple instances are possible.

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Chris Roy]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

On Sat, Sep 19, 2026, Jörn Engel wrote:
> This is just awful taste. You are inside a file called "block2mtd".
> The prefix to the mutex an workqueue add absolutely nothing.
> [...]
> Pick a name that gives us some information like that, please!

Agreed. v4 renames to list_mutex and setup_wq. Additionally, I fixed
tag formatting and removed a redundant if-guard.

On Sat, Sep 19, 2026, Richard Weinberger wrote:
> While we're here, maybe it's time to add a decent configfs interface
> to this driver instead of configuring through module parameters.

I will look at a configfs interface as a follow up once this
lockdep fix lands.

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master

Regards,
Chris

[-- Attachment #2: 0001-mtd-block2mtd-defer-device-open-out-of-param-sysfs-w.patch --]
[-- Type: text/x-patch, Size: 6081 bytes --]

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Chris Roy <iam@thechris.in>
Date: Sat, 19 Sep 2026 00:00:00 +0000
Subject: [PATCH v4] mtd: block2mtd: defer device open out of param/sysfs write

block2mtd_setup() opens the named block device while still under
param_lock, and on the sysfs write path under kernfs (and possibly a
splice pipe lock). That nests VFS locking the wrong way relative to
overlayfs and trips lockdep.

Drop param_lock and run setup on a dedicated ordered workqueue. Keep
the call synchronous with wait_for_completion(). Allocate the work on
the heap so DEBUG_OBJECTS_WORK stays quiet.

Changes since v3:
- rename list_mutex / setup_wq to say what they are for
- tidy new comments
- fix Assisted-by tag format (checkpatch: AGENT_NAME:MODEL_VERSION)
- drop redundant setup_wq check in block2mtd_setup_defer() (the
  sole caller already gates on it)

Changes since v2:
- rewrite the new comments to match the rest of the file
- add Assisted-by

Changes since v1:
- heap-allocated work (v1 tripped DEBUG_OBJECTS_WORK)
- dedicated ordered workqueue instead of system_wq
- module reference across the deferred open
- flush/destroy the workqueue before exit teardown
- serialize setup2 on the worker under list_mutex
- early-boot paramline updates under that mutex

Reported-by: syzbot+7cab6a19619f1b8efc00@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7cab6a19619f1b8efc00
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Chris Roy <iam@thechris.in>
---
 drivers/mtd/devices/block2mtd.c | 116 ++++++++++++++++++++++++++++++++--------
 1 file changed, 95 insertions(+), 21 deletions(-)

diff --git a/drivers/mtd/devices/block2mtd.c b/drivers/mtd/devices/block2mtd.c
index 03e80b2..a540089 100644
--- a/drivers/mtd/devices/block2mtd.c
+++ b/drivers/mtd/devices/block2mtd.c
@@ -27,6 +27,8 @@
 #include <linux/init.h>
 #include <linux/mtd/mtd.h>
 #include <linux/mutex.h>
+#include <linux/workqueue.h>
+#include <linux/completion.h>
 #include <linux/mount.h>
 #include <linux/slab.h>
 #include <linux/major.h>
@@ -45,6 +47,9 @@ struct block2mtd_dev {

 /* Static info about the MTD, used in cleanup_module */
 static LIST_HEAD(blkmtd_device_list);
+/* Protects blkmtd_device_list and early-boot paramline updates */
+static DEFINE_MUTEX(list_mutex);
+static struct workqueue_struct *setup_wq;


 static struct page *page_read(struct address_space *mapping, pgoff_t index)
@@ -461,31 +466,85 @@ static int block2mtd_setup2(const char *val)
 	return 0;
 }

+struct block2mtd_setup_work {
+	struct work_struct work;
+	struct completion done;
+	char *val;
+	int ret;
+};
+
+static void block2mtd_setup_workfn(struct work_struct *work)
+{
+	struct block2mtd_setup_work *w =
+		container_of(work, struct block2mtd_setup_work, work);
+
+	mutex_lock(&list_mutex);
+	w->ret = block2mtd_setup2(w->val);
+	mutex_unlock(&list_mutex);
+	complete(&w->done);
+}
+
+/* Runs block2mtd_setup2() on setup_wq, blocking until it completes */
+static int block2mtd_setup_defer(const char *val)
+{
+	struct block2mtd_setup_work *w;
+	int ret;
+
+	w = kzalloc(sizeof(*w), GFP_KERNEL);
+	if (!w)
+		return -ENOMEM;
+
+	w->val = kstrdup(val, GFP_KERNEL);
+	if (!w->val) {
+		kfree(w);
+		return -ENOMEM;
+	}
+
+	init_completion(&w->done);
+	INIT_WORK(&w->work, block2mtd_setup_workfn);
+	queue_work(setup_wq, &w->work);
+	wait_for_completion(&w->done);
+
+	ret = w->ret;
+	kfree(w->val);
+	kfree(w);
+	return ret;
+}

 static int block2mtd_setup(const char *val, const struct kernel_param *kp)
 {
-#ifdef MODULE
-	return block2mtd_setup2(val);
-#else
-	/* If more parameters are later passed in via
-	   /sys/module/block2mtd/parameters/block2mtd
-	   and block2mtd_init() has already been called,
-	   we can parse the argument now. */
-
-	if (block2mtd_init_called)
-		return block2mtd_setup2(val);
-
-	/* During early boot stage, we only save the parameters
-	   here. We must parse them later: if the param passed
-	   from kernel boot command line, block2mtd_setup() is
-	   called so early that it is not possible to resolve
-	   the device (even kmalloc() fails). Deter that work to
-	   block2mtd_setup2(). */
+	int ret = 0;

-	strscpy(block2mtd_paramline, val, sizeof(block2mtd_paramline));
+	if (!try_module_get(kp->mod))
+		return -ENODEV;

-	return 0;
+	kernel_param_unlock(kp->mod);
+
+#ifndef MODULE
+	mutex_lock(&list_mutex);
+	if (!block2mtd_init_called) {
+		/* Cannot resolve block devices this early */
+		strscpy(block2mtd_paramline, val, sizeof(block2mtd_paramline));
+		mutex_unlock(&list_mutex);
+		kernel_param_lock(kp->mod);
+		module_put(kp->mod);
+		return 0;
+	}
+	mutex_unlock(&list_mutex);
 #endif
+
+	if (setup_wq) {
+		ret = block2mtd_setup_defer(val);
+	} else {
+		/* Not yet deferred to setup_wq; safe to call setup2 directly */
+		mutex_lock(&list_mutex);
+		ret = block2mtd_setup2(val);
+		mutex_unlock(&list_mutex);
+	}
+
+	kernel_param_lock(kp->mod);
+	module_put(kp->mod);
+	return ret;
 }


@@ -496,10 +555,17 @@ static int __init block2mtd_init(void)
 {
 	int ret = 0;

+	setup_wq = alloc_ordered_workqueue("block2mtd", 0);
+	if (!setup_wq)
+		return -ENOMEM;
+
 #ifndef MODULE
+	mutex_lock(&list_mutex);
 	if (strlen(block2mtd_paramline))
 		ret = block2mtd_setup2(block2mtd_paramline);
+	/* Avoid racing sysfs with the early paramline */
 	block2mtd_init_called = 1;
+	mutex_unlock(&list_mutex);
 #endif

 	return ret;
@@ -510,9 +576,16 @@ static void block2mtd_exit(void)
 {
 	struct list_head *pos, *next;

-	/* Remove the MTD devices */
+	if (setup_wq) {
+		flush_workqueue(setup_wq);
+		destroy_workqueue(setup_wq);
+		setup_wq = NULL;
+	}
+
+	mutex_lock(&list_mutex);
 	list_for_each_safe(pos, next, &blkmtd_device_list) {
 		struct block2mtd_dev *dev = list_entry(pos, typeof(*dev), list);
+
 		block2mtd_sync(&dev->mtd);
 		mtd_device_unregister(&dev->mtd);
 		mutex_destroy(&dev->write_mutex);
@@ -522,6 +595,7 @@ static void block2mtd_exit(void)
 		list_del(&dev->list);
 		block2mtd_free_device(dev);
 	}
+	mutex_unlock(&list_mutex);
 }

 late_initcall(block2mtd_init);
--
2.43.0

[-- Attachment #3: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+7cab6a19619f1b8efc00@syzkaller.appspotmail.com
Tested-by: syzbot+7cab6a19619f1b8efc00@syzkaller.appspotmail.com

Tested on:

commit:         40288c92 Merge tag 'drm-fixes-2026-09-19' of https://g..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=169d2ff9580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=84649d3ff8d550cb
dashboard link: https://syzkaller.appspot.com/bug?extid=7cab6a19619f1b8efc00
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=11b52ff9580000

Note: testing is done by a robot and is best-effort only.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Jörn Engel]

On Sat, Sep 19, 2026 at 02:22:15PM +0530, Chris Roy wrote:
> 
> +struct block2mtd_setup_work {
> +	struct work_struct work;
> +	struct completion done;
> +	char *val;
> +	int ret;
> +};

Finding good names is probably a fetish of mine, so "val" is mildly
disturbing to me.  It's not an objectively bad name, just something
where I'd spend another five minutes trying to come up with something
better.

> +/* Runs block2mtd_setup2() on setup_wq, blocking until it completes */
> +static int block2mtd_setup_defer(const char *val)
> +{
> +	struct block2mtd_setup_work *w;
> +	int ret;
> +
> +	w = kzalloc(sizeof(*w), GFP_KERNEL);
> +	if (!w)
> +		return -ENOMEM;

Is this check necessary?  I'm in the camp of "malloc should never return
NULL".  That condition is so rare that it is effectively impossible to
trust callers with error handling.  So the right approach is to crash
(or kernel panic here) instead of returning an error.

Looking into sources I see this:
static inline void *kzalloc(size_t s, gfp_t gfp)
> {
> 	void *p = kmalloc(s, gfp);
> 
> 	memset(p, 0, s);
> 	return p;
> }

We have at least one example of explicitly not checking the return
value.  But we have other prominent examples of checking as well.  Looks
like the kernel is still undecided whether checks are necessary or not.

> -	return block2mtd_setup2(val);
...
> -		return block2mtd_setup2(val);
...
> +		ret = block2mtd_setup2(val);
...
>  		ret = block2mtd_setup2(block2mtd_paramline);

That's quite a few calls to the same function.  If setup gets that
complicated, that's a strong indication that we're doing things wrong.
Typically we get into such a mess one well-intentioned change at a time.
Find a bug, fix it by adding another caller, repeat.

It isn't obvious how we could improve things.  Sometimes it's lack of
infrastructure and the entire complicated setup-dance should be moved to
common code.  Driver can then call a single function to deal with
everything.

But if there's only a single driver using such infrastructure, maybe the
driver is doing things wrong and should copy whatever other drivers are
doing.  The problem shouldn't be unique to a single driver, so we should
find the best solution and then use it everywhere.

I don't know the correct answer here.  If you feel motivated to dig
deeper, please do!  If not, I'd rather leave the mess in place than come
up with a half-hearted attempt of a solution.

Jörn

--
You cannot suppose that Moliere ever troubled himself to be original in the
matter of ideas. You cannot suppose that the stories he tells in his plays
have never been told before. They were culled, as you very well know.
-- Andre-Louis Moreau in Scarabouche

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Chris Roy]

On Sat, Sep 19, 2026, Jörn Engel wrote:
> Finding good names is probably a fetish of mine, so "val" is mildly
> disturbing to me. [...]

I have a similar pet peeve in my domain. I kept "val" since
it mirrors block2mtd_setup2()'s own "val" parameter
(the raw <dev>[,[<erasesize>][,<label>]]), so I kept it for
consistency with the existing call chain. I had considered
"spec" but probably it would have been similarly unimaginative.

> Is this check necessary? [...] Looks like the kernel is still
> undecided whether checks are necessary or not.

I will keep it. kzalloc()/kstrdup() under plain GFP_KERNEL can still
return NULL under real memory pressure (no __GFP_NOFAIL here), and
dropping it would be inconsistent with the kstrdup() check two lines
below.

> That's quite a few calls to the same function. [...] If you feel
> motivated to dig deeper, please do! If not, I'd rather leave the
> mess in place than come up with a half-hearted attempt of a
> solution.

True. It is accretion. I'd rather not bolt a redesign onto this fix.
However, I can look at setup2()'s callers as a separate effort.

Regards,
- Chris

"But how could you live and have no story to tell?"

On Sat, 19 Sept 2026 at 20:16, Jörn Engel <joern@barelysecure.org> wrote:
>
> On Sat, Sep 19, 2026 at 02:22:15PM +0530, Chris Roy wrote:
> >
> > +struct block2mtd_setup_work {
> > +     struct work_struct work;
> > +     struct completion done;
> > +     char *val;
> > +     int ret;
> > +};
>
> Finding good names is probably a fetish of mine, so "val" is mildly
> disturbing to me.  It's not an objectively bad name, just something
> where I'd spend another five minutes trying to come up with something
> better.
>
> > +/* Runs block2mtd_setup2() on setup_wq, blocking until it completes */
> > +static int block2mtd_setup_defer(const char *val)
> > +{
> > +     struct block2mtd_setup_work *w;
> > +     int ret;
> > +
> > +     w = kzalloc(sizeof(*w), GFP_KERNEL);
> > +     if (!w)
> > +             return -ENOMEM;
>
> Is this check necessary?  I'm in the camp of "malloc should never return
> NULL".  That condition is so rare that it is effectively impossible to
> trust callers with error handling.  So the right approach is to crash
> (or kernel panic here) instead of returning an error.
>
> Looking into sources I see this:
> static inline void *kzalloc(size_t s, gfp_t gfp)
> > {
> >       void *p = kmalloc(s, gfp);
> >
> >       memset(p, 0, s);
> >       return p;
> > }
>
> We have at least one example of explicitly not checking the return
> value.  But we have other prominent examples of checking as well.  Looks
> like the kernel is still undecided whether checks are necessary or not.
>
> > -     return block2mtd_setup2(val);
> ...
> > -             return block2mtd_setup2(val);
> ...
> > +             ret = block2mtd_setup2(val);
> ...
> >               ret = block2mtd_setup2(block2mtd_paramline);
>
> That's quite a few calls to the same function.  If setup gets that
> complicated, that's a strong indication that we're doing things wrong.
> Typically we get into such a mess one well-intentioned change at a time.
> Find a bug, fix it by adding another caller, repeat.
>
> It isn't obvious how we could improve things.  Sometimes it's lack of
> infrastructure and the entire complicated setup-dance should be moved to
> common code.  Driver can then call a single function to deal with
> everything.
>
> But if there's only a single driver using such infrastructure, maybe the
> driver is doing things wrong and should copy whatever other drivers are
> doing.  The problem shouldn't be unique to a single driver, so we should
> find the best solution and then use it everywhere.
>
> I don't know the correct answer here.  If you feel motivated to dig
> deeper, please do!  If not, I'd rather leave the mess in place than come
> up with a half-hearted attempt of a solution.
>
> Jörn
>
> --
> You cannot suppose that Moliere ever troubled himself to be original in the
> matter of ideas. You cannot suppose that the stories he tells in his plays
> have never been told before. They were culled, as you very well know.
> -- Andre-Louis Moreau in Scarabouche

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Jörn Engel]

On Sat, Sep 19, 2026 at 08:58:51PM +0530, Chris Roy wrote:
> 
> I'd rather not bolt a redesign onto this fix.

Good decision!

> > Is this check necessary? [...] Looks like the kernel is still
> > undecided whether checks are necessary or not.
> 
> I will keep it. kzalloc()/kstrdup() under plain GFP_KERNEL can still
> return NULL under real memory pressure (no __GFP_NOFAIL here), and
> dropping it would be inconsistent with the kstrdup() check two lines
> below.

My foggy mind is slowly waking up.  GFP_ATOMIC can return NULL.  If
you're trying to allocate memory from an interrupt handler or similar,
you cannot afford to wait for memory reclaim to happen.  Those calls
definitely need a check and a reasonable plan what to do in case of
failure.

GFP_KERNEL should be able to block and wait, so there really is no
excuse for kmalloc to return NULL or for the callers to need a check.

But your decision of not pulling too many decisions into a single patch
is still a good decision.  Even if my logic is sound, removing checks
from kmalloc callers should be a separate effort.

Jörn

--
I don't understand it. Nobody does.
-- Richard P. Feynman

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Miquel Raynal]

Hi Jörn,

>> > Is this check necessary? [...] Looks like the kernel is still
>> > undecided whether checks are necessary or not.
>> 
>> I will keep it. kzalloc()/kstrdup() under plain GFP_KERNEL can still
>> return NULL under real memory pressure (no __GFP_NOFAIL here), and
>> dropping it would be inconsistent with the kstrdup() check two lines
>> below.
>
> My foggy mind is slowly waking up.  GFP_ATOMIC can return NULL.  If
> you're trying to allocate memory from an interrupt handler or similar,
> you cannot afford to wait for memory reclaim to happen.  Those calls
> definitely need a check and a reasonable plan what to do in case of
> failure.
>
> GFP_KERNEL should be able to block and wait, so there really is no
> excuse for kmalloc to return NULL or for the callers to need a check.
>
> But your decision of not pulling too many decisions into a single patch
> is still a good decision.  Even if my logic is sound, removing checks
> from kmalloc callers should be a separate effort.

Not saying this would be a bad move, it would be highly inconsistent
with the current code base. Every single allocation in the kernel is
checked. Such a change, without a documented and agreed upon method,
would lead to dozens fuzzing AIs sending patches to add the "missing"
check.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Jörn Engel]

Hello Miquèl

On Sun, Sep 20, 2026 at 02:52:18PM +0200, Miquel Raynal wrote:
> 
> Not saying this would be a bad move, it would be highly inconsistent
> with the current code base. Every single allocation in the kernel is
> checked. Such a change, without a documented and agreed upon method,
> would lead to dozens fuzzing AIs sending patches to add the "missing"
> check.

If your argument is that such a change would be inappropriate for the
patch in question, I totally agree with you.

I would disagree with an argument of "we should do the wrong thing for
the sake of consistency".  If indeed it is the wrong thing, we should
stop doing it.  Then we can regain consistency by not doing the wrong
thing anywhere.  In other words, consistency is irrelevant.  The only
question should be whether such a change is right or wrong.

There is also the practical consideration that changing the kmalloc
interface will lead to thousands of changes throughout the kernel and
requires a large time commitment from someone.  If nobody volunteers to
be that someone, it might still be better to stick with the status quo
for now.


So making an entirely theoretical "if I were king for a day" kind of
argument, I don't think GFP_KERNEL allocations should have to check for
failure.  Neither should userspace callers to malloc.  An interface that
frequently returns errors is pretty safe, as callers with broken error
handling are quickly detected and fixes.  An interface that almost never
returns errors is dangerous, as broken error handling in callers becomes
common and will eventually lead to bizarre hard-to-reproduce failures.

One of my roles in my last job was to fix userspace malloc and one of my
fixes was to ensure it would never return an allocation failure.  If it
returned, the caller received what it requested.  If that wasn't
possible, the process would crash.  A crashing process isn't exactly
desired, but it beats unpredictable behavior triggered by broken error
handlers.  And dealing with a single error path costs significantly less
cognitive effort than dealing with thousands of error handlers
everywhere in the code base.

Anyway, since I am not volunteering to spend a significant chunk of my
time, this is just the opinion of someone that doesn't matter.  Feel
free to reject it.

Jörn

--
Why do musicians compose symphonies and poets write poems?
They do it because life wouldn't have any meaning for them if they didn't.
That's why I draw cartoons.  It's my life.
-- Charles Shultz

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Chris Roy]

#syz set subsystems: mtd


Regards,
- Chris

"But how could you live and have no story to tell?"

On Sun, 20 Sept 2026 at 21:50, Jörn Engel <joern@barelysecure.org> wrote:
>
> Hello Miquèl
>
> On Sun, Sep 20, 2026 at 02:52:18PM +0200, Miquel Raynal wrote:
> >
> > Not saying this would be a bad move, it would be highly inconsistent
> > with the current code base. Every single allocation in the kernel is
> > checked. Such a change, without a documented and agreed upon method,
> > would lead to dozens fuzzing AIs sending patches to add the "missing"
> > check.
>
> If your argument is that such a change would be inappropriate for the
> patch in question, I totally agree with you.
>
> I would disagree with an argument of "we should do the wrong thing for
> the sake of consistency".  If indeed it is the wrong thing, we should
> stop doing it.  Then we can regain consistency by not doing the wrong
> thing anywhere.  In other words, consistency is irrelevant.  The only
> question should be whether such a change is right or wrong.
>
> There is also the practical consideration that changing the kmalloc
> interface will lead to thousands of changes throughout the kernel and
> requires a large time commitment from someone.  If nobody volunteers to
> be that someone, it might still be better to stick with the status quo
> for now.
>
>
> So making an entirely theoretical "if I were king for a day" kind of
> argument, I don't think GFP_KERNEL allocations should have to check for
> failure.  Neither should userspace callers to malloc.  An interface that
> frequently returns errors is pretty safe, as callers with broken error
> handling are quickly detected and fixes.  An interface that almost never
> returns errors is dangerous, as broken error handling in callers becomes
> common and will eventually lead to bizarre hard-to-reproduce failures.
>
> One of my roles in my last job was to fix userspace malloc and one of my
> fixes was to ensure it would never return an allocation failure.  If it
> returned, the caller received what it requested.  If that wasn't
> possible, the process would crash.  A crashing process isn't exactly
> desired, but it beats unpredictable behavior triggered by broken error
> handlers.  And dealing with a single error path costs significantly less
> cognitive effort than dealing with thousands of error handlers
> everywhere in the code base.
>
> Anyway, since I am not volunteering to spend a significant chunk of my
> time, this is just the opinion of someone that doesn't matter.  Feel
> free to reject it.
>
> Jörn
>
> --
> Why do musicians compose symphonies and poets write poems?
> They do it because life wouldn't have any meaning for them if they didn't.
> That's why I draw cartoons.  It's my life.
> -- Charles Shultz

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: AW: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Jörn Engel]

I added Adarsh Das, who also attempted to fix this bug.

On Sat, Sep 19, 2026 at 07:42:25AM +0000, Richard Weinberger wrote:
> 
> While we're here, maybe it's time to add a decent configfs interface to
> this driver instead of configuring through module parameters.
> That way also multiple instances are possible.

I honestly wonder whether this driver has any production users.  It is
somewhat useful for developers that want to simulate hardware they don't
have.  But beyond that?

Anyway, I have two deeper review questions as well.

One, afaics block2mtd predates overlayfs.  If the bug requires the
interaction of both, it is overlayfs that introduced the bug.  So why do
we fix it by modifying block2mtd?  Is that really the appropriate way to
fix it?

Two, we fix the deadlock by adding a second thread (via workqueue).  But
to keep synchronous behavior we end up blocking until the second thread
has finished.  Does the blocking behavior recreate a circular dependency
and therefore a deadlock?  If not, why not?

Jörn

--
Prosperity makes friends, adversity tries them.
-- Publilius Syrus

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

AW: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Richard Weinberger]

Am Sat, Sep 19, 2026, 16:22 schrieb Jörn Engel <joern@barelysecure.org>:
> I added Adarsh Das, who also attempted to fix this bug.
> 
> On Sat, Sep 19, 2026 at 07:42:25AM +0000, Richard Weinberger wrote:
> > 
> > While we're here, maybe it's time to add a decent configfs interface to
> > this driver instead of configuring through module parameters.
> > That way also multiple instances are possible.
> 
> I honestly wonder whether this driver has any production users.  It is
> somewhat useful for developers that want to simulate hardware they don't
> have.  But beyond that?

IMHO testing is the only use case. I use it regularly.

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Chris Roy]

On Sat, Sep 19, 2026, Richard Weinberger wrote:
> While we're here, maybe it's time to add a decent configfs interface to
> this driver instead of configuring through module parameters.
> That way also multiple instances are possible.
>
> IMHO testing is the only use case. I use it regularly.

I would love to look at this if you think it's worth the added
complexity. A couple of design questions before I start
on anything:

- Does configfs coexist with the existing block2mtd= module param
  (for early-boot/cmdline compatibility), or replace it outright?

- For multiple instances, would a configfs group per device (backing
  path, erase size, label) match what you had in mind?

Can sketch an RFC-style doc once I have a sense of the above.

Regards,
Chris

On Sat, 19 Sept 2026 at 19:58, Richard Weinberger <richard@nod.at> wrote:
>
> Am Sat, Sep 19, 2026, 16:22 schrieb Jörn Engel <joern@barelysecure.org>:
> > I added Adarsh Das, who also attempted to fix this bug.
> >
> > On Sat, Sep 19, 2026 at 07:42:25AM +0000, Richard Weinberger wrote:
> > >
> > > While we're here, maybe it's time to add a decent configfs interface to
> > > this driver instead of configuring through module parameters.
> > > That way also multiple instances are possible.
> >
> > I honestly wonder whether this driver has any production users.  It is
> > somewhat useful for developers that want to simulate hardware they don't
> > have.  But beyond that?
>
> IMHO testing is the only use case. I use it regularly.
>
> Thanks,
> //richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

AW: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Richard Weinberger]

Am Sat, Sep 19, 2026, 16:44 schrieb Chris Roy <iam@thechris.in>:

> On Sat, Sep 19, 2026, Richard Weinberger wrote:
> > While we're here, maybe it's time to add a decent configfs interface to
> > this driver instead of configuring through module parameters.
> > That way also multiple instances are possible.
> >
> > IMHO testing is the only use case. I use it regularly.
> 
> I would love to look at this if you think it's worth the added
> complexity. A couple of design questions before I start
> on anything:
> 
> - Does configfs coexist with the existing block2mtd= module param
>   (for early-boot/cmdline compatibility), or replace it outright?

Keeping the module parameters is not a hard requirement but would be nice.
Ideally, the module parameters prove an initial configfs setting. 

> - For multiple instances, would a configfs group per device (backing
>   path, erase size, label) match what you had in mind?
>

Yes. See how nvmet uses configfs. A similar, but simpler, approach
will do it for block2mtd too.

> Can sketch an RFC-style doc once I have a sense of the above.

Sounds good.

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)

[Chris Roy]

Hi Richard

> Keeping the module parameters is not a hard requirement but would be nice.
> Ideally, the module parameters prove an initial configfs setting.
> ...
> Yes. See how nvmet uses configfs. A similar, but simpler, approach
> will do it for block2mtd too.

I have encountered some bugs with the sashiko bot. So, this gives me
the perfect opportunity to
re-design with your inputs and propose an RFC-style doc including a
bigger patch within the next
day.

Regards,
- Chris

"But how could you live and have no story to tell?"

On Mon, 21 Sept 2026 at 02:39, Richard Weinberger <richard@nod.at> wrote:
>
> Am Sat, Sep 19, 2026, 16:44 schrieb Chris Roy <iam@thechris.in>:
>
> > On Sat, Sep 19, 2026, Richard Weinberger wrote:
> > > While we're here, maybe it's time to add a decent configfs interface to
> > > this driver instead of configuring through module parameters.
> > > That way also multiple instances are possible.
> > >
> > > IMHO testing is the only use case. I use it regularly.
> >
> > I would love to look at this if you think it's worth the added
> > complexity. A couple of design questions before I start
> > on anything:
> >
> > - Does configfs coexist with the existing block2mtd= module param
> >   (for early-boot/cmdline compatibility), or replace it outright?
>
> Keeping the module parameters is not a hard requirement but would be nice.
> Ideally, the module parameters prove an initial configfs setting.
>
> > - For multiple instances, would a configfs group per device (backing
> >   path, erase size, label) match what you had in mind?
> >
>
> Yes. See how nvmet uses configfs. A similar, but simpler, approach
> will do it for block2mtd too.
>
> > Can sketch an RFC-style doc once I have a sense of the above.
>
> Sounds good.
>
> Thanks,
> //richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/