On 3/25/19 2:25 AM, Hannes Reinecke wrote: > On 3/25/19 8:37 AM, jianchao.wang wrote: >> Hi Hannes >> >> On 3/25/19 3:18 PM, Hannes Reinecke wrote: >>> On 3/25/19 6:38 AM, Jianchao Wang wrote: >>>> As nobody uses blk_mq_tagset_busy_iter, remove it. >>>> >>>> Signed-off-by: Jianchao Wang <jianchao.w.wang@xxxxxxxxxx> >>>> --- >>>> block/blk-mq-tag.c | 95 -------------------------------------------------- >>>> include/linux/blk-mq.h | 2 -- >>>> 2 files changed, 97 deletions(-) >>>> >>> Please, don't. >>> >>> I'm currently implementing reserved commands for SCSI and reworking >>> the SCSI error handling where I rely on this interface quite >>> heavily. >> >> >> blk_mq_tagset_busy_iter could access some stale requests which maybe >> freed due to io scheduler switching, request_queue cleanup (shared >> tagset) when there is someone submits io and gets driver tag. When io >> scheduler attached, even quiesce request_queue won't work. >> >> If this patchset is accepted, blk_mq_tagset_busy_iter could be >> replaced with blk_mq_queue_inflight_tag_iter which needs to be >> invoked by every request_queue that shares the tagset. >> > The point is, at that time I do _not_ have a request queue to work > with. > > Most SCSI drivers have a host-wide shared tagset, which is used by all > request queues on that host. Iterating over the shared tagset is far > more efficient than to traverse over all devices and the attached > request queues. > > If I had to traverse all request queues I would need to add additional > locking to ensure this traversal is race-free, making it a really > cumbersome interface to use. > > Plus the tagset iter is understood to be used only in cases where I/O > is stopped from the upper layers (ie no new I/O will be submitted). > So here we only need to protect against I/O being completed, which is > not what this patchset is about. > > So my objection still stands: Please, don't. We can't just keep an interface that's hard to use correctly just because you have something pending for that. Jianchao has good suggestions for you on how to proceed. -- Jens Axboe
