From patchwork Fri Apr 15 08:38:57 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hugh Dickins X-Patchwork-Id: 8845931 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 38F37C0553 for ; Fri, 15 Apr 2016 08:39:34 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 61A332027D for ; Fri, 15 Apr 2016 08:39:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7E2B620279 for ; Fri, 15 Apr 2016 08:39:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753796AbcDOIjK (ORCPT ); Fri, 15 Apr 2016 04:39:10 -0400 Received: from mail-pf0-f176.google.com ([209.85.192.176]:33075 "EHLO mail-pf0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753297AbcDOIjI (ORCPT ); Fri, 15 Apr 2016 04:39:08 -0400 Received: by mail-pf0-f176.google.com with SMTP id 184so55162042pff.0 for ; Fri, 15 Apr 2016 01:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=QBfexL3U8Otv5q0KR7G+ULc/eRmV1WG+veBJwG+ljeo=; b=PyyvyWErQXYl1KEuxG+rOeI0Y28ktTHcDjGxwavh7MUwISD23lZeOCLMuHXUfNb/6w oU7dHXw0XpgBQeyp9Je5UQ4zBKkClmvsCSUHVGmyYF8NWk9ZrEReV7T7lFC46mpRGso0 4ZZQ2X3G+yhGyhHR6xXMzfITZfXFj1xQCfTOxkRzrz3RGO8+uwnZYB9yYkTvDBoykM2x lZJ/5ResRv3zhhuirKmZQCIWQyx3YWS3AsX4VkR0Cp9OcWsStQ25JoCaXqkDaGKX366u Pnp993jWBeSpgwRrhYBa6eoZk1X14EtEbJDRgwyiCn9rCGJbyAI8AE22FV2+4D0rkrTJ jRXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=QBfexL3U8Otv5q0KR7G+ULc/eRmV1WG+veBJwG+ljeo=; b=SkyEkyCSmJV4mh4dIj9s6tBn700ybHtdPDpEaGSU8N8bxQXntu41nOPCbuUMGFWntx QNUr9N99IR1f3odBlGANMQC6e/7/UezEh647Z9Xv32wYWy8oKjbc8ryE7o5EKOW6dM2B qFv0fQD5HrHUJksEZCHyqJJeq2e4VW28rR8e8f65X7U/fp4aJPv0kZaM3w4F6pmFj65D DCWJAO9V8r+RIw4/HbbrplAVDjNcBrujkjSqZPNpZOaHO8XNEg40sCqRw04OTxLf7phG vNBQ4OLNHQyWaAwjp+lQUFTyBefyUgm5CdeJ5kbTxnBGc7kTrlBc7GYsvKCTCKpMLkAX 2byQ== X-Gm-Message-State: AOPr4FXYDeK7Si6GK1xS7KaUA5rnfjRnM+yw43W4iLWa7K0ZLf5jwX3KJz2ypcy/wMy4u38T X-Received: by 10.98.66.89 with SMTP id p86mr27498002pfa.42.1460709547078; Fri, 15 Apr 2016 01:39:07 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id d19sm62945657pfj.92.2016.04.15.01.39.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Apr 2016 01:39:06 -0700 (PDT) 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@lists.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 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 --- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- 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: