Deadlock issue in jffs2 (related to reverted patch "jffs2: Fix lock acquisition order bug in jffs2_write_begin")

[Bussery, Francois]

Hi,

I encountered same as the one that drive you to remove this patch (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/jffs2?id=157078f64b8a9cd7011b6b900b2f2498df850748)
Unfortunately, this patch solved some big deadlock issues in jffs2. So, my concern is that we return back to our initial issue.

So, do you have any update for this issue? May be the 2015 patch was just not suffisant. 
What I have noticed with this patch is that there is a deadlock between the write command and the sync command.

here the stack:

write command:

Call Trace:
[<8055d510>] __schedule+0x338/0x7d8
[<8055bd5c>] __mutex_lock_slowpath+0x170/0x2a0
[<8055bf1c>] mutex_lock+0x90/0x98
[<801fb428>] jffs2_reserve_space+0x5c/0x31c
[<801fe460>] jffs2_write_inode_range+0x84/0x364
[<801f83bc>] jffs2_write_end+0x16c/0x3b4
[<800ac530>] generic_file_buffered_write+0x188/0x2c0
[<800aecd0>] __generic_file_aio_write+0x280/0x5ec
[<800af0c4>] generic_file_aio_write+0x88/0x15c
[<800f738c>] do_sync_write+0xc4/0x13c
[<800f812c>] vfs_write+0xc4/0x16c
[<800f843c>] sys_write+0x4c/0xb4
[<80010e5c>] stack_done+0x20/0x40
[0]more>


fsync ioctl:
[<8055d510>] __schedule+0x338/0x7d8
[<8055db50>] io_schedule+0x94/0x138
[<800ad254>] sleep_on_page+0x10/0x20
[<8055b7a8>] __wait_on_bit_lock+0xe0/0x194
[<800ad238>] __lock_page+0x90/0x9c
[<800adc88>] do_read_cache_page+0x210/0x23c
[<800add04>] read_cache_page_async+0x20/0x2c
[<802050b0>] jffs2_gc_fetch_page+0x2c/0x80
[<8020131c>] jffs2_garbage_collect_live+0x55c/0xf8c
[<802021b0>] jffs2_garbage_collect_pass+0x464/0x894
[<80206e74>] jffs2_flush_wbuf_gc+0x98/0x174
[<801f8b60>] jffs2_fsync+0x60/0x88
[<801280a8>] vfs_fsync+0x50/0x5c


The pb is that the mutex is taken by the fsync cmd… and lock page by write cmd….
I’m wondering if we could lock the page in sync before locking the mutex api?