From: "Jörn Engel" <joern@barelysecure.org>
To: Chris Roy <iam@thechris.in>
Cc: Richard Weinberger <richard@nod.at>,
Greg KH <gregkh@linuxfoundation.org>,
syzbot <syzbot+7cab6a19619f1b8efc00@syzkaller.appspotmail.com>,
dakr@kernel.org, driver-core@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
rafael@kernel.org, syzkaller-bugs@googlegroups.com,
linux-mtd@lists.infradead.org, miquel.raynal@bootlin.com,
vigneshr@ti.com, Adarsh Das <adarshdas950@gmail.com>
Subject: Re: [syzbot] [fs?] possible deadlock in ovl_create_object (2)
Date: Sat, 19 Sep 2026 07:45:57 -0700 [thread overview]
Message-ID: <aq6gJTYTpTr8sYPj@cashel.logfs.org> (raw)
In-Reply-To: <CAE2Bdm3FqBPAMxqKoz_h1cw+OXpm=LJHdJjsME_Jy966tqhq_A@mail.gmail.com>
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
next prev parent reply other threads:[~2026-09-19 14:46 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 15:19 syzbot
2026-09-12 13:12 ` syzbot
2026-09-16 19:48 ` Chris Roy
2026-09-16 21:37 ` Chris Roy
2026-09-16 21:52 ` syzbot
2026-09-17 6:44 ` Chris Roy
2026-09-17 6:59 ` syzbot
2026-09-17 7:33 ` Greg KH
2026-09-17 7:58 ` Chris Roy
2026-09-17 8:13 ` syzbot
2026-09-17 18:15 ` Jörn Engel
2026-09-19 7:42 ` AW: " Richard Weinberger
2026-09-19 8:52 ` Chris Roy
2026-09-19 9:07 ` syzbot
2026-09-19 14:45 ` Jörn Engel [this message]
2026-09-19 15:28 ` Chris Roy
2026-09-19 15:38 ` Jörn Engel
2026-09-20 12:52 ` Miquel Raynal
2026-09-20 16:19 ` Jörn Engel
2026-09-20 18:34 ` Chris Roy
2026-09-19 14:21 ` AW: " Jörn Engel
2026-09-19 14:28 ` Richard Weinberger
2026-09-19 14:44 ` Chris Roy
2026-09-20 21:09 ` AW: " Richard Weinberger
2026-09-20 21:13 ` Chris Roy
2026-09-20 18:51 ` [PATCH v4] mtd: block2mtd: defer device open out of param/sysfs write Chris Roy
2026-09-20 19:03 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aq6gJTYTpTr8sYPj@cashel.logfs.org \
--to=joern@barelysecure.org \
--cc=adarshdas950@gmail.com \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=iam@thechris.in \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=rafael@kernel.org \
--cc=richard@nod.at \
--cc=syzbot+7cab6a19619f1b8efc00@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®