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:   Mon, 10 Jul 2023 18:02:04 +0800
From:   Ming Lei <ming.lei@...hat.com>
To:     Christoph Hellwig <hch@...radead.org>
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>, ming.lei@...hat.com
Subject: Re: [PATCH v6 1/3] ublk: add opcode offsets for DRV_IN/DRV_OUT

On Mon, Jul 10, 2023 at 02:32:44AM -0700, Christoph Hellwig wrote:
> On Mon, Jul 10, 2023 at 05:27:23PM +0800, Ming Lei wrote:
> > Yes, that is exactly what we are doing.
> > 
> > The added macros of UBLK_IO_OP_DRV_IN_START[END] are just for supporting
> > more ublk passthrough commands, and the motivation is for running
> > check(such as buffer direction) in two sides easily.
> > 
> > However, I think it is just fine to delay to add it until introducing
> > the 2nd ublk pt command.
> 
> The concept of a passthrough command just doesn't make sense for an
> on the wire protocol.  It is a linux concept that distinguished between
> the Linux synthetic command like REQ_OP_READ/WRITE/DISCARD etc that are
> well defined and can be used by file systems and other consumers, and
> ways to pass through arbitrary blobs only known by the driver.
> 
> Anything in a wire protocol needs to be very well defined in that
> protocol completely indpendent of what Linux concept it maps to.
> Especially as the Linux concepts can change, and fairly frequently do.

Yeah, you are right wrt. linux pt command, and here we shouldn't use
the term of passthrough.

Actually the UAPI is trying to define interface between driver and
userspace, which is just like interface between driver and hardware, such
as, how nvme/sd_zbc is dealing with actual hardware wrt. reporting
zones.

Thanks,
Ming