Re: [PATCH net-next 3/3 v9] drivers: net: ethernet: qualcomm: rmnet: Initial implementation

[David Miller <davem@davemloft.net>]

From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date: Thu, 24 Aug 2017 22:39:26 -0600

> +static void rmnet_force_unassociate_device(struct net_device *dev)
> +{
> +	struct net_device *real_dev = dev;
> +	struct rmnet_walk_data d;
> +	LIST_HEAD(list);
> +
> +	if (!rmnet_is_real_dev_registered(real_dev))
> +		return;
> +
> +	ASSERT_RTNL();
> +
> +	d.real_dev = real_dev;
> +	d.head = &list;
> +
> +	rcu_read_lock();
> +	netdev_walk_all_lower_dev_rcu(real_dev, rmnet_dev_walk_unreg, &d);
> +	synchronize_net();
> +
> +	unregister_netdevice_many(&list);
> +	rcu_read_unlock();
> +
> +	rmnet_unregister_real_device(real_dev);
> +}

In these code paths where you are the writer, you have to rely upon
the RTNL mutex (or some other mutual exclusion mechanism) to protect
the update operation.  RCU locking itself does not provide this.

So you should use something like rcu_dereference_rtnl() or similar.

So this would be rmnet_force_unassociate_device() and rmnet_dellink()

RCU is subtle and the writer paths have the be handled differently
from the reader paths.  Please take some time to study how RCU should
be applied properly in these situations rather than just slapping a
patch together overnight.

Thank you.