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:   Wed, 18 Mar 2020 09:54:59 -0300
From:   Jason Gunthorpe <jgg@...lanox.com>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     Doug Ledford <dledford@...hat.com>,
        Leon Romanovsky <leonro@...lanox.com>,
        linux-rdma@...r.kernel.org,
        Michael Guralnik <michaelgur@...lanox.com>,
        netdev@...r.kernel.org, Saeed Mahameed <saeedm@...lanox.com>,
        Yishai Hadas <yishaih@...lanox.com>
Subject: Re: [PATCH rdma-next 0/4] Introduce dynamic UAR allocation mode

On Wed, Mar 18, 2020 at 02:43:25PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@...lanox.com>
> 
> From Yishai,
> 
> This series exposes API to enable a dynamic allocation and management of a
> UAR which now becomes to be a regular uobject.
> 
> Moving to that mode enables allocating a UAR only upon demand and drop the
> redundant static allocation of UARs upon context creation.
> 
> In addition, it allows master and secondary processes that own the same command
> FD to allocate and manage UARs according to their needs, this can’t be achieved
> today.
> 
> As part of this option, QP & CQ creation flows were adapted to support this
> dynamic UAR mode once asked by user space.
> 
> Once this mode is asked by mlx5 user space driver on a given context, it will
> be mutual exclusive, means both the static and legacy dynamic modes for using
> UARs will be blocked.
> 
> The legacy modes are supported for backward compatible reasons, looking
> forward we expect this new mode to be the default.

We are starting to accumulate a lot of code that is now old-rdma-core
only.

I have been wondering if we should add something like

#if CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION < 21
#endif

So we can keep track of what is actually a used code flow and what is
now hard to test legacy code.

eg this config would also disable the write interface(), turn off
compat write interfaces as they are switched to use ioctl, etc, etc.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ