From: Al Viro <viro@zeniv.linux.org.uk>
To: Jia-Ju Bai <baijiaju1990@gmail.com>
Cc: richard@nod.at, dwmw2@infradead.org,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org
Subject: Re: [PATCH] fs: jffs2: fix possible sleep-in-atomic-context bugs
Date: Thu, 26 Dec 2019 22:48:02 +0000 [thread overview]
Message-ID: <20191226224802.GR4203@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20191217135143.12875-1-baijiaju1990@gmail.com>
On Tue, Dec 17, 2019 at 09:51:43PM +0800, Jia-Ju Bai wrote:
> The filesystem may sleep while holding a spinlock.
> The function call path (from bottom to top) in Linux 4.19 is:
>
> fs/jffs2/malloc.c, 188:
> kmem_cache_alloc(GFP_KERNEL) in jffs2_alloc_refblock
> fs/jffs2/malloc.c, 221:
> jffs2_alloc_refblock in jffs2_prealloc_raw_node_refs
... gets called only if jeb->last_node is NULL. I've no idea
whether it is possible on those call chains and analysis is
certainly needed before applying that kind of patches.
It might very well be real, and certainly worth asking jffs2
folks to look into. But this kind of "defensive" fixes
is no good without understanding of the situation in the
code being (hopefully) fixed.
It's a good catch; even if there is a reason why we never
hit the blocking allocation in there, that reason should be
spelled out in the code. It isn't, and that can easily
grow into a bug even if it hasn't done so already.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@zeniv.linux.org.uk>
To: Jia-Ju Bai <baijiaju1990@gmail.com>
Cc: dwmw2@infradead.org, richard@nod.at,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fs: jffs2: fix possible sleep-in-atomic-context bugs
Date: Thu, 26 Dec 2019 22:48:02 +0000 [thread overview]
Message-ID: <20191226224802.GR4203@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20191217135143.12875-1-baijiaju1990@gmail.com>
On Tue, Dec 17, 2019 at 09:51:43PM +0800, Jia-Ju Bai wrote:
> The filesystem may sleep while holding a spinlock.
> The function call path (from bottom to top) in Linux 4.19 is:
>
> fs/jffs2/malloc.c, 188:
> kmem_cache_alloc(GFP_KERNEL) in jffs2_alloc_refblock
> fs/jffs2/malloc.c, 221:
> jffs2_alloc_refblock in jffs2_prealloc_raw_node_refs
... gets called only if jeb->last_node is NULL. I've no idea
whether it is possible on those call chains and analysis is
certainly needed before applying that kind of patches.
It might very well be real, and certainly worth asking jffs2
folks to look into. But this kind of "defensive" fixes
is no good without understanding of the situation in the
code being (hopefully) fixed.
It's a good catch; even if there is a reason why we never
hit the blocking allocation in there, that reason should be
spelled out in the code. It isn't, and that can easily
grow into a bug even if it hasn't done so already.
next prev parent reply other threads:[~2019-12-26 22:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-17 13:51 [PATCH] fs: jffs2: fix possible sleep-in-atomic-context bugs Jia-Ju Bai
2019-12-17 13:51 ` Jia-Ju Bai
2019-12-26 22:48 ` Al Viro [this message]
2019-12-26 22:48 ` Al Viro
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=20191226224802.GR4203@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=baijiaju1990@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.