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]

Date:   Mon, 25 Sep 2017 10:09:20 +0300
From:   Sagi Grimberg <sagi@...mberg.me>
To:     Hannes Reinecke <hare@...e.de>,
        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 25/09/17 08:59, Hannes Reinecke wrote:
> 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?

Quick and dirty is to have a path-checker that returns path-up always,
when the path go down, nvme will detect it and fast-fail the io.

> 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.

We could have such an interface I assume. But it would suck to maintain
yet another state (we are already having enough trouble to have a
coherent controller state machine).