linux-kernel - Re: nvme: allow ANA support to be independent of native multipathing

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:   Tue, 20 Nov 2018 17:23:43 +0100
From:   Christoph Hellwig <hch@....de>
To:     Mike Snitzer <snitzer@...hat.com>
Cc:     Christoph Hellwig <hch@....de>, Hannes Reinecke <hare@...e.de>,
        linux-nvme@...ts.infradead.org,
        Keith Busch <keith.busch@...el.com>,
        Sagi Grimberg <sagi@...mberg.me>, axboe@...nel.dk,
        Martin Wilck <mwilck@...e.com>, lijie <lijie34@...wei.com>,
        xose.vazquez@...il.com, chengjike.cheng@...wei.com,
        shenhong09@...wei.com, dm-devel@...hat.com,
        wangzhoumengjian@...wei.com, christophe.varoqui@...nsvc.com,
        bmarzins@...hat.com, sschremm@...app.com,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: nvme: allow ANA support to be independent of native
 multipathing

On Tue, Nov 20, 2018 at 08:37:19AM -0500, Mike Snitzer wrote:
> This isn't how a Linux maintainer engages in technical discussion.

And this isn't a technical discussion.   As told before the only
reason to not build the multipath code is to save space, and
the only reason to disable multipath at runtime is for potential
pre-existing setups, which obviously are not ANA capable.

The right fix is to warn users if they use a driver without
CONFIG_NVME_MULTIPATH on a multi-port device and to phase out the
multipath=0 option in the long run, again with a warning.  Any new
additions to "improve" these cases simply don't make sense.