> 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@xxxxxxxxxx> > --- > > Â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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href