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 16:17:16 -0400
From:	"Alan D. Brunelle" <Alan.Brunelle@...com>
To:	"Alan D. Brunelle" <Alan.Brunelle@...com>
CC:	Björn Steinbrink <B.Steinbrink@....de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Petr Baudis <pasky@...e.cz>, linux-kernel@...r.kernel.org,
	git@...r.kernel.org
Subject: Re: Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

Alan D. Brunelle wrote:
> Björn Steinbrink wrote:
>> On 2008.08.22 10:51:36 -0700, Andrew Morton wrote:
>>> On Fri, 22 Aug 2008 19:16:51 +0200 Petr Baudis <pasky@...e.cz> wrote:
>>>> On Fri, Aug 22, 2008 at 09:25:49AM -0700, Andrew Morton wrote:
>>>>> 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
>>>> ...I don't quite get this - according to the bisection log,
>>>>
>>>> 	# good: [b1b135c8d619cb2c7045d6ee4e48375882518bb5] fix spinlock recursion in hvc_console
>>>>
>>>> and now you want to mark it as bad?
>>> <what bisection log?>
>> Alan provided his bisection log as an attachment to the original bug
>> report.
>>
>>> I assume that Alan's bisection search ended up saying that the merge
>>> commit (1c89ac55017f982355c7761e1c912c88c941483d) was the first bad
>>> commit.
>> Yep, and that's totally correct as far as bisect is concerned. The
>> parents of that merge commit are:
>> 88fa08f67bee1a0c765237bdac106a32872f57d2
>> b1b135c8d619cb2c7045d6ee4e48375882518bb5
>>
>> And Alan marked both of them as good.
>>
>> So, unless Alan made a mistake during his bisection, each of the
>> branches is correct, but the merge did not lead to a correct result. So
>> while there were no textual conflicts, there were still incompatible
>> changes regarding the code semantics and compatibility was not restored
>> during the merge.
> 
> It's important to note that even if I did make a mistake during the
> bisection process (and I certainly wouldn't discount that), recent
> kernels still fail: but when I take out that commit from a recent
> kernel, it fails.

s/fails/succeeds/

> 
> I put in Andrew's suggested patch (to help find things), and now I
> repeatedly get the problems in the attached log.
> 
> Not being an x86 knowledgeable person, I'm a bit concerned about the RSP
> value?! (I enabled stack overflow checking, but that didn't stop things.)
> 
> Alan
> 

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