Re: [PATCH] Block on access to temporarily unavailable pci device

[Matthew Wilcox]

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/