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 <[email protected]>
Date: Thu Apr 7 14:00:12 2016 +1000
huge tmpfs: avoid premature exposure of new pagetable
Bisect log and config are attatched.
Thanks,
Xiong
# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.6.0-rc3-next-20160414+
root=/dev/mapper/xxxxx--01-root ro crashkernel=auto
rd.lvm.lv=xxxxx-01/root rd.lvm.lv=xxxxxx/swap console=ttyS1,115200n81
memmap=10G!5G memmap=15G!15G selinux=0 LANG=en_US.UTF-8
# mkfs.ext4 -V
mke2fs 1.43-WIP (15-Mar-2016)
Using EXT2FS Library version 1.43-WIP
# mkfs.xfs -V
mkfs.xfs version 4.5.0
....
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 <[email protected]>
> 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:
On Fri, Apr 15, 2016 at 4:38 PM, Hugh Dickins <[email protected]> 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 <[email protected]>
>> 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!