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] [day] [month] [year] [list]

Message-ID: <CADJHv_ts7_Qu8oZ=kCbYPOR7NzbMFJxze31b9EdFj9gqWrRhEA@mail.gmail.com>
Date:	Mon, 18 Apr 2016 10:50:08 +0800
From:	Xiong Zhou <jencce.kernel@...il.com>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	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, Apr 15, 2016 at 4:38 PM, Hugh Dickins <hughd@...gle.com> 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 <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.

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!