linux-kernel - Re: binary execution from DAX mount hang since next-20160407

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 15 Apr 2016 01:38:57 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Xiong Zhou <jencce.kernel@...il.com>
cc:	hughd@...gle.com, Linux-Next <linux-next@...r.kernel.org>,
	linux-nvdimm@...ts.01.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: binary execution from DAX mount hang since next-20160407

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 <hughd@...gle.com>
> 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: