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:
 <SA6PR21MB4231E3DC3F2D88ADFBD0F74DCEC82@SA6PR21MB4231.namprd21.prod.outlook.com>
Date: Tue, 4 Mar 2025 01:58:01 +0000
From: Long Li <longli@...rosoft.com>
To: Jason Gunthorpe <jgg@...pe.ca>, "longli@...uxonhyperv.com"
	<longli@...uxonhyperv.com>
CC: Leon Romanovsky <leon@...nel.org>, Konstantin Taranov
	<kotaranov@...rosoft.com>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, "linux-rdma@...r.kernel.org"
	<linux-rdma@...r.kernel.org>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-hyperv@...r.kernel.org"
	<linux-hyperv@...r.kernel.org>
Subject: RE: [EXTERNAL] Re: [Patch rdma-next] RDMA/mana_ib: handle net event
 for pointing to the current netdev

> Subject: [EXTERNAL] Re: [Patch rdma-next] RDMA/mana_ib: handle net event
> for pointing to the current netdev
> 
> On Fri, Feb 28, 2025 at 02:41:59PM -0800, longli@...uxonhyperv.com wrote:
> > +	struct mana_ib_dev *dev = container_of(this, struct mana_ib_dev,
> nb);
> > +	struct net_device *event_dev = netdev_notifier_info_to_dev(ptr);
> > +	struct gdma_context *gc = dev->gdma_dev->gdma_context;
> > +	struct mana_context *mc = gc->mana.driver_data;
> > +	struct net_device *ndev;
> > +
> > +	if (event_dev != mc->ports[0])
> > +		return NOTIFY_DONE;
> > +
> > +	switch (event) {
> > +	case NETDEV_CHANGEUPPER:
> > +		rcu_read_lock();
> > +		ndev = mana_get_primary_netdev_rcu(mc, 0);
> > +		rcu_read_unlock();
> 
> That locking sure looks weird/wrong.
> 
> Jason

I think the locking is necessary as mana_get_primary_netdev_rcu() requires a RCU lock. It's safe to nest rcu_read_lock() if it's already held.

I have sent v2. v1 is from an earlier branch and is missing some error handling code.

Thanks,
Long

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ