* 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:27 EST