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]
Message-ID:
 <BN8PR15MB25139C984234B4B7413D25F899192@BN8PR15MB2513.namprd15.prod.outlook.com>
Date: Wed, 15 Jan 2025 11:17:51 +0000
From: Bernard Metzler <BMT@...ich.ibm.com>
To: Stephen Rothwell <sfr@...b.auug.org.au>, Jason Gunthorpe <jgg@...dia.com>
CC: Junxian Huang <huangjunxian6@...ilicon.com>,
        Leon Romanovsky
	<leon@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Yuyu Li
	<liyuyu6@...wei.com>
Subject: RE: linux-next: manual merge of the rdma tree with Linus' tree

> -----Original Message-----
> From: Stephen Rothwell <sfr@...b.auug.org.au>
> Sent: Wednesday, January 15, 2025 2:08 AM
> To: Jason Gunthorpe <jgg@...dia.com>
> Cc: Bernard Metzler <BMT@...ich.ibm.com>; Junxian Huang
> <huangjunxian6@...ilicon.com>; Leon Romanovsky <leon@...nel.org>; Linux
> Kernel Mailing List <linux-kernel@...r.kernel.org>; Linux Next Mailing List
> <linux-next@...r.kernel.org>; Yuyu Li <liyuyu6@...wei.com>
> Subject: [EXTERNAL] Re: linux-next: manual merge of the rdma tree with
> Linus' tree
> 
> Hi Jason,
> 
> On Tue, 14 Jan 2025 20:41:30 -0400 Jason Gunthorpe <jgg@...dia.com> wrote:
> >
> > On Wed, Jan 15, 2025 at 08:27:21AM +1100, Stephen Rothwell wrote:
> > > Hi Jason,
> > >
> > > On Tue, 14 Jan 2025 16:48:28 -0400 Jason Gunthorpe <jgg@...dia.com>
> wrote:
> > > >
> > > > I think we need to retain the ib_get_curr_port_state() call:
> > >
> > > Why?
> >
> > That is how the new system is supposed to work.. Drivers are supposed
> > to call ib_get_curr_port_state() not open code it. This matches what
> > is in the for-next tree:
> >
> >         attr->state = ib_get_curr_port_state(sdev->netdev);
> >         attr->phys_state = attr->state == IB_PORT_ACTIVE ?
> >                 IB_PORT_PHYS_STATE_LINK_UP : IB_PORT_PHYS_STATE_DISABLED;
> >
> > > It is no longer used to determine the attr->phys-state value and
> > > then attr->state is set again just below.
> >
> > Ah, missed that, it should be deleted also, and the phys_state should
> > use the other hunk too:
> >
> > --- drivers/infiniband/sw/siw/siw_verbs.c       2025-01-14
> 16:37:02.023738738 -0400
> > +++ /home/jgg/oss/testing-k.o/drivers/infiniband/sw/siw/siw_verbs.c
> 2025-01-14 20:38:42.611302948 -0400
> > @@ -189,10 +189,9 @@
> >         attr->max_msg_sz = -1;
> >         attr->max_mtu = ib_mtu_int_to_enum(ndev->max_mtu);
> >         attr->active_mtu = ib_mtu_int_to_enum(READ_ONCE(ndev->mtu));
> > -       attr->phys_state = (netif_running(ndev) &&
> netif_carrier_ok(ndev)) ?
> > +       attr->state = ib_get_curr_port_state(ndev);
> > +       attr->phys_state = attr->state == IB_PORT_ACTIVE ?
> >                 IB_PORT_PHYS_STATE_LINK_UP : IB_PORT_PHYS_STATE_DISABLED;
> > -       attr->state = attr->phys_state == IB_PORT_PHYS_STATE_LINK_UP ?
> > -               IB_PORT_ACTIVE : IB_PORT_DOWN;
> >         attr->port_cap_flags = IB_PORT_CM_SUP | IB_PORT_DEVICE_MGMT_SUP;
> >         /*
> >          * All zero
> 
> Thanks, I have updated my resolution to that today.

Hi Jason, Stephen, I agree. Thanks very much for taking care of it!

Cheers, Bernard.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ