[PATCH batadv 0/8] batman-adv: follow up fixes

[PATCH batadv 0/8] batman-adv: follow up fixes

[Sven Eckelmann]

While reviewing the fixes submitted to batman-adv in the recent weeks,
further problems in similar or adjecent code was identified. This was either
noticed in the manual review or reported by sashiko.dev.

Especially in the TT code, you have the global and the local translation
table. But when a bug was fixed, often only one of the two codepaths was
fixed. It was now tried to sync the TVLV preparation code between to of
them - not style wise but fixes wise. Besides the hardening, it will also
make the code less confusing.

The BLA and TP fixes are just some reference counting fixes - either
reference leak fixes or missing reference handling.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
Sven Eckelmann (8):
      batman-adv: tp_meter: fix tp_num leak on kmalloc failure
      batman-adv: bla: prevent use-after-free when deleting claims
      batman-adv: bla: only purge non-released claims
      batman-adv: tt: fix negative tt_buff_len
      batman-adv: tt: reject oversized local TVLV buffers
      batman-adv: tt: fix TOCTOU race for reported vlans
      batman-adv: tt: avoid empty VLAN responses
      batman-adv: tt: prevent TVLV entry number overflow

 net/batman-adv/bridge_loop_avoidance.c | 10 ++++++-
 net/batman-adv/tp_meter.c              |  5 +++-
 net/batman-adv/translation-table.c     | 55 +++++++++++++++++++++++++++-------
 net/batman-adv/types.h                 |  2 +-
 4 files changed, 58 insertions(+), 14 deletions(-)
---
base-commit: 3d3cf6a7314aca4df0a6dde28ce784a2a30d0166
change-id: 20260503-fixes-followup-064092b7ff55

Best regards,
--  
Sven Eckelmann <sven@narfation.org>

[PATCH batadv 1/8] batman-adv: tp_meter: fix tp_num leak on kmalloc failure

[Sven Eckelmann]

When batadv_tp_start() or batadv_tp_init_recv() fail to allocate a new
tp_vars object, the previously incremented bat_priv->tp_num counter is
never decremented. This causes tp_num to drift upward on each allocation
failure. Since only BATADV_TP_MAX_NUM sessions can be started and the count
is never reduced for these failed allocations, it causes to an exhaustion
of throughput meter sessions. In worst case, no new throughput meter
session can be started until the mesh interface is removed.

The error handling must decrement tp_num releasing the lock and aborting
the creation of an throughput meter session

Cc: stable@kernel.org
Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
 net/batman-adv/tp_meter.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/batman-adv/tp_meter.c b/net/batman-adv/tp_meter.c
index 58ca59a2799e..066c76113fc4 100644
--- a/net/batman-adv/tp_meter.c
+++ b/net/batman-adv/tp_meter.c
@@ -994,6 +994,7 @@ void batadv_tp_start(struct batadv_priv *bat_priv, const u8 *dst,
 
 	tp_vars = kmalloc_obj(*tp_vars, GFP_ATOMIC);
 	if (!tp_vars) {
+		atomic_dec(&bat_priv->tp_num);
 		spin_unlock_bh(&bat_priv->tp_list_lock);
 		batadv_dbg(BATADV_DBG_TP_METER, bat_priv,
 			   "Meter: %s cannot allocate list elements\n",
@@ -1366,8 +1367,10 @@ batadv_tp_init_recv(struct batadv_priv *bat_priv,
 	}
 
 	tp_vars = kmalloc_obj(*tp_vars, GFP_ATOMIC);
-	if (!tp_vars)
+	if (!tp_vars) {
+		atomic_dec(&bat_priv->tp_num);
 		goto out_unlock;
+	}
 
 	ether_addr_copy(tp_vars->other_end, icmp->orig);
 	tp_vars->role = BATADV_TP_RECEIVER;

-- 
2.47.3

[PATCH batadv 2/8] batman-adv: bla: prevent use-after-free when deleting claims

[Sven Eckelmann]

When batadv_bla_del_backbone_claims() removes all claims for a backbone, it
does this by dropping the link entry in the hash list. This list entry
itself was one of the references which need to be dropped at the same time
via batadv_claim_put().

But the batadv_claim_put() must not be done before the last access to the
claim object in this function. Otherwise the claim might be freed already
by the batadv_claim_release() function before the list entry was dropped.

Cc: stable@kernel.org
Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
 net/batman-adv/bridge_loop_avoidance.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c
index 51fe028b9088..8b77dd2ecfa4 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -318,8 +318,8 @@ batadv_bla_del_backbone_claims(struct batadv_bla_backbone_gw *backbone_gw)
 			if (claim->backbone_gw != backbone_gw)
 				continue;
 
-			batadv_claim_put(claim);
 			hlist_del_rcu(&claim->hash_entry);
+			batadv_claim_put(claim);
 		}
 		spin_unlock_bh(list_lock);
 	}

-- 
2.47.3

[PATCH batadv 3/8] batman-adv: bla: only purge non-released claims

[Sven Eckelmann]

When batadv_bla_purge_claims() goes through the list of claims, it is only
traversing the hash list with an rcu_read_lock(). Due to a potential
parallel batadv_claim_put(), it can happen that it encounters a claim which
was actually in the process of being released+freed by
batadv_claim_release(). In this case, backbone_gw is set to NULL before the
delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is
then no longer allowed because it would cause a NULL-ptr derefence.

To avoid this, only claims with a valid reference counter must be purged.
All others are already taken care of.

Cc: stable@kernel.org
Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
 net/batman-adv/bridge_loop_avoidance.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c
index 8b77dd2ecfa4..9dbf945b4922 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1288,6 +1288,13 @@ static void batadv_bla_purge_claims(struct batadv_priv *bat_priv,
 
 		rcu_read_lock();
 		hlist_for_each_entry_rcu(claim, head, hash_entry) {
+			/* only purge claims not currently in the process of being released.
+			 * Such claims could otherwise have a NULL-ptr* backbone_gw set because
+			 * they already went through batadv_handle_unclaim()
+			 */
+			if (!kref_get_unless_zero(&claim->refcount))
+				continue;
+
 			backbone_gw = batadv_bla_claim_get_backbone_gw(claim);
 			if (now)
 				goto purge_now;
@@ -1313,6 +1320,7 @@ static void batadv_bla_purge_claims(struct batadv_priv *bat_priv,
 					      claim->addr, claim->vid);
 skip:
 			batadv_backbone_gw_put(backbone_gw);
+			batadv_claim_put(claim);
 		}
 		rcu_read_unlock();
 	}

-- 
2.47.3

[PATCH batadv 4/8] batman-adv: tt: fix negative tt_buff_len

[Sven Eckelmann]

batadv_orig_node::tt_buff_len was declared as s16, but the field is never
intended to hold a negative value. When a value greater than 32767 is
assigned, it wraps to a negative signed integer.

In batadv_send_other_tt_response(), tt_buff_len is temporarily widened to
s32. The incorrectly negative s16 value propagates into the s32, causing
batadv_tt_prepare_tvlv_global_data() to allocate a full sized buffer but
populates only a small portion of it with the collected changeset. All
remaining bits are kept uninitialized.

Using an u16 avoids this type confusion and ensures that no (negative) sign
extension is performed in batadv_send_other_tt_response().

Cc: stable@kernel.org
Fixes: a73105b8d4c7 ("batman-adv: improved client announcement mechanism")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
 net/batman-adv/types.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h
index daa06f421154..0f3814b458cc 100644
--- a/net/batman-adv/types.h
+++ b/net/batman-adv/types.h
@@ -452,7 +452,7 @@ struct batadv_orig_node {
 	 * @tt_buff_len: length of the last tt changeset this node received
 	 *  from the orig node
 	 */
-	s16 tt_buff_len;
+	u16 tt_buff_len;
 
 	/** @tt_buff_lock: lock that protects tt_buff and tt_buff_len */
 	spinlock_t tt_buff_lock;

-- 
2.47.3

[PATCH batadv 5/8] batman-adv: tt: reject oversized local TVLV buffers

[Sven Eckelmann]

The commit 3a359bf5c61d ("batman-adv: reject oversized global TT response
buffers") added a check to ensure that a global return buffer size can be
stored in an u16. The same buffer handling also exists for the local data
buffer but was not touched.

A similar check should be also be in place for the local TVLV buffer. It
doesn't have the similar attack surface because it is only generated from
locally discovered MAC addresses but the dynamic nature could still cause
temporarily to large buffers.

Cc: stable@kernel.org
Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
 net/batman-adv/translation-table.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index 05cddcf994f6..06548dae1039 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -877,12 +877,12 @@ batadv_tt_prepare_tvlv_local_data(struct batadv_priv *bat_priv,
 {
 	struct batadv_tvlv_tt_vlan_data *tt_vlan;
 	struct batadv_meshif_vlan *vlan;
+	size_t change_offset;
 	u16 num_vlan = 0;
 	u16 vlan_entries = 0;
 	u16 total_entries = 0;
 	u16 tvlv_len;
 	u8 *tt_change_ptr;
-	int change_offset;
 
 	spin_lock_bh(&bat_priv->meshif_vlan_list_lock);
 	hlist_for_each_entry(vlan, &bat_priv->meshif_vlan_list, list) {
@@ -900,8 +900,10 @@ batadv_tt_prepare_tvlv_local_data(struct batadv_priv *bat_priv,
 	if (*tt_len < 0)
 		*tt_len = batadv_tt_len(total_entries);
 
-	tvlv_len = *tt_len;
-	tvlv_len += change_offset;
+	if (check_add_overflow(*tt_len, change_offset, &tvlv_len)) {
+		tvlv_len = 0;
+		goto out;
+	}
 
 	*tt_data = kmalloc(tvlv_len, GFP_ATOMIC);
 	if (!*tt_data) {

-- 
2.47.3

[PATCH batadv 6/8] batman-adv: tt: fix TOCTOU race for reported vlans

[Sven Eckelmann]

The local TT based TVLV is generated by first checking the number of VLANs
which have at least one TT entry. A new buffer with the correct size for
the VLANs is then allocated. Only then, the list of VLANs s used to fill
the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock
is held. But the actual number of TT entries of each VLAN can still
increase during this time - just not the number of VLANs in the list.

But the prefilter used in the buffer size calculation might still cause an
increase of the number of VLANs which need to be stored. Simply because a
VLAN might now suddenly have at least one entry when it had none in the
pre-alloc check - and then needs to occupy space which was not allocated.

It is better to overestimate the buffer size at the beginning and then fill
the buffer only with the VLANs which are not empty.

Cc: stable@kernel.org
Fixes: 16116dac2339 ("batman-adv: prevent TT request storms by not sending inconsistent TT TLVLs")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
 net/batman-adv/translation-table.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index 06548dae1039..f5b9143c803a 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -887,11 +887,8 @@ batadv_tt_prepare_tvlv_local_data(struct batadv_priv *bat_priv,
 	spin_lock_bh(&bat_priv->meshif_vlan_list_lock);
 	hlist_for_each_entry(vlan, &bat_priv->meshif_vlan_list, list) {
 		vlan_entries = atomic_read(&vlan->tt.num_entries);
-		if (vlan_entries < 1)
-			continue;
-
-		num_vlan++;
 		total_entries += vlan_entries;
+		num_vlan++;
 	}
 
 	change_offset = struct_size(*tt_data, vlan_data, num_vlan);
@@ -913,9 +910,9 @@ batadv_tt_prepare_tvlv_local_data(struct batadv_priv *bat_priv,
 
 	(*tt_data)->flags = BATADV_NO_FLAGS;
 	(*tt_data)->ttvn = atomic_read(&bat_priv->tt.vn);
-	(*tt_data)->num_vlan = htons(num_vlan);
 
 	tt_vlan = (*tt_data)->vlan_data;
+	num_vlan = 0;
 	hlist_for_each_entry(vlan, &bat_priv->meshif_vlan_list, list) {
 		vlan_entries = atomic_read(&vlan->tt.num_entries);
 		if (vlan_entries < 1)
@@ -926,8 +923,15 @@ batadv_tt_prepare_tvlv_local_data(struct batadv_priv *bat_priv,
 		tt_vlan->reserved = 0;
 
 		tt_vlan++;
+		num_vlan++;
 	}
 
+	/* recalculate in case number of VLANs reduced */
+	change_offset = struct_size(*tt_data, vlan_data, num_vlan);
+	tvlv_len = *tt_len + change_offset;
+
+	(*tt_data)->num_vlan = htons(num_vlan);
+
 	tt_change_ptr = (u8 *)*tt_data + change_offset;
 	*tt_change = (struct batadv_tvlv_tt_change *)tt_change_ptr;
 

-- 
2.47.3

[PATCH batadv 7/8] batman-adv: tt: avoid empty VLAN responses

[Sven Eckelmann]

The commit 16116dac2339 ("batman-adv: prevent TT request storms by not
sending inconsistent TT TLVLs") added checks to the local (direct) TT
response code. But the response can also be done indirectly by another node
using the global TT state. To avoid such inconsistency states reported in
the original fix, also avoid sending empty VLANs for replies from the
global TT state.

Cc: stable@kernel.org
Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
 net/batman-adv/translation-table.c | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index f5b9143c803a..5a005d4e6cc6 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -797,24 +797,26 @@ batadv_tt_prepare_tvlv_global_data(struct batadv_orig_node *orig_node,
 				   s32 *tt_len)
 {
 	u16 num_vlan = 0;
-	u16 num_entries = 0;
 	u16 tvlv_len = 0;
 	unsigned int change_offset;
 	struct batadv_tvlv_tt_vlan_data *tt_vlan;
 	struct batadv_orig_node_vlan *vlan;
+	u16 total_entries = 0;
 	u8 *tt_change_ptr;
+	int vlan_entries;
 
 	spin_lock_bh(&orig_node->vlan_list_lock);
 	hlist_for_each_entry(vlan, &orig_node->vlan_list, list) {
+		vlan_entries = atomic_read(&vlan->tt.num_entries);
+		total_entries += vlan_entries;
 		num_vlan++;
-		num_entries += atomic_read(&vlan->tt.num_entries);
 	}
 
 	change_offset = struct_size(*tt_data, vlan_data, num_vlan);
 
 	/* if tt_len is negative, allocate the space needed by the full table */
 	if (*tt_len < 0)
-		*tt_len = batadv_tt_len(num_entries);
+		*tt_len = batadv_tt_len(total_entries);
 
 	if (change_offset > U16_MAX || *tt_len > U16_MAX - change_offset) {
 		*tt_len = 0;
@@ -832,17 +834,28 @@ batadv_tt_prepare_tvlv_global_data(struct batadv_orig_node *orig_node,
 
 	(*tt_data)->flags = BATADV_NO_FLAGS;
 	(*tt_data)->ttvn = atomic_read(&orig_node->last_ttvn);
-	(*tt_data)->num_vlan = htons(num_vlan);
 
 	tt_vlan = (*tt_data)->vlan_data;
+	num_vlan = 0;
 	hlist_for_each_entry(vlan, &orig_node->vlan_list, list) {
+		vlan_entries = atomic_read(&vlan->tt.num_entries);
+		if (vlan_entries < 1)
+			continue;
+
 		tt_vlan->vid = htons(vlan->vid);
 		tt_vlan->crc = htonl(vlan->tt.crc);
 		tt_vlan->reserved = 0;
 
 		tt_vlan++;
+		num_vlan++;
 	}
 
+	/* recalculate in case number of VLANs reduced */
+	change_offset = struct_size(*tt_data, vlan_data, num_vlan);
+	tvlv_len = *tt_len + change_offset;
+
+	(*tt_data)->num_vlan = htons(num_vlan);
+
 	tt_change_ptr = (u8 *)*tt_data + change_offset;
 	*tt_change = (struct batadv_tvlv_tt_change *)tt_change_ptr;
 

-- 
2.47.3

[PATCH batadv 8/8] batman-adv: tt: prevent TVLV entry number overflow

[Sven Eckelmann]

The helpers to prepare the buffers for the local and global TT based
replies are trying to sum up all TT entries which can be found for each
VLAN. In theory, this sum can be too big for an u16 and therefore overflow.
A too small buffer would then be allocated for the TVLV.

The too small buffer will be handled gracefully by
batadv_tt_tvlv_generate() and is not causing a buffer overflow - just a
truncated reply. But this overflow shouldn't have happened in the first and
the too small buffer should never have been allocated when an overflow was
detected.

Cc: stable@kernel.org
Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
 net/batman-adv/translation-table.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index 5a005d4e6cc6..630ae8a66beb 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -804,11 +804,18 @@ batadv_tt_prepare_tvlv_global_data(struct batadv_orig_node *orig_node,
 	u16 total_entries = 0;
 	u8 *tt_change_ptr;
 	int vlan_entries;
+	u16 sum_entries;
 
 	spin_lock_bh(&orig_node->vlan_list_lock);
 	hlist_for_each_entry(vlan, &orig_node->vlan_list, list) {
 		vlan_entries = atomic_read(&vlan->tt.num_entries);
-		total_entries += vlan_entries;
+
+		if (check_add_overflow(vlan_entries, total_entries, &sum_entries)) {
+			*tt_len = 0;
+			goto out;
+		}
+
+		total_entries = sum_entries;
 		num_vlan++;
 	}
 
@@ -896,11 +903,18 @@ batadv_tt_prepare_tvlv_local_data(struct batadv_priv *bat_priv,
 	u16 total_entries = 0;
 	u16 tvlv_len;
 	u8 *tt_change_ptr;
+	u16 sum_entries;
 
 	spin_lock_bh(&bat_priv->meshif_vlan_list_lock);
 	hlist_for_each_entry(vlan, &bat_priv->meshif_vlan_list, list) {
 		vlan_entries = atomic_read(&vlan->tt.num_entries);
-		total_entries += vlan_entries;
+
+		if (check_add_overflow(vlan_entries, total_entries, &sum_entries)) {
+			tvlv_len = 0;
+			goto out;
+		}
+
+		total_entries = sum_entries;
 		num_vlan++;
 	}
 

-- 
2.47.3

Re: [PATCH batadv 0/8] batman-adv: follow up fixes

[Jakub Kicinski]

On Sun, 03 May 2026 14:22:33 +0200 Sven Eckelmann wrote:
> While reviewing the fixes submitted to batman-adv in the recent weeks,
> further problems in similar or adjecent code was identified. This was either
> noticed in the manual review or reported by sashiko.dev.

Are you CCing netdev to get this reviewed by Sashiko?
Please don't..
We delegate code to sub-sub-systems to lower the patch volume :(

Re: [PATCH batadv 0/8] batman-adv: follow up fixes

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

On Tuesday, 5 May 2026 02:10:51 CEST Jakub Kicinski wrote:
> On Sun, 03 May 2026 14:22:33 +0200 Sven Eckelmann wrote:
> > While reviewing the fixes submitted to batman-adv in the recent weeks,
> > further problems in similar or adjecent code was identified. This was either
> > noticed in the manual review or reported by sashiko.dev.
> 
> Are you CCing netdev to get this reviewed by Sashiko?
> Please don't..
> We delegate code to sub-sub-systems to lower the patch volume :(
> 

Because of `b4 prep --auto-to-cc`. Will now manually remove you.

Regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH batadv 0/8] batman-adv: follow up fixes

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

On Tuesday, 5 May 2026 06:46:11 CEST Sven Eckelmann wrote:
> On Tuesday, 5 May 2026 02:10:51 CEST Jakub Kicinski wrote:
> > On Sun, 03 May 2026 14:22:33 +0200 Sven Eckelmann wrote:
> > > While reviewing the fixes submitted to batman-adv in the recent weeks,
> > > further problems in similar or adjecent code was identified. This was either
> > > noticed in the manual review or reported by sashiko.dev.
> > 
> > Are you CCing netdev to get this reviewed by Sashiko?
> > Please don't..
> > We delegate code to sub-sub-systems to lower the patch volume :(
> > 
> 
> Because of `b4 prep --auto-to-cc`. Will now manually remove you.

To speed up the discussion: @Konstantin, is there a way in b4 to say "stop at 
the sub-sub-systems" when doing `b4 prep --auto-to-cc`? I am just trying to get the 
`b4` workflow somehow working with the netdev requirements.

Regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH batadv 0/8] batman-adv: follow up fixes

[Matthieu Baerts]

Hi Sven,

05 May 2026 07:00:27 Sven Eckelmann <sven@narfation.org>:

> On Tuesday, 5 May 2026 06:46:11 CEST Sven Eckelmann wrote:
>> On Tuesday, 5 May 2026 02:10:51 CEST Jakub Kicinski wrote:
>>> On Sun, 03 May 2026 14:22:33 +0200 Sven Eckelmann wrote:
>>>> While reviewing the fixes submitted to batman-adv in the recent weeks,
>>>> further problems in similar or adjecent code was identified. This was either
>>>> noticed in the manual review or reported by sashiko.dev.
>>>
>>> Are you CCing netdev to get this reviewed by Sashiko?
>>> Please don't..
>>> We delegate code to sub-sub-systems to lower the patch volume :(
>>>
>>
>> Because of `b4 prep --auto-to-cc`. Will now manually remove you.
>
> To speed up the discussion: @Konstantin, is there a way in b4 to say "stop at
> the sub-sub-systems" when doing `b4 prep --auto-to-cc`? I am just trying to get the
> `b4` workflow somehow working with the netdev requirements.

Maybe a new option could be added, but that seems difficult to guess
where to stop, and to which subsystems to apply this.

Can you not simply omit using `b4 prep --auto-to-cc` when working
with "internal" patches?

On my side, that's what I'm doing. I added a .b4-config file with this
content, not to have to specify --set-prefix nor --to:

[b4]
    send-series-to = MPTCP Linux <mptcp@lists.linux.dev>
    prep-pre-flight-checks = disable-needs-auto-to-cc
    send-prefixes = mptcp-next

Cheers,
Matt

Re: [PATCH batadv 0/8] batman-adv: follow up fixes

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 3651 bytes --]

On Tuesday, 5 May 2026 07:21:13 CEST Matthieu Baerts wrote:
[...]
> >>> Are you CCing netdev to get this reviewed by Sashiko?
> >>> Please don't..
> >>> We delegate code to sub-sub-systems to lower the patch volume :(
> >>>
> >>
> >> Because of `b4 prep --auto-to-cc`. Will now manually remove you.
> >
> > To speed up the discussion: @Konstantin, is there a way in b4 to say "stop at
> > the sub-sub-systems" when doing `b4 prep --auto-to-cc`? I am just trying to get the
> > `b4` workflow somehow working with the netdev requirements.
> 
> Maybe a new option could be added, but that seems difficult to guess
> where to stop, and to which subsystems to apply this.
> 
> Can you not simply omit using `b4 prep --auto-to-cc` when working
> with "internal" patches?

Yes, no, maybe :)
I will for the moment ignore the .b4-config part and talk about it at the end 
of the mail.

b4 is trying to (afaik) to have a good common work flow for kernel related 
projects (and more). Independent of my role (if I am the maintainer or just 
another contributor), it will nag before a send: "Hey, please run 
--auto-to-cc, --check, --check-deps before you submit this patch(set) - you 
know how embarrassing it is when you notice some obvious problem 2 seconds 
after the SMTP server accepted your mail."

And I agree with this and also try to convince people to try b4 because I 
think it is really helpful. Or at least ask them to use
`./scripts/get_maintainer.pl` and NOT send patches with the prefix "net" or 
"net-next" when it actually targets our tree. But as it turns out, these 
recommendation seem to have been wrong and I am sorry about this.

And I know, b4 is a good tool but adding a bazillion options just for every 
special case doesn't make a lot of sense and might make it a worse tool. I was 
therefore more thinking about `scripts/get_maintainer.pl`  (see `b4.send-auto-
cc-cmd`) which also called by b4 with various options to avoid adding too many 
people.

I don't say that any of these tools need to change. I am guessing more that I 
have to adjust something (MAINTAINERS, ...) to avoid that people are sending 
batman-adv sub-sub-system patches directly to netdev. I am just not aware of 
what this should be. But it sounds to me like there is at least a need for it 
(from the netdev maintainers perspective).

> On my side, that's what I'm doing. I added a .b4-config file with this
> content, not to have to specify --set-prefix nor --to:

Regarding the .b4-config - yes, this is helpful and I should add it to 
batctl.git. I was more thinking about the normal contributor to 
net/batman-adv/. Regardless of this person taking as base net/net-next.git or 
our repo.

The fixes from Ren Wei (and associates) and some other people were sent with 
"net" in the prefix, were Cc'ing netdev and didn't seem to use our tree as 
base. This is of course not correct and they should have targeted our tree 
instead. I didn't complain because the fix was otherwise extremely helpful and 
I though that there was no harm done. As it looks now, I should have and I am 
sorry for not communicating this.

And I am at the moment not sure how to fix this without overloading 
contributers with "when you are contributing to some sub-subsystem of netdev 
..., but when you are contributing to ext4, other rules apply .... don't 
forget about i2c rules for patch submission, ...".

But maybe I am just ignorant and this is already quite simple (and there are 
no special "netdev" rules) - I am just not aware of it. In this case, please 
point me in the right direction, just to avoid reproducing wrong 
recommendations to other people.

Regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH batadv 0/8] batman-adv: follow up fixes

[Yuan Tan]

On Tue, May 5, 2026 at 12:20 AM Sven Eckelmann <sven@narfation.org> wrote:
>
> On Tuesday, 5 May 2026 07:21:13 CEST Matthieu Baerts wrote:
> [...]
> > >>> Are you CCing netdev to get this reviewed by Sashiko?
> > >>> Please don't..
> > >>> We delegate code to sub-sub-systems to lower the patch volume :(
> > >>>
> > >>
> > >> Because of `b4 prep --auto-to-cc`. Will now manually remove you.
> > >
> > > To speed up the discussion: @Konstantin, is there a way in b4 to say "stop at
> > > the sub-sub-systems" when doing `b4 prep --auto-to-cc`? I am just trying to get the
> > > `b4` workflow somehow working with the netdev requirements.
> >
> > Maybe a new option could be added, but that seems difficult to guess
> > where to stop, and to which subsystems to apply this.
> >
> > Can you not simply omit using `b4 prep --auto-to-cc` when working
> > with "internal" patches?
>
> Yes, no, maybe :)
> I will for the moment ignore the .b4-config part and talk about it at the end
> of the mail.
>
> b4 is trying to (afaik) to have a good common work flow for kernel related
> projects (and more). Independent of my role (if I am the maintainer or just
> another contributor), it will nag before a send: "Hey, please run
> --auto-to-cc, --check, --check-deps before you submit this patch(set) - you
> know how embarrassing it is when you notice some obvious problem 2 seconds
> after the SMTP server accepted your mail."
>
> And I agree with this and also try to convince people to try b4 because I
> think it is really helpful. Or at least ask them to use
> `./scripts/get_maintainer.pl` and NOT send patches with the prefix "net" or
> "net-next" when it actually targets our tree. But as it turns out, these
> recommendation seem to have been wrong and I am sorry about this.
>
> And I know, b4 is a good tool but adding a bazillion options just for every
> special case doesn't make a lot of sense and might make it a worse tool. I was
> therefore more thinking about `scripts/get_maintainer.pl`  (see `b4.send-auto-
> cc-cmd`) which also called by b4 with various options to avoid adding too many
> people.
>
> I don't say that any of these tools need to change. I am guessing more that I
> have to adjust something (MAINTAINERS, ...) to avoid that people are sending
> batman-adv sub-sub-system patches directly to netdev. I am just not aware of
> what this should be. But it sounds to me like there is at least a need for it
> (from the netdev maintainers perspective).
>
> > On my side, that's what I'm doing. I added a .b4-config file with this
> > content, not to have to specify --set-prefix nor --to:
>
> Regarding the .b4-config - yes, this is helpful and I should add it to
> batctl.git. I was more thinking about the normal contributor to
> net/batman-adv/. Regardless of this person taking as base net/net-next.git or
> our repo.
>
> The fixes from Ren Wei (and associates) and some other people were sent with
> "net" in the prefix, were Cc'ing netdev and didn't seem to use our tree as
> base. This is of course not correct and they should have targeted our tree
> instead. I didn't complain because the fix was otherwise extremely helpful and
> I though that there was no harm done. As it looks now, I should have and I am
> sorry for not communicating this.
>
> And I am at the moment not sure how to fix this without overloading
> contributers with "when you are contributing to some sub-subsystem of netdev
> ..., but when you are contributing to ext4, other rules apply .... don't
> forget about i2c rules for patch submission, ...".
>
> But maybe I am just ignorant and this is already quite simple (and there are
> no special "netdev" rules) - I am just not aware of it. In this case, please
> point me in the right direction, just to avoid reproducing wrong
> recommendations to other people.
>
> Regards,
>         Sven

Hi Sven,

I apologize for the inconvenience this caused. This was my oversight;
I’m embarrassed to admit that I was unaware that batman-adv used its
own maintenance tree and had instructed my team to follow the standard
netdev process.

It is our responsibility as contributors to carefully follow rules. I
will update our internal guides immediately to ensure our future
patches adhere to the correct workflow.

Best,
Yuan