| 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
| ||
|
Message-ID: <20081011064712.GA25451@elte.hu> 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/
Powered by blists - more mailing lists