linux-kernel - Re: [PATCH rdma-next 03/13] RDMA: Split kernel-only create QP flags from uverbs create QP flags

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: <Y8au3ni8NVBPI5hu@nvidia.com>
Date:   Tue, 17 Jan 2023 10:21:18 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     Israel Rukshin <israelr@...dia.com>,
        Bryan Tan <bryantan@...are.com>,
        Christoph Hellwig <hch@....de>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>, Jens Axboe <axboe@...com>,
        Keith Busch <kbusch@...nel.org>, linux-kernel@...r.kernel.org,
        linux-nvme@...ts.infradead.org, linux-rdma@...r.kernel.org,
        linux-trace-kernel@...r.kernel.org,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Max Gurtovoy <mgurtovoy@...dia.com>, netdev@...r.kernel.org,
        Paolo Abeni <pabeni@...hat.com>,
        Saeed Mahameed <saeedm@...dia.com>,
        Sagi Grimberg <sagi@...mberg.me>,
        Selvin Xavier <selvin.xavier@...adcom.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Vishnu Dasa <vdasa@...are.com>,
        Yishai Hadas <yishaih@...dia.com>
Subject: Re: [PATCH rdma-next 03/13] RDMA: Split kernel-only create QP flags
 from uverbs create QP flags

On Tue, Jan 17, 2023 at 04:14:22PM +0200, Leon Romanovsky wrote:
> On Tue, Jan 17, 2023 at 09:49:28AM -0400, Jason Gunthorpe wrote:
> > On Tue, Jan 17, 2023 at 02:03:07PM +0200, Leon Romanovsky wrote:
> > > On Mon, Jan 16, 2023 at 01:39:38PM -0400, Jason Gunthorpe wrote:
> > > > On Mon, Jan 16, 2023 at 03:05:50PM +0200, Leon Romanovsky wrote:
> > > > 
> > > > > diff --git a/drivers/infiniband/hw/mlx4/mlx4_ib.h b/drivers/infiniband/hw/mlx4/mlx4_ib.h
> > > > > index 17fee1e73a45..c553bf0eb257 100644
> > > > > --- a/drivers/infiniband/hw/mlx4/mlx4_ib.h
> > > > > +++ b/drivers/infiniband/hw/mlx4/mlx4_ib.h
> > > > > @@ -184,7 +184,7 @@ enum mlx4_ib_qp_flags {
> > > > >  	/* Mellanox specific flags start from IB_QP_CREATE_RESERVED_START */
> > > > >  	MLX4_IB_ROCE_V2_GSI_QP = MLX4_IB_QP_CREATE_ROCE_V2_GSI,
> > > > >  	MLX4_IB_SRIOV_TUNNEL_QP = 1 << 30,
> > > > > -	MLX4_IB_SRIOV_SQP = 1 << 31,
> > > > > +	MLX4_IB_SRIOV_SQP = 1ULL << 31,
> > > > >  };
> > > > 
> > > > These should be moved to a uapi if we are saying they are userspace
> > > > available
> > > > 
> > > > But I'm not sure they are?
> > > 
> > > I don't think so.
> > 
> > Then they should be > 32 bits right?
> 
> Right now, they are in reserved range:
>         /* reserve bits 26-31 for low level drivers' internal use */
>         IB_QP_CREATE_RESERVED_START             = 1 << 26,
>         IB_QP_CREATE_RESERVED_END               = 1ULL << 31,
> 
> If we move them to kernel part, we will need to define reserved range
> there too. So we just "burn" extra bits just for mlx4, also I don't see
> any reason to promote mlx4 bits to be general ones.

Is the reserved range kernel only? It would be nice to clarify that
detail

If yes we should move it so that userspace cannot set it. Do we have a
bug here already?

Jason