linux-kernel - Re: [PATCH 1/2] nvme: add per-device io and admin timeouts

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 29 Mar 2019 10:29:25 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Christoph Hellwig <hch@....de>, Maximilian Heyne <mheyne@...zon.de>
Cc:     Amit Shah <aams@...zon.de>, Keith Busch <keith.busch@...el.com>,
        Jens Axboe <axboe@...com>, Sagi Grimberg <sagi@...mberg.me>,
        linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] nvme: add per-device io and admin timeouts

On Fri, 2019-03-29 at 10:44 +0100, Christoph Hellwig wrote:
> On Fri, Mar 29, 2019 at 09:39:20AM +0000, Maximilian Heyne wrote:
> > Some NVMe devices require specific io and admin timeouts that are
> > different from the default, for instance local vs. remote storage.
> > 
> > This patch adds per-device admin and io timeouts to the nvme_ctrl
> > structure and replaces all usages of the module parameters in the PCI
> > NVMe driver with the per-device timeouts.
> 
> I'm not all against a per-controller override, but if you controllers
> really _require_ a different timeout this is not the way to go.
> 
> Please talk to the nvme technical working group about exposing a
> default timeout in the controller as that is the only way to make
> these things work out of box.

Yeah, that's a good idea and would work well on top of these patches
when it eventually gets through the process.

In the meantime, people running Linux in certain environments are
having to hack their kernel to change the default timeout. Being able
to do it through sysfs is much saner.

Max, we should probably also implement this for at least the TCP back
end, which is going to want it for much the same reasons we do, and it
really does want to be tunable by the user there (and should probably
remain so in the general case even when we do improve the spec).

Note that this isn't strictly "required" but if your transport has a
SLA which permits outages of a certain period of time (for example
however long it takes a switch to restart), then having the NVMe
timeout exceed that value is kind of nice.

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5174 bytes)