From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754798AbZBUSJK (ORCPT ); Sat, 21 Feb 2009 13:09:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753597AbZBUSI6 (ORCPT ); Sat, 21 Feb 2009 13:08:58 -0500 Received: from mail-bw0-f161.google.com ([209.85.218.161]:41258 "EHLO mail-bw0-f161.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753404AbZBUSI5 (ORCPT ); Sat, 21 Feb 2009 13:08:57 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Mh7T1yuq90cO2czWpKJCk2oaM4yUETwPFZibmxKF81sqmJph81NbM2U9nqyBBWhxOU lymJXskzvCTh6BuDkvZhkPhAG5sAGUT53x/7+BWybOZYOAVYLY6nb0cLxILq5NG84P4l R2EPoKr403d2eK+7mDYsTBRqEjZtM3aaW1zAs= MIME-Version: 1.0 In-Reply-To: <20090221174703.GA6860@linux.vnet.ibm.com> References: <20090220134121.GA19575@damson.getinternet.no> <20090220135000.GA9616@elte.hu> <20090220140157.GA12799@elte.hu> <19f34abd0902200651k7e86aebay5398ef5ac0578561@mail.gmail.com> <20090220154619.GC6960@linux.vnet.ibm.com> <19f34abd0902201551o65a3650egf29d81e8b6823d67@mail.gmail.com> <20090221014056.GU6960@linux.vnet.ibm.com> <19f34abd0902210130p62fba6d0n906b321949409578@mail.gmail.com> <20090221174703.GA6860@linux.vnet.ibm.com> Date: Sat, 21 Feb 2009 19:08:55 +0100 Message-ID: <19f34abd0902211008k39afd449k604aaf34f693c9a6@mail.gmail.com> Subject: Re: [PATCH] mm: fix lazy vmap purging (use-after-free error) From: Vegard Nossum To: paulmck@linux.vnet.ibm.com Cc: Ingo Molnar , stable@kernel.org, Andrew Morton , Nick Piggin , Pekka Enberg , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2009/2/21 Paul E. McKenney : >> rcu_check_callbacks (cpu=0, user=0) at kernel/rcutree.c:949 >> 949 { >> ... >> rcu_check_callbacks (cpu=0, user=-1049147360) at kernel/rcutree.c:967 >> 967 rcu_qsctr_inc(cpu); > > ???? Are the argument values trustworthy? If so, I don't see how > the variable user transitioned from zero to non-zero. > > The value user!=0 tells RCU that we were interrupted from a user process, > but this immediately follows user==0. If we really were interrupted > from kernel code, (including from an irq handler) we should have user==0. > > The user!=0 causes RCU to conclude that we are in a quiescent state. > > RCU is then within its rights to process callbacks, which would result > in the behavior you saw. Ah, curious. Thanks for the explanation. I tried again, just to be sure: Breakpoint 1, rcu_check_callbacks (cpu=0, user=0) at kernel/rcutree.c:949 949 { (gdb) p &user Address requested for identifier "user" which is in register $edx (gdb) p user $1 = 0 (gdb) s 950 if (user || (gdb) 949 { (gdb) 950 if (user || (gdb) idle_cpu (cpu=0) at kernel/sched.c:5196 5196 return cpu_curr(cpu) == cpu_rq(cpu)->idle; (gdb) 5197 } (gdb) idle_cpu (cpu=) at kernel/sched.c:5196 5196 return cpu_curr(cpu) == cpu_rq(cpu)->idle; (gdb) 5197 } (gdb) rcu_check_callbacks (cpu=0, user=-1049147360) at kernel/rcutree.c:967 967 rcu_qsctr_inc(cpu); Could that be a missing "d" clobber in some inline assembly? Or a miscompilation? Here's the disassembly (I hope it won't wrap): 0xc1073ec0 : push %ebp 0xc1073ec1 : test %edx,%edx 0xc1073ec3 : mov %esp,%ebp 0xc1073ec5 : push %ebx 0xc1073ec6 : mov %eax,%ebx 0xc1073ec8 : je 0xc1073f08 0xc1073eca : mov $0xc1771320,%eax 0xc1073ecf : add -0x3e8fa900(,%ebx,4),%eax 0xc1073ed6 : mov (%eax),%edx 0xc1073ed8 : movb $0x1,0xc(%eax) 0xc1073edc : mov %edx,0x8(%eax) 0xc1073edf : mov $0xc1771380,%eax 0xc1073ee4 : add -0x3e8fa900(,%ebx,4),%eax 0xc1073eeb : mov (%eax),%edx 0xc1073eed : movb $0x1,0xc(%eax) 0xc1073ef1 : mov %edx,0x8(%eax) 0xc1073ef4 : mov $0x8,%eax Seems to be rcu_qsctr_inc() that reloads %edx. If I'd guess, I'd say x86's per_cpu macros. But it seems so strange that the corruption would not manifest in other ways too. Stand by for further investigations :-) Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036