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?