On (Mon) 22 Jul 2013 [15:26:22], Rusty Russell wrote: > Amit Shah <amit.shah@xxxxxxxxxx> writes: > > The removal functions act on the vqs, and the vq operations need to be > > locked. > > > > Signed-off-by: Amit Shah <amit.shah@xxxxxxxxxx> > > How can userspace access the port now? By the time we are cleaning up > buffers, there should be no possibility of such accesses. close(), can happen when the port is being unplugged. We're just making sure here that port_fops_release() and unplug_port() don't try to free up the same data at the same time. > The number of bugfixes here is deeply disturbing. Yes, the first three fix a bug - close() after unplug. However, the others are inadequate locking fixes which I noticed while fixing that bug. Port unplug isn't a frequently-used or tested path, so these were lying unnoticed so far. > I wonder if it's be > easier to rewrite it all with a lock per port, and one global to protect > ports_driver_data. Hm, with this series, I don't see anything that might need extra locking. Though I'll take a look at this afresh in a while -- and see if we could simplify something. Given that this was necessary only for unplug operations, (and they aren't a 'regular operation', so we could drop the stable@ for the series?), are you OK with this series for now? Amit _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
