On Wed, Oct 18, 2006 at 08:51:04AM -0600, Matthew Wilcox wrote: > This reimplementation uses a global wait queue and a bit per device. > I've open-coded prepare_to_wait() / finish_wait() as I could optimise > it significantly by knowing that the pci_lock protected us at all points. I forgot to report how I've tested it. Using the 'test' patch from yesterday, I have two processes running lspci in an infinite loop. When I write a 1 to /sys/bus/pci/devices/0000\:00\:01.0/block, they both halt. When I write a 0, they both resume. Then I tried doing echo 0 >/sys/bus/pci/devices/0000\:00\:01.0/block a second time, and I got the WARNing I expected. animal:~# echo 1 >/sys/bus/pci/devices/0000\:00\:01.0/block animal:~# echo 1 >/sys/bus/pci/devices/0000\:00\:01.0/block animal:~# echo 0 >/sys/bus/pci/devices/0000\:00\:01.0/block They both resumed (as expected; we don't support nesting). animal:~# echo 1 >/sys/bus/pci/devices/0000\:00\:01.0/block animal:~# echo 1 >/sys/bus/pci/devices/0000\:00\:01.1/block animal:~# echo 0 >/sys/bus/pci/devices/0000\:00\:01.0/block animal:~# echo 0 >/sys/bus/pci/devices/0000\:00\:01.1/block Both resumed only after the second echo 0 (as lspci reads all devices before printing anything). It's not exactly rigorous testing, but I couldn't think of any other cases to try.
