linux-ext4 - Re: Lockup in wait_transaction_locked under memory pressure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150630030207.GB14839@thunk.org>
Date:	Mon, 29 Jun 2015 23:02:07 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Dave Chinner <david@...morbit.com>
Cc:	Michal Hocko <mhocko@...e.cz>, Nikolay Borisov <kernel@...p.com>,
	linux-ext4@...r.kernel.org, Marian Marinov <mm@...com>
Subject: Re: Lockup in wait_transaction_locked under memory pressure

On Tue, Jun 30, 2015 at 11:52:06AM +1000, Dave Chinner wrote:
> Yes, and looks at the caller path....
> 
> > >  #8 [ffff88177374af50] shrink_inactive_list at ffffffff81135845
> > >  #9 [ffff88177374b060] shrink_lruvec at ffffffff81135ead
> > > #10 [ffff88177374b150] shrink_zone at ffffffff811360c3
> > > #11 [ffff88177374b220] shrink_zones at ffffffff81136eff
> > > #12 [ffff88177374b2a0] do_try_to_free_pages at ffffffff8113712f
> > > #13 [ffff88177374b300] try_to_free_mem_cgroup_pages at ffffffff811372be
> > > #14 [ffff88177374b380] try_charge at ffffffff81189423
> > > #15 [ffff88177374b430] mem_cgroup_try_charge at ffffffff8118c6f5
> > > #16 [ffff88177374b470] __add_to_page_cache_locked at ffffffff8112137d
> > > #17 [ffff88177374b4e0] add_to_page_cache_lru at ffffffff81121618
> > > #18 [ffff88177374b510] pagecache_get_page at ffffffff8112170b
> > > #19 [ffff88177374b560] grow_dev_page at ffffffff811c8297
> > > #20 [ffff88177374b5c0] __getblk_slow at ffffffff811c91d6
> > > #21 [ffff88177374b600] __getblk_gfp at ffffffff811c92c1
> > > #22 [ffff88177374b630] ext4_ext_grow_indepth at ffffffff8124565c
> > > #23 [ffff88177374b690] ext4_ext_create_new_leaf at ffffffff81246ca8
> > > #24 [ffff88177374b6e0] ext4_ext_insert_extent at ffffffff81246f09
> > > #25 [ffff88177374b750] ext4_ext_map_blocks at ffffffff8124a848
> > > #26 [ffff88177374b870] ext4_map_blocks at ffffffff8121a5b7
> > > #27 [ffff88177374b910] mpage_map_one_extent at ffffffff8121b1fa
> > > #28 [ffff88177374b950] mpage_map_and_submit_extent at ffffffff8121f07b
> > > #29 [ffff88177374b9b0] ext4_writepages at ffffffff8121f6d5
> > > #30 [ffff88177374bb20] do_writepages at ffffffff8112c490
> > > #31 [ffff88177374bb30] __filemap_fdatawrite_range at ffffffff81120199
> > > #32 [ffff88177374bb80] filemap_flush at ffffffff8112041c
> 
> That's a potential self deadlocking path, isn't it? i.e. the
> writeback path has been entered, may hold pages locked in the
> current bio being built (waiting for submission), then memory
> reclaim has been entered while trying to map more contiguous blocks
> to submit, and that waits on page IO to complete on a page in a bio
> that ext4 hasn't yet submitted?
> 
> i.e. shouldn't ext4 be doing GFP_NOFS allocations all through this
> writeback path?

All of the direct allocations in fs/ext4/extents.c are using GFP_NOFS.
The problem is that we're calling sb_getblk(), which does _not_ set
GFP_NOFS.  What we need to do is to add a sb_getblk_gfp() inline
function in include/linux/buffer_head.h, and use that in
fs/ext4/extents.c.

Thanks for pointing that out!  I'll create a patch as soon as I get
back from vacation.

       	   	    	 	     	      - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html