lkml.org 
[lkml]   [2018]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[BUG] fs: jffs2: possible sleep-in-atomic-context bugs in jffs2_iget
Date
The kernel may sleep with holding a spinlock.

The function call paths (from bottom to top) in Linux-4.16 are:

[FUNC] schedule
fs/inode.c, 1916: schedule in __wait_on_freeing_inode
fs/inode.c, 826: __wait_on_freeing_inode in find_inode_fast
fs/inode.c, 1107: find_inode_fast in iget_locked
fs/jffs2/fs.c, 263: iget_locked in jffs2_iget
fs/jffs2/fs.c, 665: jffs2_iget in jffs2_gc_fetch_inode
fs/jffs2/wbuf.c, 505: jffs2_gc_fetch_inode in jffs2_wbuf_recover
fs/jffs2/wbuf.c, 462: spin_lock in jffs2_wbuf_recover

[FUNC] mutex_lock_nested
fs/jffs2/fs.c, 273: mutex_lock_nested in jffs2_iget
fs/jffs2/fs.c, 665: jffs2_iget in jffs2_gc_fetch_inode
fs/jffs2/wbuf.c, 505: jffs2_gc_fetch_inode in jffs2_wbuf_recover
fs/jffs2/wbuf.c, 462: spin_lock in jffs2_wbuf_recover

I do not find a good way to fix, so I only report.
Maybe the spinlock should be released before calling jffs2_iget(), and
then be acquired again.
This is found by my static analysis tool (DSAC).


Thanks,
Jia-Ju Bai

\
 
 \ /
  Last update: 2018-08-13 05:33    [W:0.016 / U:5.628 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site