On Wed, Oct 5, 2016 at 10:46 PM, Bart Van Assche <bart.vanassche@xxxxxxxxxxx> wrote: > On 10/04/16 21:32, Ming Lei wrote: >> >> On Wed, Oct 5, 2016 at 12:16 PM, Bart Van Assche >> <bart.vanassche@xxxxxxxxxxx> wrote: >>> >>> On 10/01/16 15:56, Ming Lei wrote: >>>> >>>> >>>> If we just call the rcu/srcu read lock(or the mutex) around .queue_rq(), >>>> the above code needn't to be duplicated any more. >>> >>> >>> Can you have a look at the attached patch? That patch uses an srcu read >>> lock >>> for all queue types, whether or not the BLK_MQ_F_BLOCKING flag has been >>> set. >> >> >> That is much cleaner now. >> >>> Additionally, I have dropped the QUEUE_FLAG_QUIESCING flag. Just like >>> previous versions, this patch has been tested. >> >> >> I think the flag of QUEUE_FLAG_QUIESCING is still needed because we >> have to set this flag to prevent new coming .queue_rq() from being run, >> and synchronize_srcu() won't wait for completion of that at all (see >> section of 'Update-Side Primitives' in [1]). >> >> [1] https://lwn.net/Articles/202847/ > > > Hello Ming, > > How about using the existing flag BLK_MQ_S_STOPPED instead of introducing a > new QUEUE_FLAG_QUIESCING flag? From the comment above blk_mq_quiesce_queue() That looks fine, and we need to stop direct issue first after hw queue becomes BLK_MQ_S_STOPPED. > in the patch that was attached to my previous e-mail: "Additionally, it is > not prevented that new queue_rq() calls occur unless the queue has been > stopped first." > > Thanks, > > Bart. -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
