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:	Fri, 10 Oct 2008 17:11:13 +0900
From:	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>
To:	Alex Chiang <achiang@...com>,
	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	jbarnes@...tuousgeek.org, kristen.c.accardi@...el.com,
	matthew@....cx
Subject: Re: [PATCH v5 04/16] PCI: prevent duplicate slot names

Alex Chiang wrote:
> * Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>:
>> I'm sorry, but I forgot to tell you one important thing. Now we
>> are trying to change pci slot management API to setup
>> pci_slot->hotplug.  We must consider how to implement the
>> counterpart to clean up pci_slot->hotplug at the same time. My
>> current idea is adding hotplug arg to pci_destroy_slot(), but
>> it seems a little ugly...
> 
> Ugh, I'm not sure which is worse, an unbalanced API vs passing a
> hotplug_slot to pci_destroy_slot.
> 
> pci_destroy_slot should never touch the pci_slot->hotplug
> argument, I think, because it is possible for non-hotplug callers
> to call pci_create_slot.
> 
> I think the rule should just be:
> 
> 	- all hotplug drivers must use pci_hp_register/deregister
> 	- hotplug drivers must pass a valid hotplug_slot argument
> 
> 	- all detection drivers must use pci_create/destroy_slot
> 	- detection drivers must pass NULL for hotplug_slot
>

I'm still concerned about one thing. Now that we added hotplug
arg to pci_create_slot(), pci_bus_sem could be used for changing
pci_slot->hotplug. But if there is no generic API to clean up
pci_slot->hotplug, we can't use pci_bus_sem because pci hotplug
core cannot hold pci_bus_sem. As a result, we need to add the
following rule in addition to the above rules.

	- hotplug core driver must hold some mutex/semaphore when
	  calling pci_create_slot()
	- hotplug core driver must hold the same mutex/semaphore
	  when cleaning up pci_slot->hotplug.

That is, even though pci_create_slot provides the interface to
setup pci_slot->hotplug, caller needs to pay attention to race
condition about pci_slot->hotplug. I think it's a little strange.

But I might be overcareful...

Thanks,
Kenji Kaneshige


 
> If you prefer, we could wrap pci_create_slot for detection
> drivers:
> 
> struct pci_slot *pci_slot_register(struct pci_bus *parent, int slot_nr,
> 				   const char *name)
> 
> {
> 	return pci_create_slot(parent, slot_nr, name, NULL);
> }
> EXPORT_SYMBOL_GPL(pci_slot_register);
> 
> And then do not export pci_create_slot().
> 
> Hm?
> 
> /ac
> 
> 
> 


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