netdev - Re: [PATCH 1/2] mac802154: add a software MAC 802.15.4 implementation

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, 12 Aug 2009 00:29:29 +0400
From:	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	netdev@...r.kernel.org, linux-zigbee-devel@...ts.sourceforge.net,
	linux-wireless@...r.kernel.org, Sergey Lapin <slapin@...fans.org>
Subject: Re: [PATCH 1/2] mac802154: add a software MAC 802.15.4
 implementation

On Mon, Aug 10, 2009 at 10:28:43AM -0700, Paul E. McKenney wrote:
> On Mon, Aug 10, 2009 at 06:16:39PM +0400, Dmitry Eremin-Solenikov wrote:
> > Some of available devices are just dump radios implementing IEEE 802.15.4
> > PHY layer. This commit adds a common library that acts like an intermediate
> > layer between our socket family and drivers for those dumb devices.
> > 
> > Currently this is data-only part (no commands, no beacons). Control
> > interfaces will follow up shortly.
> > 
> > Note this implementaion is neither certified, nor feature complete!
> 
> One question below, otherwise looks plausible.  (I am not entirely sure
> which lists are which...)
> 
> 							Thanx, Paul

[skipped]

> 
> > +
> > +/*
> > + * This is for hw unregistration only, as it doesn't do RCU locking
> 
> So this list is different than the RCU-protected one, and readers
> always hold locks when traversing it?
> 
> I am not familiar with this code, so might be missing something, but
> it looks to me like the same list that RCU readers traverse.  If so,
> need list_del_rcu() and synchronize_rcu().

On the first glance, yes. On the second glance, list_del instead of
list_del_rcu should be safe as there should be now other list traversals
at the same time. I'll think about it however.

> 
> > + */
> > +void ieee802154_drop_slaves(struct ieee802154_dev *hw)
> > +{
> > +	struct ieee802154_priv *priv = ieee802154_to_priv(hw);
> > +	struct ieee802154_sub_if_data *sdata, *next;
> > +
> > +	ASSERT_RTNL();
> > +
> > +	list_for_each_entry_safe(sdata, next, &priv->slaves, list) {
> > +		mutex_lock(&sdata->hw->slaves_mtx);
> > +		list_del(&sdata->list);
> > +		mutex_unlock(&sdata->hw->slaves_mtx);
> > +
> > +		dev_put(sdata->hw->netdev);
> > +
> > +		unregister_netdevice(sdata->dev);
> > +	}
> > +}

-- 
With best wishes
Dmitry

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html