Subject: linux-next: manual merge of the net-next tree with the net tree

From: Stephen Rothwell <[email-masked]>
Date: Thu, 10 Apr 2025 11:20:52 +1000

Hi all,

Today's linux-next merge of the net-next tree got conflicts in:

  Documentation/networking/netdevices.rst
  net/core/lock_debug.c

between commit:

  04efcee6ef8d ("net: hold instance lock during NETDEV_CHANGE")

from the net tree and commit:

  03df156dd3a6 ("xdp: double protect netdev->xdp_flags with netdev->lock")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/networking/netdevices.rst
index eab601ab2db0,0ccc7dcf4390..000000000000
--- a/Documentation/networking/netdevices.rst
+++ b/Documentation/networking/netdevices.rst
@@@ -338,14 -336,51 +336,52 @@@ operations directly under the netdev in
  Devices drivers are encouraged to rely on the instance lock where possible.
  
  For the (mostly software) drivers that need to interact with the core stack,
 -there are two sets of interfaces: ``dev_xxx`` and ``netif_xxx`` (e.g.,
 -``dev_set_mtu`` and ``netif_set_mtu``). The ``dev_xxx`` functions handle
 -acquiring the instance lock themselves, while the ``netif_xxx`` functions
 -assume that the driver has already acquired the instance lock.
 +there are two sets of interfaces: ``dev_xxx``/``netdev_xxx`` and ``netif_xxx``
 +(e.g., ``dev_set_mtu`` and ``netif_set_mtu``). The ``dev_xxx``/``netdev_xxx``
 +functions handle acquiring the instance lock themselves, while the
 +``netif_xxx`` functions assume that the driver has already acquired
 +the instance lock.
  
+ struct net_device_ops
+ ---------------------
+ 
+ ``ndos`` are called without holding the instance lock for most drivers.
+ 
+ "Ops locked" drivers will have most of the ``ndos`` invoked under
+ the instance lock.
+ 
+ struct ethtool_ops
+ ------------------
+ 
+ Similarly to ``ndos`` the instance lock is only held for select drivers.
+ For "ops locked" drivers all ethtool ops without exceptions should
+ be called under the instance lock.
+ 
+ struct netdev_stat_ops
+ ----------------------
+ 
+ "qstat" ops are invoked under the instance lock for "ops locked" drivers,
+ and under rtnl_lock for all other drivers.
+ 
+ struct net_shaper_ops
+ ---------------------
+ 
+ All net shaper callbacks are invoked while holding the netdev instance
+ lock. ``rtnl_lock`` may or may not be held.
+ 
+ Note that supporting net shapers automatically enables "ops locking".
+ 
+ struct netdev_queue_mgmt_ops
+ ----------------------------
+ 
+ All queue management callbacks are invoked while holding the netdev instance
+ lock. ``rtnl_lock`` may or may not be held.
+ 
+ Note that supporting struct netdev_queue_mgmt_ops automatically enables
+ "ops locking".
+ 
  Notifiers and netdev instance lock
- ==================================
+ ----------------------------------
  
  For device drivers that implement shaping or queue management APIs,
  some of the notifiers (``enum netdev_cmd``) are running under the netdev
@@@ -355,7 -390,7 +391,8 @@@ For devices with locked ops, currently 
  running under the lock:
  * ``NETDEV_REGISTER``
  * ``NETDEV_UP``
 +* ``NETDEV_CHANGE``
+ * ``NETDEV_XDP_FEAT_CHANGE``
  
  The following notifiers are running without the lock:
  * ``NETDEV_UNREGISTER``
diff --cc net/core/lock_debug.c
index 941e26c1343d,598c443ef2f3..000000000000
--- a/net/core/lock_debug.c
+++ b/net/core/lock_debug.c
@@@ -20,7 -20,7 +20,8 @@@ int netdev_debug_event(struct notifier_
  	switch (cmd) {
  	case NETDEV_REGISTER:
  	case NETDEV_UP:
 +	case NETDEV_CHANGE:
+ 	case NETDEV_XDP_FEAT_CHANGE:
  		netdev_ops_assert_locked(dev);
  		fallthrough;
  	case NETDEV_DOWN: