linux-kernel - RE: [PATCH net] ice: Correctly deal with PFs that do not support RDMA

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] [day] [month] [year] [list]

Date:   Thu, 9 Sep 2021 22:02:13 +0000
From:   "Ertman, David M" <david.m.ertman@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "yongxin.liu@...driver.com" <yongxin.liu@...driver.com>,
        "Saleem, Shiraz" <shiraz.saleem@...el.com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
Subject: RE: [PATCH net] ice: Correctly deal with PFs that do not support RDMA

> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Thursday, September 9, 2021 2:49 PM
> To: Ertman, David M <david.m.ertman@...el.com>
> Cc: davem@...emloft.net; yongxin.liu@...driver.com; Saleem, Shiraz
> <shiraz.saleem@...el.com>; Nguyen, Anthony L
> <anthony.l.nguyen@...el.com>; netdev@...r.kernel.org; linux-
> kernel@...r.kernel.org; Brandeburg, Jesse <jesse.brandeburg@...el.com>;
> intel-wired-lan@...ts.osuosl.org
> Subject: Re: [PATCH net] ice: Correctly deal with PFs that do not support
> RDMA
> 
> On Thu,  9 Sep 2021 01:56:12 -0700 Dave Ertman wrote:
> > There are two cases where the current PF does not support RDMA
> > functionality.  The first is if the NVM loaded on the device is set
> > to not support RDMA (common_caps.rdma is false).  The second is if
> > the kernel bonding driver has included the current PF in an active
> > link aggregate.
> >
> > When the driver has determined that this PF does not support RDMA, then
> > auxiliary devices should not be created on the auxiliary bus.  Without
> > a device on the auxiliary bus, even if the irdma driver is present, there
> > will be no RDMA activity attempted on this PF.
> >
> > Currently, in the reset flow, an attempt to create auxiliary devices is
> > performed without regard to the ability of the PF.  There needs to be a
> > check in ice_aux_plug_dev (as the central point that creates auxiliary
> > devices) to see if the PF is in a state to support the functionality.
> >
> > When disabling and re-enabling RDMA due to the inclusion/removal of the
> PF
> > in a link aggregate, we also need to set/clear the bit which controls
> > auxiliary device creation so that a reset recovery in a link aggregate
> > situation doesn't try to create auxiliary devices when it shouldn't.
> >
> > Fixes: f9f5301e7e2d ("ice: Register auxiliary device to provide RDMA")
> > Reported-by: Yongxin Liu <yongxin.liu@...driver.com>
> > Signed-off-by: Dave Ertman <david.m.ertman@...el.com>
> > Signed-off-by: Tony Nguyen <anthony.l.nguyen@...el.com>
> 
> Why CC lkml but not CC RDMA or Leon?

Oversight on my part - thought I had cut-n-pasted all of the address 
in my git send-email command.  Will send again and correct issue