linux-kernel - Re: [git pull] fastboot tree for v2.6.28

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:	Sat, 11 Oct 2008 08:47:12 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [git pull] fastboot tree for v2.6.28

* Arjan van de Ven <arjan@...radead.org> wrote:

> > You can try to convince me otherwise, but I really do think this 
> > patch is fundamentally the wrong approach.
> 
> there's an angle here which I would like to bring up. There is a 
> fundamental difference between a spider functionality like USB, and 
> "leaf drivers". Yes USB should do it right, it's drivers are 
> effectively a midlayer. (and again, pull gregkh's tree and you'll get 
> that; although even with that there's a noticeable amount of time 
> spent there).
> 
> For leaf drivers, it's a matter of where you want to push the 
> functionality. With leaf drivers I mean things like the ACPI battery 
> driver (or other ACPI drivers), but also various PCI drivers that 
> don't have or are elaborate subsystems or boot dependencies. We could 
> make all their probing functions async in each driver, or we could 
> provide the most simple interface as is done in this case, they just 
> change how they declare their initcall. (I'll grant you that we could 
> also do a pci_register_device_async() like of helper, but that's just 
> solving part of the same problem)
> 
> Personally for leaf drivers, I think the initcall-level approach is 
> much less error prone.

i'd like to inject my first-hand testing experience with your patches: 

When i saw your patches then initially my impression was "oh my, this 
will break a ton of stuff", so i asked you to: make it default-off 
(against Andrew's suggestion to just remove the config and make it a 
compulsory feature), to add various mechanisms to disable and isolate 
it, should it break something - which i expected to be a near certainty.

But i was wrong. We had only a single bug in fastboot-v1 three months 
ago which i bisected back to this series, and you fixed that quickly. 
And CONFIG_FASTBOOT=y is definitely one of the popular features that 
testers enable and there's all sorts of weird systems that are being 
tested with tip/master.

So tip/fastboot has certainly been a problem free topic in its 3 months 
of lifetime - and it got propagated to linux-next early on as well.

Our -tip testsystems boot with CONFIG_FASTBOOT=y about 50% of the time, 
once every couple of minutes on this test-system:

 config-Fri_Oct_10_23_06_21_CEST_2008.good:CONFIG_FASTBOOT=y
 config-Fri_Oct_10_23_07_54_CEST_2008.good:CONFIG_FASTBOOT=y
 config-Fri_Oct_10_23_14_08_CEST_2008.good:CONFIG_FASTBOOT=y
 config-Fri_Oct_10_23_15_54_CEST_2008.good:CONFIG_FASTBOOT=y
 config-Fri_Oct_10_23_21_37_CEST_2008.good:CONFIG_FASTBOOT=y
 config-Fri_Oct_10_23_22_56_CEST_2008.good:CONFIG_FASTBOOT=y
 config-Fri_Oct_10_23_27_14_CEST_2008.good:CONFIG_FASTBOOT=y

i checked the logs, just yesterday that meant 354 fastboot-enabled 
bootups on just that single test-system. So while i fully expected 
fragility from this topic, neither our testing nor our testers saw 
fragility in practice.

	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/