linux-kernel - Re: Linux 2.6.20.3

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:	Tue, 13 Mar 2007 22:40:35 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	nish.aravamudan@...il.com
Cc:	greg@...ah.com, linux-kernel@...r.kernel.org, akpm@...l.org,
	torvalds@...l.org, stable@...nel.org, sparclinux@...r.kernel.org
Subject: Re: Linux 2.6.20.3

From: "Nish Aravamudan" <nish.aravamudan@...il.com>
Date: Tue, 13 Mar 2007 17:29:17 -0700

> Ok, truly bizarre, I found that I was not running stock 2.6.20.3, but
> had your small hugetlb patch on top.
> 
> So I went back and patched 2.6.20.1 with your patch, rebooted, got a
> soft lockup. Went back to stock 2.6.20.1 and did not.
> 
> I don't see how your patch (C&P below for reference) could make any
> difference...Especially because no hugepages were in use at the time.
> On patched 2.6.20.1, I was just trying to check if my source tree had
> your patch applied (by `patch -p1 < davem.patch`) and got the
> soft-lockup I saw in 2.6.20.3 with the patch applied. I am going to
> try a clean 2.6.20.3 as well, now.

We've seen cases in the past where something benign like this
triggers a bug because it moves the data/bss/etc. sections
around.

For example, if the used parts of the kernel image end up extending
into another page, this can influence the bootup memory detection
logic.

The softlockup in your first trace shows it spinning in the journaling
code.  Perhaps what is happening is that it is looping endlessly over
some data structure which is in a corrupted state.  This could happen
if the bootup code erroneously frees up pages it should not have.
I would recommend figuring out exactly what the journaling code is
stuck on, then try to trace the life of that page of memory from
early bootup until it is allocated.

I hope this can help you figure out this bug as I can't reproduce it
here at all, and I did merge the hugetlb fix into Linus's tree
already (and that is the right thing to do as we certainly have some
unrelated bug here).

On the flip side, I bet removing some kernel config option might make
the heisenbug go away if you're just eager to test the hugetlb patch
:-)
-
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/