lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 26 Mar 2019 17:57:27 -0600
From:   Keith Busch <>
To:     "" <>
Cc:     Ming Lei <>, Jens Axboe <>,
        "Busch, Keith" <>,
        James Smart <>,
        Bart Van Assche <>,
        Josef Bacik <>,
        linux-nvme <>,
        Linux Kernel Mailing List <>,
        linux-block <>,
        Hannes Reinecke <>,
        Johannes Thumshirn <>,
        Christoph Hellwig <>,
        Sagi Grimberg <>
Subject: Re: [PATCH V2 7/8] nvme: use blk_mq_queue_tag_inflight_iter

On Mon, Mar 25, 2019 at 08:05:53PM -0700, wrote:
> What if there used to be a io scheduler and leave some stale requests of sched tags ?
> Or the nr_hw_queues was decreased and leave the hctx->fq->flush_rq ?

Requests internally queued in scheduler or block layer are not eligible
for the nvme driver's iterator callback. We only use it to reclaim
dispatched requests that the target can't return, which only applies to
requests that must have a valid rq->tag value from hctx->tags.
> The stable request could be some tings freed and used
> by others and the state field happen to be overwritten to non-zero...

I am not sure I follow what this means. At least for nvme, every queue
sharing the same tagset is quiesced and frozen, there should be no
request state in flux at the time we iterate.

Powered by blists - more mailing lists