From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751570AbbJFFMW (ORCPT ); Tue, 6 Oct 2015 01:12:22 -0400 Received: from ipmail04.adl6.internode.on.net ([150.101.137.141]:64944 "EHLO ipmail04.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750853AbbJFFMV (ORCPT ); Tue, 6 Oct 2015 01:12:21 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AmQQCEVxNWPEcOLHleGQGDDYFChlqiawaLFoshhhQCAgEBAoEyTQEBAQEBAQcBAQEBQT9BAQEBg2EBAQQnExwWCgMQCAMOCgklDwUlAwcaE4gtvjwBAQEBAQUBAQEBAR0ZhhOFRYUNB4MagRQFlUBAjQ+BX4dckjWEeSozgWeBdIRkAQEB Date: Tue, 6 Oct 2015 16:12:18 +1100 From: Dave Chinner To: Andrew Morton Cc: Michal Hocko , Guenter Roeck , "linux-kernel@vger.kernel.org" , Christoph Lameter , "Kirill A. Shutemov" , linux-mm@kvack.org Subject: Re: linux-next: kernel BUG at mm/slub.c:1447! Message-ID: <20151006051218.GB32150@dastard> References: <560D59F7.4070002@roeck-us.net> <20151001134904.127ccc7bea14e969fbfba0d5@linux-foundation.org> <20151002072522.GC30354@dhcp22.suse.cz> <20151002134953.551e6379ee9f6b5a0aeb7af7@linux-foundation.org> <20151005134713.GC7023@dhcp22.suse.cz> <20151005122936.8a3b0fe21629390c9aa8bc2a@linux-foundation.org> <20151005191217.48008dc7.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151005191217.48008dc7.akpm@linux-foundation.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 05, 2015 at 07:12:17PM -0700, Andrew Morton wrote: > On Mon, 5 Oct 2015 12:29:36 -0700 Andrew Morton 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@fromorbit.com