linux-kernel - Re: [PATCH] x86/pci: don't use crs for root if we only have one root bus

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:	Thu, 25 Jun 2009 09:03:47 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Gary Hade <garyhade@...ibm.com>,
	Matthew Wilcox <matthew@....cx>,
	Larry Finger <Larry.Finger@...inger.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-pci@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jaswinder Singh Rajput <jaswinder@...nel.org>
Subject: Re: [PATCH] x86/pci: don't use crs for root if we only have one
	root bus

* Jesse Barnes <jbarnes@...tuousgeek.org> wrote:

> > [ There's a difference between "we're supposed to find and fix bugs
> > in the -rc series", and "I release known-buggy -rc1's since we're
> > supposed to fix it later". For similar reasons, I hate pulling
> > known-buggy stuff during the merge window - it's ok if it shows
> > itself to be buggy _later_, but if people send me stuff that they
> > know is buggy as they send it to me, then that's a problem. ]
> 
> Yeah, 100% agreed.  I didn't hear any reports until after people 
> started using your tree, so I think this case was handled 
> correctly: push something that *seems* ok upstream, but with eyes 
> wide open for the possibility we'd need to revert.

There's only one small gripe i have with the handling of it: the 
timing. "9e9f46c: PCI: use ACPI _CRS data by default" was written 
and committed on June 11th, two days _after_ the merge window 
opened.

That's way too late for maybe-broken changes to x86 lowlevel details 
(especially if it touches hw-environmental interaction - which is 
very hard to test with meaningful coverage), and it's also pretty 
much the worst moment to solicit testing from people who are busy 
getting their stuff to Linus and who are busy testing out any of the 
unexpected interactions and bugs.

So this was, to a certain degree, a predictable outcome. Trees in 
the Linux "critical path" of testing (core kernel, x86, core 
networking, very common drivers, PCI, driver core, VFS, etc.) should 
generally try to cool down 1-2 weeks before the merge window - 
because breakage there can do a lot of knock-on cascading damage. 
Two weeks is not a lot of time and the effects of showstopper bugs 
get magnified disproportionately.

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