Re: [RFC] PCI device list locking - take 2

[Chris Wright <chris@wirex.com>]

* Greg KH (greg@kroah.com) wrote:
> Hm, I think we should probably just check in pci_get_device() to verify
> that ->next is really valid.  If it isn't just return NULL, as we have
> no idea what the next device would possibly be.  The worse thing that
> would happen is the proc file would be a bit shorter than expected.  If
> read again, it would be correct, with the previously referenced device
> now gone.

I'm not sure testing a valid ->next makes sense.  It could be non-NULL,
but poison, or if it was using list_del_init, it would be stuck in loop.

> I don't want to try to hold a lock over start/next/stop as that would
> just be asking for trouble :)

Heh, I agree, it doesn't feel quite right to acquire lock and release
lock in separate functions, but in the case of start/show/next/stop this
seems to be the design.  Alternative here seems to be keeping thing on
list with get and deleting from with put on last ref, but that didn't
look so simple.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net