On Wed, Aug 26, 2020 at 08:36:33AM -0700, Keith Busch wrote: > On Wed, Aug 26, 2020 at 04:54:22PM +0800, Ming Lei wrote: > > On Wed, Aug 26, 2020 at 03:51:25PM +0800, Chao Leng wrote: > > > It doesn't matter. Because the reentry of quiesce&unquiesce queue is not > > > safe, must be avoided by other mechanism. otherwise, exceptions may > > > occur. Introduce mq_quiesce_lock looks saving possible synchronization > > > waits, but it should not happen. If really happen, we need fix it. > > > > Sagi mentioned there may be nested queue quiesce, so I add .mq_quiesce_lock > > to make this usage easy to support, meantime avoid percpu_ref warning > > in such usage. > > > > Anyway, not see any problem with adding .mq_quiesce_lock, so I'd suggest to > > move on with this way. > > I'm not sure there really are any nested queue quiesce paths, but if > there are, wouldn't we need to track the "depth" like how a queue freeze > works? Both atomic 'depth' and .mq_quiesce_lock can work for nested queue quiesce since we can avoid unnecessary queue quiesce with the mutex. percpu_ref_kill() / percpu_ref_kill_and_confirm() can warn if the percpu_ref has been killed, that is why I think Sagi's suggestion is good. But 'depth' may cause trouble easily, such as unbalanced quiesce/unquiesce, however no such issue with mutex, at least we don't require the two to be paired strictly so far. Thanks, Ming
