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

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>] [day] [month] [year] [list]

Message-ID: <20250410112052.3d7b4f2e@canb.auug.org.au>
Date: Thu, 10 Apr 2025 11:20:52 +1000
From: Stephen Rothwell <sfr@...b.auug.org.au>
To: David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>
Cc: Networking <netdev@...r.kernel.org>, Linux Kernel Mailing List
 <linux-kernel@...r.kernel.org>, Linux Next Mailing List
 <linux-next@...r.kernel.org>, Stanislav Fomichev <sdf@...ichev.me>
Subject: linux-next: manual merge of the net-next tree with the net tree

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:

Content of type "application/pgp-signature" skipped