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@xxxxxx> wrote:
>
> Am Sat, Sep 19, 2026, 16:44 schrieb Chris Roy <iam@xxxxxxxxxxx>:
>
> > 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