Sasha Levin [off-list ref] writes:

On Mon, Apr 16, 2012 at 12:59 PM, Aneesh Kumar K.V
[off-list ref] wrote:

quoted

Sasha Levin [off-list ref] writes:

quoted

On Sun, Apr 15, 2012 at 2:27 PM, Aneesh Kumar K.V
[off-list ref] wrote:

quoted

Sasha Levin [off-list ref] writes:

quoted

When a virtio_9p pci device is being removed, we should close down any
active channels and free up resources, we're not supposed to BUG() if there's
still an open channel since it's a valid case when removing the PCI device.

Otherwise, removing the PCI device with an open channel would cause the
following BUG():

...

quoted

diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index 3d43206..5af18d1 100644
--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c

@@ -615,7 +615,8 @@ static void p9_virtio_remove(struct virtio_device *vdev)

 {
      struct virtio_chan *chan = vdev->priv;

-     BUG_ON(chan->inuse);
+     if (chan->inuse)
+             p9_virtio_close(chan->client);
      vdev->config->del_vqs(vdev);

      mutex_lock(&virtio_9p_lock);

But an umount should have resulted in p9_virtio_close ? How are you
removing the device ? Are you removing the device with file system
mounted  ?. In that case may be we should return EBUSY ?

I signal the underlying PCI device to remove (echo 1 >
/sys/devices/pci0000\:00/[...]/remove), we can't really prevent that
thing so we must clean up ourselves.

What does that mean for the mounted file system ? What would happen to
the pending fs operations in that case ?

I'm guessing that all of them should be canceled.

Pending operation we can cancel, but what about dirty pages in cached
mode ? Also how does virtio-blk handle this ? 

virtio-pci simulates
a PCI device, if the PCI device is unplugged there's not much to do
about the filesystem or pending requests.

Ideal thing to do would be to make remove return -EBUSY; let the user
umount. But looking at the code, I guess there is no easy way to return
error from remove callback ?

-aneesh