linux-kernel - Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <31e90477-59fc-8f70-d482-50c25393f58f@suse.de>
Date:   Mon, 25 Sep 2017 07:59:05 +0200
From:   Hannes Reinecke <hare@...e.de>
To:     Sagi Grimberg <sagi@...mberg.me>,
        Johannes Thumshirn <jthumshirn@...e.de>,
        Christoph Hellwig <hch@....de>
Cc:     Keith Busch <keith.busch@...el.com>,
        Linux NVMe Mailinglist <linux-nvme@...ts.infradead.org>,
        Linux Kernel Mailinglist <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable

On 09/25/2017 07:37 AM, Sagi Grimberg wrote:
> 
>> So why exposing it then in the first time? I know you don't want
>> dm-mpath in
>> NVMe (neither do I) but we have to have something until your patchset
>> and ANA
>> is merged. And with this patch it's trivial to build a path checker
>> that just
>> looks at the state attribute in sysfs.
> 
> Can't we just not use path-checkers for nvme (we already have one in
> nvme)?

Really? For NVMe?
How would you do that, then?

Anyway: the entire point is that you don't _need_ a path checker for NVMe.
The primary reason for path checkers is to check with the transport
layer if the remote endpoint is reachable.
(I know, that's not quite what they're doing now, but that's beside the
point).
For NVMf we do have KATO, so the NVMe subsystem knows exactly if the
connection is live or not. So it should be perfectly sufficient to check
the connection state instead of running a path checker of sorts.
But for doing so we need something in sysfs which we could check.

Mind you, I wouldn't be adverse to have some common sysfs attribute,
with some common values (eg path up, path down, path blocked), and have
NVMf translating the internal state into that.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@...e.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)