Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753823AbcDOIjL (ORCPT ); Fri, 15 Apr 2016 04:39:11 -0400 Received: from mail-pf0-f182.google.com ([209.85.192.182]:35384 "EHLO mail-pf0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753375AbcDOIjI (ORCPT ); Fri, 15 Apr 2016 04:39:08 -0400 Date: Fri, 15 Apr 2016 01:38:57 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Xiong Zhou cc: hughd@google.com, Linux-Next , linux-nvdimm@ml01.01.org, "linux-kernel@vger.kernel.org" , Linux-Fsdevel , linux-mm@kvack.org Subject: Re: binary execution from DAX mount hang since next-20160407 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2650 Lines: 84 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. 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: