linux-kernel - Re: Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Aug 2008 09:25:49 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"Alan D. Brunelle" <Alan.Brunelle@...com>
Cc:	linux-kernel@...r.kernel.org, git@...r.kernel.org
Subject: Re: Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

On Fri, 22 Aug 2008 11:37:33 -0400 "Alan D. Brunelle" <Alan.Brunelle@...com> wrote:

> Andrew Morton wrote:
> 
> > 
> > You could confirm/debug it with something along the lines of this:
> > 
> > --- a/mm/vmalloc.c~a
> > +++ a/mm/vmalloc.c
> > @@ -214,7 +214,9 @@ __get_vm_area_node(unsigned long size, u
> >  	unsigned long align = 1;
> >  	unsigned long addr;
> >  
> > -	BUG_ON(in_interrupt());
> > +	if (preempt_count() > 10)
> > +		printk("%s: preempt_count()=%d\n", __func__, preempt_count());
> > +	WARN_ON(in_interrupt());
> >  	if (flags & VM_IOREMAP) {
> >  		int bit = fls(size);
> >  
> > _
> > 
> > 
> > But this bug could be in practically anywhere in the kernel and
> > bisection is by far the best way to find it.  It's sad and odd that
> > bisection landed you on a merge commit.  I'd suggest that you persist
> > with the bisection (please). 
> > http://www.kernel.org/doc/local/git-quick.html#example might be useful.
> 
> Sorry, was off on other things for the last couple of days:
> 
> I /did/ bisect it down to the aforementioned merge, the question is: How
> to crack open that merge into it's composite pieces? (Where do I go to
> bisect within that?)

urgh, it's irritating when git-bisect directs you to a merge commit - it
hasn't done it for me for ages.

One (probably wrong) approach is to run

	gitk 1c89ac55017f982355c7761e1c912c88c941483d

then peer at the output, work out which real commits were in that
merge.

It looks like the merge ended with
b1b135c8d619cb2c7045d6ee4e48375882518bb5 and started with
40c42076ebd362dc69210cccea101ac80b6d4bd4, so perhaps you can do

	git bisect bad b1b135c8d619cb2c7045d6ee4e48375882518bb5
	git bisect good 40c42076ebd362dc69210cccea101ac80b6d4bd4

That has an off-by-one error, in that it assumes that
40c42076ebd362dc69210cccea101ac80b6d4bd4 is good, which we don't know. 
Perhaps one can pick the preceding commit in the `git log' output to
fix that.

Anyway, I've sent sufficient wrongness to the right list for us to work
out how to do this for real ;)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/