linux-kernel - Re: 2.6.19-rc3: known unfixed regressions (v3)

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]

Message-ID: <20061030185844.GA4442@mellanox.co.il>
Date:	Mon, 30 Oct 2006 20:58:44 +0200
From:	"Michael S. Tsirkin" <mst@...lanox.co.il>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	"Jun'ichi Nomura" <j-nomura@...jp.nec.com>,
	Martin Lorenz <martin@...enz.eu.org>,
	Pavel Machek <pavel@...e.cz>, Adrian Bunk <bunk@...sta.de>,
	Andrew Morton <akpm@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	len.brown@...el.com, linux-acpi@...r.kernel.org, linux-pm@...l.org,
	"Randy.Dunlap" <rdunlap@...otime.net>
Subject: Re: 2.6.19-rc3: known unfixed regressions (v3)

Quoting r. Linus Torvalds <torvalds@...l.org>:
> Subject: Re: 2.6.19-rc3: known unfixed regressions (v3)
> 
> 
> 
> On Mon, 30 Oct 2006, Jun'ichi Nomura wrote:
> > 
> > Please revert the patch. I'll fix the wrong error handling.
> > 
> > I'm not sure reverting the patch solves the ACPI problem
> > because Michael's kernel seems not having any user of
> > bd_claim_by_kobject.
> 
> Yeah, doing a grep does seem to imply that there is no way that those 
> changes could matter.
> 
> Michael, can you double-check? I think Jun'ichi is right - in your kernel, 
> according to the config posted on bugzilla, I don't think there should be 
> a single caller of bd_claim_by_disk, since CONFIG_MD is disabled.

I will, just maybe not today.

> So it does seem strange. But if you bisected to that patch, and it 
> reliably does _not_ have problems with the patch reverted, maybe there is 
> some strange preprocessor thing that makes "grep" not find the caller.
> 
> Michael, you also reported:
> 
> > Reset to d7dd8fd9557840162b724a8ac1366dd78a12dff seems to hide part of 
> > the issue (I have ACPI after kernel build, but not after 
> > suspend/resume).  Both reverting this patch, and reset to the parent of
> > this patch seem to solve (or at least, hide) both problems for me (no 
> > ACPI after suspend/resume and no ACPI after kernel build).
> 
> (where that "d7dd8f.." is actually missing the initial "4" - I think you 
> cut-and-pasted things incorrectly). 

Yes.

> So I wonder.. You still had ACPI working _after_ the kernel build even 
> with that patch in place, and it seems that suspend/resume is the real 
> issue. Martin Lorenz reports on the same bugzilla entry, and he only has 
> problems with suspend/resume.
> 
> I assume that "compile the kernel" just triggers some magic ACPI event 
> (probably fan-related due to heat), and I wonder if the bisection faked 
> you out because once you get "close enough" the differences are small 
> enough that the kernel compile is quick and the heat event doesn't 
> actually trigger?
> 
> See what I'm saying? Maybe the act of bisecting itself changed the 
> results, and then when you just revert the patch, you end up in the same 
> situation: you only recompile a small part (you only recompile that 
> particular file), and the problem doesn't occur, so you'd think that the 
> revert "fixed" it.
> 
> If it's heat-related, it should probably trigger by anything that does a 
> lot of CPU (and perhaps disk) accesses, not just kernel builds. It might 
> be good to try to find another test-case for it than a kernel recompile, 
> one that doesn't depend on how much changed in the kernel..
> 
> 		Linus
> 
> 

Linus, I agree something fishy is going on, I'm just not sure how to debug.
It kind of looks like some memory corruption, or something.
I plan double-checking sometime later.

2 points I'd like to clarify:
1. When I git-bisected, I tested ACPI after suspend/resume,
   this is much faster to test but might be a separate issue.
   I really tested several times, and unless I repeated
   same mistake several times just switching between commit above 
   and its parent made ACPI after resume work/not work.

2. When I test kernel compile, I do
git clone -s ~/scm/linux-2.6
cd linux-2.6
make defconfig
make -j 4

so the build I do in testing is repeatable.

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