Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757034Ab1DLJ6j (ORCPT ); Tue, 12 Apr 2011 05:58:39 -0400 Received: from mail-pw0-f46.google.com ([209.85.160.46]:53924 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753716Ab1DLJ6h convert rfc822-to-8bit (ORCPT ); Tue, 12 Apr 2011 05:58:37 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 12 Apr 2011 11:58:36 +0200 Message-ID: Subject: Re: [PATCH] mm: fix possible cause of a page_mapped BUG From: =?UTF-8?B?Um9iZXJ0IMWad2nEmWNraQ==?= To: Hugh Dickins Cc: Linus Torvalds , Andrew Morton , Miklos Szeredi , Michel Lespinasse , "Eric W. Biederman" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Peter Zijlstra , Rik van Riel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2363 Lines: 57 On Thu, Apr 7, 2011 at 4:24 PM, Hugh Dickins wrote: > On Thu, 7 Apr 2011, Robert Swiecki wrote: >> > >> > Testing with Linus' patch. Will let you know in a few hours. >> >> Ok, nothing happened after ~20h. The bug, usually, was triggered within 5-10h. >> >> I can add some printk in this condition, and let it run for a few days >> (I will not have access to my testing machine throughout that time), >> if you think this will confirm your hypothesis. > > That's great, thanks Robert.  If the machine has nothing better to do, > then it would be nice to let it run a little longer (a few days if that's > what suits you), but it does look good so far.  Though I'm afraid you'll > now discover something else entirely ;) Ok, I added printk here: if (new_len > old_len) { unsigned long pgoff; if (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP)) goto Efault; pgoff = (addr - vma->vm_start) >> PAGE_SHIFT; pgoff += vma->vm_pgoff; if (pgoff + (new_len >> PAGE_SHIFT) < pgoff) { printk("VMA_TO_RESIZE: ADDR:%lx OLD_LEN:%lx NEW_LEN:%lx PGOFF: %lx VMA->VM_START:%lx VMA->VM_FLAGS:%lx", addr, old_len, new_len, pgoff, vma->vm_start, vma->vm_flags); goto Einval; } } and after a few mins of fuzzing I get: [ 584.224028] VMA_TO_RESIZE: ADDR:f751f000 OLD_LEN:6000 NEW_LEN:c000 PGOFF: fffffffffffffffa VMA->VM_START:f751f000 VMA->VM_FLAGS:2321fa [ 639.777561] VMA_TO_RESIZE: ADDR:f751f000 OLD_LEN:6000 NEW_LEN:b000 PGOFF: fffffffffffffffa VMA->VM_START:f751f000 VMA->VM_FLAGS:2301f8 So, if this case is not caught later on in the code, I guess it solves the problem. During the fuzzing I didn't experience any panic's, but some other problems arose, i.e. cannot read /proc//maps for some processes (sys_read hangs, and such process cannot be killed or stopped with any signal, still it's running (R state) and using CPU - I'll submit another report for that). -- 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/