On Mon, Oct 05, 2015 at 07:12:17PM -0700, Andrew Morton wrote: > On Mon, 5 Oct 2015 12:29:36 -0700 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > Maybe it would be better to add the gfp_t argument to the > > address_space_operations. At a minimum, writepage(), readpage(), > > writepages(), readpages(). What a pickle. > > I'm being dumb. All we need to do is to add a new > > address_space_operations.readpage_gfp(..., gfp_t gfp) > > etc. That should be trivial. Each fs type only has 2-4 instances of > address_space_operations so the overhead is miniscule. > > As a background janitorial thing we can migrate filesystems over to the > new interface then remove address_space_operations.readpage() etc. But > this *would* add overhead: more stack and more text for no gain. So > perhaps we just leave things as they are. > > That's so simple that I expect we can short-term fix this bug with that > approach. umm, something like > > --- a/fs/mpage.c~a > +++ a/fs/mpage.c > @@ -139,7 +139,8 @@ map_buffer_to_page(struct page *page, st > static struct bio * > do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages, > sector_t *last_block_in_bio, struct buffer_head *map_bh, > - unsigned long *first_logical_block, get_block_t get_block) > + unsigned long *first_logical_block, get_block_t get_block, > + gfp_t gfp) Simple enough, but not sufficient to avoid deadlocks because this doesn't address the common vector for deadlock that was reported. i.e. deadlocks due to the layering dependency the loop device creates between two otherwise independent filesystems. If read IO through the loop device does GFP_KERNEL allocations, then it is susceptible to deadlock as that can force writeback and transactions from the filesystem on top of the loop device, which does more IO to the loop device, which then backs up on the backing file inode mutex. Forwards progress cannot be made until the GFP_KERNEL allocation succeeds, but that depends on the loop device making forwards progress... The loop device indicates this is a known problems tries to avoid these deadlocks by doing this on it's backing file: mapping_set_gfp_mask(mapping, lo->old_gfp_mask & ~(__GFP_IO|__GFP_FS)) to try to ensure that mapping related allocations do not cause inappropriate reclaim contexts to be triggered. This is a problem independent of any specific filesystem - let's not hack a workaround into a specific filesystem just because the problem was reported on that filesystem.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>