Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932522AbcDRCuP (ORCPT ); Sun, 17 Apr 2016 22:50:15 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33028 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932286AbcDRCuL (ORCPT ); Sun, 17 Apr 2016 22:50:11 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 18 Apr 2016 10:50:08 +0800 Message-ID: Subject: Re: binary execution from DAX mount hang since next-20160407 From: Xiong Zhou To: Hugh Dickins Cc: Linux-Next , linux-nvdimm@ml01.01.org, "linux-kernel@vger.kernel.org" , Linux-Fsdevel , linux-mm@kvack.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2996 Lines: 90 On Fri, Apr 15, 2016 at 4:38 PM, Hugh Dickins wrote: > On Fri, 15 Apr 2016, Xiong Zhou wrote: > >> Hi, all >> >> Since tag next-20160407 in linux-next repo, executing binary >> from/in DAX mount hangs. >> >> It does not hang if mount without dax option. >> It hangs with both xfs and ext4. >> It does not hang if execute from a -t tmpfs mount. >> It does not hang on next-20160406 and still hangs on 0414 tree. >> >> # ps -axjf >> ... >> S+ 0 0:00 | \_ sh -x thl.sh >> R+ 0 42:33 | \_ [hl] >> .. >> # cat thl.sh >> mkfs.ext4 /dev/pmem0 >> mount -o dax /dev/pmem0 /daxmnt >> cp hl /daxmnt >> /daxmnt/hl >> # cat hl.c >> void main() >> { >> printf("ok\n"); >> } >> # cc hl.c -o hl >> >> Bisecting commits between 0406 and 0407 tag, points to this: >> >> d7c7d56ca61aec18e5e0cb3a64e50073c42195f7 is the first bad commit >> commit d7c7d56ca61aec18e5e0cb3a64e50073c42195f7 >> Author: Hugh Dickins >> Date: Thu Apr 7 14:00:12 2016 +1000 >> >> huge tmpfs: avoid premature exposure of new pagetable >> >> Bisect log and config are attatched. > > Excellent and very helpful bug report: thank you very much for taking > the trouble to make such a good report. > > I see why this happens now: I've not been paying enough attention > to the DAX changes. > > The fix requires a repositioning of where I allocate the new page > table: which is a change we knew we had to make for other reasons, > but it did not appear to be a high priority compared with other things > - until your bug report showing that I have broken DAX rather badly. > > In return for your excellent bug report, I can immediately offer > the most shameful patch I have ever posted: which has the virtue of > simplicity, and will work so long as you have plenty of free memory; > but might deadlock if it has to go into page reclaim (or maybe not: > perhaps the DAXness would leave it as merely a lockdep violation). > > Maybe not so much worse than the current hang, but still shameful: > I'm appending it here just in case you're in a hurry to see your "ok" > program working on DAX; but I think I'd better rearrange priorities > and try to provide a proper fix as soon as possible. No hurry, :) Take your time. > > Never-to-be-Signed-off-by: an anonymous hacker > > --- 4.6-rc2-mm1/mm/memory.c 2016-04-10 10:12:06.167769232 -0700 > +++ linux/mm/memory.c 2016-04-15 00:54:06.427085026 -0700 > @@ -2874,7 +2874,7 @@ static int __do_fault(struct vm_area_str > ret = VM_FAULT_HWPOISON; > goto err; > } > - > + out: > /* > * Use pte_alloc instead of pte_alloc_map, because we can't > * run pte_offset_map on the pmd, if an huge pmd could > @@ -2892,7 +2892,7 @@ static int __do_fault(struct vm_area_str > ret = VM_FAULT_NOPAGE; > goto err; > } > - out: > + > *page = vmf.page; > return ret; > err: Yes, "ok" is printed ok!