From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f199.google.com (mail-qk0-f199.google.com [209.85.220.199]) by kanga.kvack.org (Postfix) with ESMTP id AAF836B0253 for ; Wed, 4 Jan 2017 09:26:17 -0500 (EST) Received: by mail-qk0-f199.google.com with SMTP id q128so312948687qkd.3 for ; Wed, 04 Jan 2017 06:26:17 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id c5si19476337qke.50.2017.01.04.06.26.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jan 2017 06:26:17 -0800 (PST) Date: Wed, 4 Jan 2017 22:26:15 +0800 From: Xiong Zhou Subject: Re: [PATCH] dax: fix deadlock with DAX 4k holes Message-ID: <20170104142615.34ci46l7otz7qrlz@XZHOUW.usersys.redhat.com> References: <20161027112230.wsumgs62fqdxt3sc@xzhoul.usersys.redhat.com> <1483479365-13607-1-git-send-email-ross.zwisler@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1483479365-13607-1-git-send-email-ross.zwisler@linux.intel.com> Sender: owner-linux-mm@kvack.org List-ID: To: Ross Zwisler Cc: Xiong Zhou , stable@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , Christoph Hellwig , Dan Williams , Dave Chinner , Dave Hansen , Jan Kara , linux-mm@kvack.org, linux-nvdimm@ml01.01.org On Tue, Jan 03, 2017 at 02:36:05PM -0700, Ross Zwisler wrote: > Currently in DAX if we have three read faults on the same hole address we > can end up with the following: > > Thread 0 Thread 1 Thread 2 > -------- -------- -------- > dax_iomap_fault > grab_mapping_entry > lock_slot > > > dax_iomap_fault > grab_mapping_entry > get_unlocked_mapping_entry > > > dax_iomap_fault > grab_mapping_entry > get_unlocked_mapping_entry > > dax_load_hole > find_or_create_page > ... > page_cache_tree_insert > dax_wake_mapping_entry_waiter > > __radix_tree_replace > > > > get_page > lock_page > ... > put_locked_mapping_entry > unlock_page > put_page > > wait queue> > > The crux of the problem is that once we insert a 4k zero page, all locking > from then on is done in terms of that 4k zero page and any additional > threads sleeping on the empty DAX entry will never be woken. Fix this by > waking all sleepers when we replace the DAX radix tree entry with a 4k zero > page. This will allow all sleeping threads to successfully transition from > locking based on the DAX empty entry to locking on the 4k zero page. > > With the test case reported by Xiong this happens very regularly in my test > setup, with some runs resulting in 9+ threads in this deadlocked state. > With this fix I've been able to run that same test dozens of times in a > loop without issue. > > Signed-off-by: Ross Zwisler > Reported-by: Xiong Zhou > Fixes: commit ac401cc78242 ("dax: New fault locking") > Cc: Jan Kara > Cc: stable@vger.kernel.org # 4.7+ > --- Positive test result of this patch for this issue and the regression tests. Great job! > > This issue exists as far back as v4.7, and I was easly able to reproduce it > with v4.7 using the same test. > > Unfortunately this patch won't apply cleanly to the stable trees, but the > change is very simple and should be easy to replicate by hand. Please ping > me if you'd like patches that apply cleanly to the v4.9 and v4.8.15 trees. > > --- > mm/filemap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/filemap.c b/mm/filemap.c > index d0e4d10..b772a33 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -138,7 +138,7 @@ static int page_cache_tree_insert(struct address_space *mapping, > dax_radix_locked_entry(0, RADIX_DAX_EMPTY)); > /* Wakeup waiters for exceptional entry lock */ > dax_wake_mapping_entry_waiter(mapping, page->index, p, > - false); > + true); > } > } > __radix_tree_replace(&mapping->page_tree, node, slot, page, > -- > 2.7.4 > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org