Messages in this thread | | | Date | Mon, 28 Feb 2011 15:35:40 -0800 | Subject | Re: [PATCH] mm: fix possible cause of a page_mapped BUG | From | Robert Święcki <> |
| |
> But rather than exporting the notion of restart_addr from memory.c, or > converting to restart_pgoff throughout, simply reset vm_truncate_count > to 0 to force a rescan if mremap move races with preempted truncation. > > We have no confirmation that this fixes Robert's BUG, > but it is a fix that's worth making anyway.
Hi, I don't have currently access to my rs232/console testing machine (lame excuse but it helps a lot;), cause I'm working currently OOtO, so I'll try to test it asap - which is probably Mar 15th or so.
Btw, the fuzzer is here: http://code.google.com/p/iknowthis/
I think i was trying it with this revision: http://code.google.com/p/iknowthis/source/detail?r=11 (i386 mode, newest 'iknowthis' supports x86-64 natively), so feel free to try it.
It used to crash the machine (it's BUG_ON but the system became unusable) in matter of hours. Btw, when I was testing it for the last time it Ooopsed much more frequently in proc_readdir (I sent report in one of earliet e-mails).
> Signed-off-by: Hugh Dickins <hughd@google.com> > --- > > mm/mremap.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > --- 2.6.38-rc6/mm/mremap.c 2011-01-18 22:04:56.000000000 -0800 > +++ linux/mm/mremap.c 2011-02-23 15:29:52.000000000 -0800 > @@ -94,9 +94,7 @@ static void move_ptes(struct vm_area_str > */ > mapping = vma->vm_file->f_mapping; > spin_lock(&mapping->i_mmap_lock); > - if (new_vma->vm_truncate_count && > - new_vma->vm_truncate_count != vma->vm_truncate_count) > - new_vma->vm_truncate_count = 0; > + new_vma->vm_truncate_count = 0; > } > > /* >
-- Robert Święcki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |