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@xxxxxxxxxx>
> 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:
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
