* [PATCH] fs: jffs2: fix possible sleep-in-atomic-context bugs
@ 2019-12-17 13:51 ` Jia-Ju Bai
0 siblings, 0 replies; 4+ messages in thread
From: Jia-Ju Bai @ 2019-12-17 13:51 UTC (permalink / raw)
To: dwmw2, richard; +Cc: Jia-Ju Bai, linux-mtd, linux-kernel
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
fs/jffs2/wbuf.c, 164:
jffs2_prealloc_raw_node_refs in jffs2_block_refile
fs/jffs2/wbuf.c, 291:
jffs2_block_refile in jffs2_wbuf_recover
fs/jffs2/wbuf.c, 287:
spin_lock in jffs2_wbuf_recover
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
fs/jffs2/wbuf.c, 164:
jffs2_prealloc_raw_node_refs in jffs2_block_refile
fs/jffs2/wbuf.c, 927:
jffs2_block_refile in jffs2_flash_writev
fs/jffs2/wbuf.c, 924:
spin_lock in jffs2_flash_writev
kmem_cache_alloc(GFP_KERNEL) can sleep at runtime.
To fix these possible bugs, GFP_KERNEL is replaced with GFP_ATOMIC for
kmem_cache_alloc().
These bugs are found by a static analysis tool STCheck written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
fs/jffs2/malloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/jffs2/malloc.c b/fs/jffs2/malloc.c
index ce1189793288..66496ef09716 100644
--- a/fs/jffs2/malloc.c
+++ b/fs/jffs2/malloc.c
@@ -185,7 +185,7 @@ static struct jffs2_raw_node_ref *jffs2_alloc_refblock(void)
{
struct jffs2_raw_node_ref *ret;
- ret = kmem_cache_alloc(raw_node_ref_slab, GFP_KERNEL);
+ ret = kmem_cache_alloc(raw_node_ref_slab, GFP_ATOMIC);
if (ret) {
int i = 0;
for (i=0; i < REFS_PER_BLOCK; i++) {
--
2.17.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 4+ messages in thread* [PATCH] fs: jffs2: fix possible sleep-in-atomic-context bugs
@ 2019-12-17 13:51 ` Jia-Ju Bai
0 siblings, 0 replies; 4+ messages in thread
From: Jia-Ju Bai @ 2019-12-17 13:51 UTC (permalink / raw)
To: dwmw2, richard; +Cc: linux-mtd, linux-kernel, Jia-Ju Bai
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
fs/jffs2/wbuf.c, 164:
jffs2_prealloc_raw_node_refs in jffs2_block_refile
fs/jffs2/wbuf.c, 291:
jffs2_block_refile in jffs2_wbuf_recover
fs/jffs2/wbuf.c, 287:
spin_lock in jffs2_wbuf_recover
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
fs/jffs2/wbuf.c, 164:
jffs2_prealloc_raw_node_refs in jffs2_block_refile
fs/jffs2/wbuf.c, 927:
jffs2_block_refile in jffs2_flash_writev
fs/jffs2/wbuf.c, 924:
spin_lock in jffs2_flash_writev
kmem_cache_alloc(GFP_KERNEL) can sleep at runtime.
To fix these possible bugs, GFP_KERNEL is replaced with GFP_ATOMIC for
kmem_cache_alloc().
These bugs are found by a static analysis tool STCheck written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
fs/jffs2/malloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/jffs2/malloc.c b/fs/jffs2/malloc.c
index ce1189793288..66496ef09716 100644
--- a/fs/jffs2/malloc.c
+++ b/fs/jffs2/malloc.c
@@ -185,7 +185,7 @@ static struct jffs2_raw_node_ref *jffs2_alloc_refblock(void)
{
struct jffs2_raw_node_ref *ret;
- ret = kmem_cache_alloc(raw_node_ref_slab, GFP_KERNEL);
+ ret = kmem_cache_alloc(raw_node_ref_slab, GFP_ATOMIC);
if (ret) {
int i = 0;
for (i=0; i < REFS_PER_BLOCK; i++) {
--
2.17.1
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] fs: jffs2: fix possible sleep-in-atomic-context bugs
2019-12-17 13:51 ` Jia-Ju Bai
@ 2019-12-26 22:48 ` Al Viro
-1 siblings, 0 replies; 4+ messages in thread
From: Al Viro @ 2019-12-26 22:48 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: richard, dwmw2, linux-kernel, linux-mtd
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/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] fs: jffs2: fix possible sleep-in-atomic-context bugs
@ 2019-12-26 22:48 ` Al Viro
0 siblings, 0 replies; 4+ messages in thread
From: Al Viro @ 2019-12-26 22:48 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: dwmw2, richard, linux-mtd, linux-kernel
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-12-26 22:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2019-12-26 22:48 ` Al Viro
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.