Hello, On Thu, Apr 12, 2018 at 03:56:51PM +0200, hch@xxxxxx wrote: > On Thu, Apr 12, 2018 at 06:48:12AM -0700, tj@xxxxxxxxxx wrote: > > > Which sounds like a very good reason not to use a driver controller > > > lock for internals like blkcq. > > > > > > In fact splitting the lock used for synchronizing access to queue > > > fields from the driver controller lock used to synchronize I/O > > > in the legacy path in long overdue. > > > > It'd be probably a lot easier to make sure the shared lock doesn't go > > away till all the request_queues using it go away. The choice is > > between refcnting something which carries the lock and double locking > > in hot paths. Can't think of many downsides of the former approach. > > We've stopped sharing request_queues between different devices a while > ago. The problem is just that for legacy devices the driver still controls > the lock life time, and it might be shorter than the queue lifetime. > Note that for blk-mq we basically don't use the queue_lock at all, > and certainly not in the hot path. Cool, can we just factor out the queue lock from those drivers? It's just really messy to be switching locks like we do in the cleanup path. Thanks. -- tejun
