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
| ||
|
Date: Mon, 17 Sep 2012 23:51:22 +0800 From: Jiang Liu <liuj97@...il.com> To: Bjorn Helgaas <bhelgaas@...gle.com> CC: Don Dutile <ddutile@...hat.com>, Yinghai Lu <yinghai@...nel.org>, Greg KH <gregkh@...uxfoundation.org>, Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>, Jiang Liu <jiang.liu@...wei.com>, Taku Izumi <izumi.taku@...fujitsu.com>, "Rafael J . Wysocki" <rjw@...k.pl>, Yijing Wang <wangyijing@...wei.com>, Xinwei Hu <huxinwei@...wei.com>, linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org Subject: Re: [RFC PATCH v1 06/22] PCI: use a global lock to serialize PCI root bridge hotplug operations >>> I'm not sure why you didn't add a pci_host_bridge_hotplug_lock() in >>> the sba_init() path, since it looks similar to the drm_open_helper() >>> path above. But in any case, I think that would be the wrong thing to >>> do because it would fix the superficial problem while leaving the >>> deeper problem of host bridge hot-add not setting the iommu pointer. > >> sba_init is called during system initialization stages through subsys_initcall, >> so no extra protection for it. > > OK, I see your reasoning. But I don't agree :) All the users of an > interface should use the same locking scheme, even if they're at > boot-time where we "know" we don't need it. It's too hard to analyze > differences, and code gets copied from one place to somewhere else > where it might not be appropriate. Hi Bjorn, "All the users of an interface should use the same locking scheme", a really good design pattern to follow. It's so easy for everybody to remove the __init modifier without noticing the design limitation. --Gerry -- 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