linux-kernel - Re: [PATCH v6 1/3] ublk: add opcode offsets for DRV_IN/DRV

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:   Sun, 9 Jul 2023 23:52:39 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Ming Lei <ming.lei@...hat.com>
Cc:     Damien Le Moal <dlemoal@...nel.org>,
        Andreas Hindborg <nmi@...aspace.dk>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:BLOCK LAYER" <linux-block@...r.kernel.org>,
        Andreas Hindborg <a.hindborg@...sung.com>,
        Minwoo Im <minwoo.im.dev@...il.com>,
        Matias Bjorling <Matias.Bjorling@....com>,
        gost.dev@...sung.com, Jens Axboe <axboe@...nel.dk>,
        Aravind Ramesh <Aravind.Ramesh@....com>,
        Johannes Thumshirn <jth@...nel.org>,
        Hans Holmberg <Hans.Holmberg@....com>,
        Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH v6 1/3] ublk: add opcode offsets for DRV_IN/DRV_OUT

On Fri, Jul 07, 2023 at 08:59:03AM +0800, Ming Lei wrote:
> > let's clearly state so. But then, I still not understand why these need
> > a different naming pattern using the "__UBLK" prefix...
> 
> I think __UBLK just meant we don't suggest userspace to use it directly,
> since the added macros are just for making ranges for DRV_IN and DRV_OUT,
> so we can check command direction easily be using this start/end info in
> both sides.

Folks, please stop coupling a uapi (or on-disk protocol) too tightly
to Linux internals.  Think of what makes sense as a communication
protocol, not what is an internal kernel interface.

REPORT_ZONES is a sensible command, and supported in ATA/SCSI/NVMe in
one way or another.  In Linux it is a synchronous method call right now
for one reason or another, and most implementation map it to a
passthrough command - be that the actual protocol command or something
internal for virtio.

So for ublk this is just another command like any other, that needs to
be defined and documented.  Nothing internal or driver specific.