| Message ID | alpine.LSU.2.11.1604150104350.5801@eggly.anvils (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Apr 15, 2016 at 4:38 PM, Hugh Dickins <hughd@google.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@google.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!
--- 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: