Re: [PATCH] mm: fix possible cause of a page_mapped BUG

From: Robert ÅwiÄcki
Date: Mon Feb 28 2011 - 18:35:45 EST

> 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:

I think i was trying it with this revision: (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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at