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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ