__xfrm_state_delete
> > - bond_ipsec_del_sa()
> > - .xdo_dev_state_delete()
> > - bond_ipsec_free_sa()
> > - .xdo_dev_state_free()
>
On Tue, Mar 11, 2025 at 09:08:49PM +, Cosmin Ratiu wrote:
> On Fri, 2025-03-07 at 09:03 -0800, Jakub Kicinski wrote:
> > On Fri, 7 Mar 2025 09:42:49 +0200 Nikolay Aleksandrov wrote:
> > > TBH, keeping buggy code with a comment doesn't sound good to me.
> > > I'd rather remove this
> > > support
On Fri, 2025-03-07 at 09:03 -0800, Jakub Kicinski wrote:
> On Fri, 7 Mar 2025 09:42:49 +0200 Nikolay Aleksandrov wrote:
> > TBH, keeping buggy code with a comment doesn't sound good to me.
> > I'd rather remove this
> > support than tell people "good luck, it might crash". It's better
> > to be saf
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni :
On Thu, 6 Mar 2025 02:39:21 + you wrote:
> The mac address on backup slave should be convert from Solicited-Node
> Multicast address, not from bonding unicast target address.
>
> v4: no change, just repost
On Thu, Mar 06, 2025 at 02:39:23AM +, Hangbin Liu wrote:
> The correct mac address for NS target 2001:db8::254 is 33:33:ff:00:02:54,
> not 33:33:00:00:02:54. The same with client maddress.
>
> Fixes: 86fb6173d11e ("selftests: bonding: add ns multicast group testing")
&g
to the slave. However, the target in bonding is a unicast address, which
> we cannot use directly. Instead, we should first convert it to a
> Solicited-Node Multicast Address and then derive the corresponding MAC
> address.
>
> Fix the incorrect MAC address setting on bo
On Fri, Mar 07, 2025 at 09:03:32AM -0800, Jakub Kicinski wrote:
> On Fri, 7 Mar 2025 09:42:49 +0200 Nikolay Aleksandrov wrote:
> > TBH, keeping buggy code with a comment doesn't sound good to me. I'd rather
> > remove this
> > support than tell people "good luck, it might crash". It's better to be
On Sat, Mar 08, 2025 at 08:54:51AM +, Simon Horman wrote:
> On Fri, Mar 07, 2025 at 03:19:01AM +, Hangbin Liu wrote:
>
> ...
>
> > @@ -616,9 +615,22 @@ static void bond_ipsec_del_sa_all(struct bonding *bond)
> > return;
> >
> &
On Fri, Mar 07, 2025 at 03:19:01AM +, Hangbin Liu wrote:
...
> @@ -616,9 +615,22 @@ static void bond_ipsec_del_sa_all(struct bonding *bond)
> return;
>
> mutex_lock(&bond->ipsec_lock);
> - list_for_each_entry(ipsec, &bond->ipsec_lis
On Fri, 7 Mar 2025 09:42:49 +0200 Nikolay Aleksandrov wrote:
> TBH, keeping buggy code with a comment doesn't sound good to me. I'd rather
> remove this
> support than tell people "good luck, it might crash". It's better to be safe
> until a
> correct design is in place which takes care of these
>>> like
> >>>
> >>> ipsec->xs->xso.real_dev = real_dev;
> >>> __xfrm_state_delete
> >>> - bond_ipsec_del_sa()
> >>>
- bond_ipsec_free_sa()
- .xdo_dev_state_free()
.xdo_dev_state_add()
But there is no good solution yet. So I just added a FIXME note in here
and hope we can fix it in future.
Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to mutex")
Reported-by:
>>> like
>>>
>>> ipsec->xs->xso.real_dev = real_dev;
>>> __xfrm_state_delete
>>> - bond_ipsec_del_sa()
>>> - .xdo_dev_state_delete()
free()
> .xdo_dev_state_add()
>
> But there is no good solution yet. So I just added a FIXME note in here
> and hope we can fix it in future.
>
> Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to mutex")
> Reported-by: Jakub Kicinski
> Cl
On Wed, Mar 05, 2025 at 04:12:18PM +, Cosmin Ratiu wrote:
> +++ b/drivers/net/bonding/bond_main.c
> @@ -613,8 +613,11 @@ static void bond_ipsec_del_sa_all(struct bonding
> *bond)
>
> mutex_lock(&bond->ipsec_lock);
> list_for_each_entry(ipsec
This introduces a test for IPSec offload over bonding, utilizing netdevsim
for the testing process, as veth interfaces do not support IPSec offload.
The test will ensure that the IPSec offload functionality remains operational
even after a failover event occurs in the bonding configuration.
Here
The active-backup bonding mode supports XFRM ESP offload. However, when
a bond is added using command like `ip link add bond0 type bond mode 1
miimon 100`, the `ethtool -k` command shows that the XFRM ESP offload is
disabled. This occurs because, in bond_newlink(), we change bond link
first and
On Thu, Mar 06, 2025 at 01:37:15PM +, Cosmin Ratiu wrote:
> On Thu, 2025-03-06 at 10:02 +, Hangbin Liu wrote:
> > > For bond_ipsec_add_sa_all(), I will move the xso.real_dev =
> > > real_dev
> > > after .xdo_dev_state_add() in case the following situation.
>
> xso.real_dev needs to be init
nd_ipsec_add_sa_all(). e.g.
>
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 04b677d0c45b..3ada51c63207 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -537,15 +537,27 @@ static void bond
On Thu, 2025-03-06 at 10:02 +, Hangbin Liu wrote:
> > For bond_ipsec_add_sa_all(), I will move the xso.real_dev =
> > real_dev
> > after .xdo_dev_state_add() in case the following situation.
xso.real_dev needs to be initialized before the call to
xdo_dev_state_add, since many of the implementa
On Wed, Mar 05, 2025 at 04:12:18PM +, Cosmin Ratiu wrote:
> On Wed, 2025-03-05 at 14:13 +, Hangbin Liu wrote:
> > On Wed, Mar 05, 2025 at 10:38:36AM +0200, Nikolay Aleksandrov wrote:
> > > > @@ -617,8 +614,18 @@ static void bond_ipsec_del_sa_all(struct
real_dev to NULL? I checked,
> > real_dev is not used anywhere on the free calls, I think. I have
> > another series refactoring things around real_dev, I hope to be able to
> > send it soon.
> >
> > Here's a sketch of this idea:
> >
When validation on the backup slave is enabled, we need to validate the
Neighbor Solicitation (NS) messages received on the backup slave. To
receive these messages, the correct destination MAC address must be added
to the slave. However, the target in bonding is a unicast address, which
we cannot
The correct mac address for NS target 2001:db8::254 is 33:33:ff:00:02:54,
not 33:33:00:00:02:54. The same with client maddress.
Fixes: 86fb6173d11e ("selftests: bonding: add ns multicast group testing")
Acked-by: Jay Vosburgh
Reviewed-by: Nikolay Aleksandrov
Signed-off-by: H
The mac address on backup slave should be convert from Solicited-Node
Multicast address, not from bonding unicast target address.
v4: no change, just repost.
v3: also fix the mac setting for slave_set_ns_maddr. (Jay)
Add function description for slave_set_ns_maddr/slave_set_ns_maddrs (Jay)
v2
On Wed, 5 Mar 2025 08:25:07 + Hangbin Liu wrote:
> Could you help process it, or should I re-post it?
Repost.
On Wed, 2025-03-05 at 14:13 +, Hangbin Liu wrote:
> On Wed, Mar 05, 2025 at 10:38:36AM +0200, Nikolay Aleksandrov wrote:
> > > @@ -617,8 +614,18 @@ static void bond_ipsec_del_sa_all(struct
> > > bonding *bond)
> > >
> > > mutex_lock(&bond->
On Wed, Mar 05, 2025 at 10:38:36AM +0200, Nikolay Aleksandrov wrote:
> > @@ -617,8 +614,18 @@ static void bond_ipsec_del_sa_all(struct bonding *bond)
> >
> > mutex_lock(&bond->ipsec_lock);
> > list_for_each_entry(ipsec, &bond->ipsec_list, lis
Hangbin Liu writes:
> This introduces a test for IPSec offload over bonding, utilizing netdevsim
> for the testing process, as veth interfaces do not support IPSec offload.
> The test will ensure that the IPSec offload functionality remains operational
> even after a failover eve
rom bond->ipsec list.
>
> At the same time, protect bond_ipsec_del_sa_all and bond_ipsec_add_sa_all
> with x->lock for each xs being processed. This prevents XFRM from
> concurrently initiating add/delete operations on the managed states.
>
> Fixes: 2aeeef906d5a ("bonding: change i
ess on backup slave should be convert from Solicited-Node
> Multicast address, not from bonding unicast target address.
>
> v3: also fix the mac setting for slave_set_ns_maddr. (Jay)
> Add function description for slave_set_ns_maddr/slave_set_ns_maddrs (Jay)
> v2: fix patch 01&#
The active-backup bonding mode supports XFRM ESP offload. However, when
a bond is added using command like `ip link add bond0 type bond mode 1
miimon 100`, the `ethtool -k` command shows that the XFRM ESP offload is
disabled. This occurs because, in bond_newlink(), we change bond link
first and
This introduces a test for IPSec offload over bonding, utilizing netdevsim
for the testing process, as veth interfaces do not support IPSec offload.
The test will ensure that the IPSec offload functionality remains operational
even after a failover event occurs in the bonding configuration.
Here
concurrently initiating add/delete operations on the managed states.
Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to mutex")
Reported-by: Jakub Kicinski
Closes: https://lore.kernel.org/netdev/20241212062734.182a0...@kernel.org
Suggested-by: Cosmin Ratiu
Signed-off-by: Hangbin
On Tue, 2025-03-04 at 09:18 +, Hangbin Liu wrote:
>
> Just to make sure I added the lock in correct place, would you please
> help
> confirm.
>
> diff --git a/drivers/net/bonding/bond_main.c
> b/drivers/net/bonding/bond_main.c
> index e85878b12376..c59ad3a5cf43 10
del_sa_all
> is called in parallel, doesn't call delete on xs (because it's dead),
> then calls free (incorrect without delete first), then removes the list
> entry. Later, xdo_dev_state_delete( == bond_ipsec_del_sa) is called,
> and calls delete (incorrect, out of order with
Hi Cosmin,
On Fri, Feb 28, 2025 at 10:31:58AM +, Cosmin Ratiu wrote:
> On Fri, 2025-02-28 at 02:20 +, Hangbin Liu wrote:
> > On Thu, Feb 27, 2025 at 03:31:01PM +0200, Nikolay Aleksandrov wrote:
> > > > > One more thing - note I'm not an xfrm expert by far but it
> > > > > seems to me here y
On 2/28/25 13:07, Nikolay Aleksandrov wrote:
> On 2/28/25 12:31, Cosmin Ratiu wrote:
>> On Fri, 2025-02-28 at 02:20 +, Hangbin Liu wrote:
>>> On Thu, Feb 27, 2025 at 03:31:01PM +0200, Nikolay Aleksandrov wrote:
>> One more thing - note I'm not an xfrm expert by far but it
>> seems to me
On 2/28/25 12:31, Cosmin Ratiu wrote:
> On Fri, 2025-02-28 at 02:20 +, Hangbin Liu wrote:
>> On Thu, Feb 27, 2025 at 03:31:01PM +0200, Nikolay Aleksandrov wrote:
> One more thing - note I'm not an xfrm expert by far but it
> seems to me here you have
> to also call xdo_dev_state_fr
On Fri, 2025-02-28 at 02:20 +, Hangbin Liu wrote:
> On Thu, Feb 27, 2025 at 03:31:01PM +0200, Nikolay Aleksandrov wrote:
> > > > One more thing - note I'm not an xfrm expert by far but it
> > > > seems to me here you have
> > > > to also call xdo_dev_state_free() with the old active slave
> >
x27;m a bit lot here.
> >
> > Thanks
> > Hangbin
>
> Well, the race is between the xfrm GC and del_sa_all, in bond's free_sa if you
> walk the list under the mutex before calling real_dev's free callback and
> don't find the current element that's bein
Hangbin Liu writes:
> This introduces a test for IPSec offload over bonding, utilizing netdevsim
> for the testing process, as veth interfaces do not support IPSec offload.
> The test will ensure that the IPSec offload functionality remains operational
> even after a failover eve
On 2/27/25 15:21, Hangbin Liu wrote:
> On Thu, Feb 27, 2025 at 11:21:51AM +0200, Nikolay Aleksandrov wrote:
>>>> @@ -617,6 +611,12 @@ static void bond_ipsec_del_sa_all(struct bonding
>>>> *bond)
>>>>
>>>>mutex_lock(&bond->ipsec_l
On Thu, Feb 27, 2025 at 11:21:51AM +0200, Nikolay Aleksandrov wrote:
> >> @@ -617,6 +611,12 @@ static void bond_ipsec_del_sa_all(struct bonding
> >> *bond)
> >>
> >>mutex_lock(&bond->ipsec_lock);
> >>list_for_each_entry(ipsec, &
).
>>
>> In all three cases, xdo_dev_state_free() should not be called, only xs
>> should be removed from bond->ipsec list.
>>
>> Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to mutex")
>> Reported-by: Jakub Kicinski
&g
ged to a new device. At the same time, the xs is marked as DEAD
> due to the XFRM entry is removed, triggering xfrm_state_gc_task() and
> bond_ipsec_free_sa().
>
> In all three cases, xdo_dev_state_free() should not be called, only xs
> should be removed from bond->ip
This introduces a test for IPSec offload over bonding, utilizing netdevsim
for the testing process, as veth interfaces do not support IPSec offload.
The test will ensure that the IPSec offload functionality remains operational
even after a failover event occurs in the bonding configuration
The active-backup bonding mode supports XFRM ESP offload. However, when
a bond is added using command like `ip link add bond0 type bond mode 1
miimon 100`, the `ethtool -k` command shows that the XFRM ESP offload is
disabled. This occurs because, in bond_newlink(), we change bond link
first and
() and
bond_ipsec_free_sa().
In all three cases, xdo_dev_state_free() should not be called, only xs
should be removed from bond->ipsec list.
Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to mutex")
Reported-by: Jakub Kicinski
Closes: https://lor
On Wed, 2025-02-26 at 12:07 +, Hangbin Liu wrote:
>
> During bonding testing, we also found a case that would trigger
> the WARN_ON(xs->xso.real_dev != real_dev).
>
> If we create active-backup mode bonding and create ipsec tunnel over
> bonding device, then remove bondi
anks for proposing it. Maybe you should
> package it in a new submission with a proper title/etc.?
> I'll do the initial review here.
This is a draft patch and I think there may have something need to be fixed.
So I just paste it here :)
>
> >
> > diff --git a/driv
M_STATE_DEAD
> > in bond_ipsec_del_sa_all.
> >
> > What do you think about this idea?
>
> Thanks a lot for the comments. I also skipped the DEAD xs in
> add_sa_all.
> What about the patch like:
This is what I had in mind, thanks for proposing it. Maybe you should
pa
in add_sa_all.
What about the patch like:
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index e45bba240cbc..0e4db43a833a 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -537,6 +537,12 @@ static void bond_ipsec_add_sa_all(str
t;
>> Fix this by moving the mutex_lock() operation to a work queue.
>>
>> Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to
>> mutex")
>> Reported-by: Jakub Kicinski
>> Closes:
>> https://lore.kernel.org/netdev/20241212062734.18
ork queue.
>
> Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to
> mutex")
> Reported-by: Jakub Kicinski
> Closes:
> https://lore.kernel.org/netdev/20241212062734.182a0...@kernel.org
> Signed-off-by: Hangbin Liu
> ---
> drivers/net/bonding/bond_m
On 2/25/25 15:13, Hangbin Liu wrote:
> On Tue, Feb 25, 2025 at 01:05:24PM +0200, Nikolay Aleksandrov wrote:
>>> @@ -592,15 +611,17 @@ static void bond_ipsec_del_sa(struct xfrm_state *xs)
>>> real_dev->xfrmdev_ops->xdo_dev_state_delete(xs);
>>> out:
>>> netdev_put(real_dev, &tracker);
>>> -
On Tue, Feb 25, 2025 at 01:05:24PM +0200, Nikolay Aleksandrov wrote:
> > @@ -592,15 +611,17 @@ static void bond_ipsec_del_sa(struct xfrm_state *xs)
> > real_dev->xfrmdev_ops->xdo_dev_state_delete(xs);
> > out:
> > netdev_put(real_dev, &tracker);
> > - mutex_lock(&bond->ipsec_lock);
> > -
On 2/25/25 11:40, Hangbin Liu wrote:
> The fixed commit placed mutex_lock() inside spin_lock_bh(), which triggers
> a warning like:
>
> BUG: sleeping function called from invalid context at...
>
> Fix this by moving the mutex_lock() operation to a work queue.
>
> Fixes
This introduces a test for IPSec offload over bonding, utilizing netdevsim
for the testing process, as veth interfaces do not support IPSec offload.
The test will ensure that the IPSec offload functionality remains operational
even after a failover event occurs in the bonding configuration
The active-backup bonding mode supports XFRM ESP offload. However, when
a bond is added using command like `ip link add bond0 type bond mode 1
miimon 100`, the `ethtool -k` command shows that the XFRM ESP offload is
disabled. This occurs because, in bond_newlink(), we change bond link
first and
The fixed commit placed mutex_lock() inside spin_lock_bh(), which triggers
a warning like:
BUG: sleeping function called from invalid context at...
Fix this by moving the mutex_lock() operation to a work queue.
Fixes: 2aeeef906d5a ("bonding: change ipsec_lock from spin lock to mutex"
On 2/7/25 11:29, Hangbin Liu wrote:
> The mac address on backup slave should be convert from Solicited-Node
> Multicast address, not from bonding unicast target address.
>
> v3: also fix the mac setting for slave_set_ns_maddr. (Jay)
> Add function description for sla
Hangbin Liu wrote:
>The mac address on backup slave should be convert from Solicited-Node
>Multicast address, not from bonding unicast target address.
>
>v3: also fix the mac setting for slave_set_ns_maddr. (Jay)
>Add function description for slave_set_ns_maddr/slave_set_ns_m
Hi Jay,
Any comments?
Thanks
Hangbin
On Tue, Feb 11, 2025 at 07:31:32AM +, Hangbin Liu wrote:
> Hi Jay,
> On Sat, Feb 08, 2025 at 06:34:21AM +, Hangbin Liu wrote:
> > Please hold on this patch. Our QE reported that with bare NIC, the
> > backup NIC can't receive the NS messages even after
Hi Jay,
On Sat, Feb 08, 2025 at 06:34:21AM +, Hangbin Liu wrote:
> Please hold on this patch. Our QE reported that with bare NIC, the
> backup NIC can't receive the NS messages even after joining the multicast
> MAC group. But after remove the backup NIC from bond, the NIC interface
> could rec
olicited-Node
> Multicast address, not from bonding unicast target address.
>
> v3: also fix the mac setting for slave_set_ns_maddr. (Jay)
> Add function description for slave_set_ns_maddr/slave_set_ns_maddrs (Jay)
> v2: fix patch 01's subject
>
> Hangbin Liu (2):
> bon
The correct mac address for NS target 2001:db8::254 is 33:33:ff:00:02:54,
not 33:33:00:00:02:54. The same with client maddress.
Fixes: 86fb6173d11e ("selftests: bonding: add ns multicast group testing")
Signed-off-by: Hangbin Liu
---
tools/testing/selftests/drivers/net/bonding/bond_
When validation on the backup slave is enabled, we need to validate the
Neighbor Solicitation (NS) messages received on the backup slave. To
receive these messages, the correct destination MAC address must be added
to the slave. However, the target in bonding is a unicast address, which
we cannot
The mac address on backup slave should be convert from Solicited-Node
Multicast address, not from bonding unicast target address.
v3: also fix the mac setting for slave_set_ns_maddr. (Jay)
Add function description for slave_set_ns_maddr/slave_set_ns_maddrs (Jay)
v2: fix patch 01's su
On Thu, Feb 06, 2025 at 05:19:34PM -0800, Jay Vosburgh wrote:
> I think this now deserves some commentary in the code. Not
> because this function itself is unclear, but because there's the
> similarly-named slave_set_ns_maddr() (singular, not plural as in this
> patch) that will behave in a
Hangbin Liu wrote:
>When validation on the backup slave is enabled, we need to validate the
>Neighbor Solicitation (NS) messages received on the backup slave. To
>receive these messages, the correct destination MAC address must be added
>to the slave. However, the target in bonding
The correct mac address for NS target 2001:db8::254 is 33:33:ff:00:02:54,
not 33:33:00:00:02:54. The same with client maddress.
Fixes: 86fb6173d11e ("selftests: bonding: add ns multicast group testing")
Signed-off-by: Hangbin Liu
---
tools/testing/selftests/drivers/net/bonding/bond_
When validation on the backup slave is enabled, we need to validate the
Neighbor Solicitation (NS) messages received on the backup slave. To
receive these messages, the correct destination MAC address must be added
to the slave. However, the target in bonding is a unicast address, which
we cannot
The mac address on backup slave should be convert from Solicited-Node
Multicast address, not from bonding unicast target address.
v2: fix patch 01's subject
Hangbin Liu (2):
bonding: fix incorrect MAC address setting to receive NS messages
selftests: bonding: fix incorrect mac ad
the NS target's corresponding MAC address. But the target in
> bonding is a unicast addresses. We can't use it directly. Instead, we should
> convert it to a Solicited-Node Multicast Address first and then convert
> the multicast address to the right MAC address.
>
> Fixes: 8eb361
The correct mac address for NS target 2001:db8::254 is 33:33:ff:00:02:54,
not 33:33:00:00:02:54. The same with client maddress.
Fixes: 86fb6173d11e ("selftests: bonding: add ns multicast group testing")
Signed-off-by: Hangbin Liu
---
tools/testing/selftests/drivers/net/bonding/bond_
In order to receive the neighbor solicitation messages on the backup slave,
we should add the NS target's corresponding MAC address. But the target in
bonding is a unicast addresses. We can't use it directly. Instead, we should
convert it to a Solicited-Node Multicast Address firs
The mac address on backup slave should be convert from Solicited-Node
Multicast address, not from bonding unicast target address.
Hangbin Liu (2):
bonding: fix incorrect MAC address setting to receive NA messages
selftests: bonding: fix incorrect mac address
drivers/net/bonding
On Fri, 24 Jan 2025 16:03:32 + Cosmin Ratiu wrote:
> On Fri, 2025-01-24 at 07:38 -0800, Jakub Kicinski wrote:
> > On Thu, 23 Jan 2025 15:24:37 + Cosmin Ratiu wrote:
> > > I've sent another patch to suggest these changes.
> >
> > FTR this is not the normal way to proceed in code review,
On Fri, 2025-01-24 at 07:38 -0800, Jakub Kicinski wrote:
> On Thu, 23 Jan 2025 15:24:37 + Cosmin Ratiu wrote:
> > I've sent another patch to suggest these changes.
>
> FTR this is not the normal way to proceed in code review,
> please try to share your feedback rather than taking over
> the su
On Thu, 23 Jan 2025 15:24:37 + Cosmin Ratiu wrote:
> I've sent another patch to suggest these changes.
FTR this is not the normal way to proceed in code review,
please try to share your feedback rather than taking over
the submission (unless the original author explicitly asks
you to).
I've sent another patch to suggest these changes.
I've tested it (with iperf3 traffic) and by playing with ethtool -K on
the bond device. With simple iperf3 TCP traffic and no other tweaks, I
get 2x the performance over the bond device with my patch compared to
without.
I hope I didn't miss anythi
On Wed, 2025-01-22 at 13:52 +, Hangbin Liu wrote:
> The fixed commit adds NETIF_F_GSO_ESP bit for bonding
> gso_partial_features.
> However, if we don't set the dev NETIF_F_GSO_PARTIAL bit, the later
> netdev_change_features() -> netdev_fix_features() will remove the
> N
The fixed commit adds NETIF_F_GSO_ESP bit for bonding gso_partial_features.
However, if we don't set the dev NETIF_F_GSO_PARTIAL bit, the later
netdev_change_features() -> netdev_fix_features() will remove the
NETIF_F_GSO_ESP bit from the dev features. This causes ethtool to show
that
On Tue, Jan 21, 2025 at 08:55:25AM +, Hangbin Liu wrote:
> The fixed commit adds NETIF_F_GSO_ESP bit for bonding gso_partial_features.
> However, if we don't set the dev NETIF_F_GSO_PARTIAL bit, the later
> netdev_change_features() -> netdev_fix_features() will remove the
>
The fixed commit adds NETIF_F_GSO_ESP bit for bonding gso_partial_features.
However, if we don't set the dev NETIF_F_GSO_PARTIAL bit, the later
netdev_change_features() -> netdev_fix_features() will remove the
NETIF_F_GSO_ESP bit from the dev features. This causes ethtool to show
that
On Thu, Dec 12, 2024 at 11:43:15AM +0200, Nikolay Aleksandrov wrote:
> >>> --- a/drivers/net/bonding/bond_netlink.c
> >>> +++ b/drivers/net/bonding/bond_netlink.c
> >>> @@ -568,18 +568,21 @@ static int bond_newlink(struct net *src_net
On 12/12/24 11:39, Hangbin Liu wrote:
> On Thu, Dec 12, 2024 at 11:19:33AM +0200, Nikolay Aleksandrov wrote:
>>> diff --git a/drivers/net/bonding/bond_main.c
>>> b/drivers/net/bonding/bond_main.c
>>> index 49dd4fe195e5..7daeab67e7b5 100644
>>> --- a/dr
On Thu, Dec 12, 2024 at 11:19:33AM +0200, Nikolay Aleksandrov wrote:
> > diff --git a/drivers/net/bonding/bond_main.c
> > b/drivers/net/bonding/bond_main.c
> > index 49dd4fe195e5..7daeab67e7b5 100644
> > --- a/drivers/net/bonding/bond_main.c
> > +++ b/d
On 12/11/24 09:11, Hangbin Liu wrote:
> The active-backup bonding mode supports XFRM ESP offload. However, when
> a bond is added using command like `ip link add bond0 type bond mode 1
> miimon 100`, the `ethtool -k` command shows that the XFRM ESP offload is
> disabled. This occurs
The active-backup bonding mode supports XFRM ESP offload. However, when
a bond is added using command like `ip link add bond0 type bond mode 1
miimon 100`, the `ethtool -k` command shows that the XFRM ESP offload is
disabled. This occurs because, in bond_newlink(), we change bond link
first and
This introduces a test for IPSec offload over bonding, utilizing netdevsim
for the testing process, as veth interfaces do not support IPSec offload.
The test will ensure that the IPSec offload functionality remains operational
even after a failover event occurs in the bonding configuration
user space, so I think it's
safe to leave those calls not holding the mode_lock. The race is still
there, but the data returned to user space is a snapshot and so may
reflect an incomplete state during a transition. Further, having the
inspection functions acquire the mode_lock permits user spac
ve arr.
Signed-off-by: jin yiting
---
drivers/net/bonding/bond_3ad.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index 6908822..d100079 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
in
>ad_agg_selection_logic has not changed, no need to update slave arr.
>
>Signed-off-by: jin yiting
>---
> drivers/net/bonding/bond_3ad.c | 6 ++
> 1 file changed, 6 insertions(+)
>
>diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
>index
will be cleared. Before the new active aggregator is
selected on CPU B, bond_3ad_get_active_agg_info failed on CPU A,
bond->slave_arr will be set to NULL. The best aggregator in
ad_agg_selection_logic has not changed, no need to update slave arr.
Signed-off-by: jin yiting
---
drivers/net/bon
On Thu, 15 Apr 2021 14:59:49 +0800 jin yiting wrote:
> From 71e63af579edd15ad7f7395760a19f67d9a1d7d3 Mon Sep 17 00:00:00 2001
> From: jin yiting
> Date: Wed, 31 Mar 2021 20:38:40 +0800
> Subject: [PATCH] bonding: 3ad: update slave arr after initialize
> MIME-Version: 1.0
>
From 71e63af579edd15ad7f7395760a19f67d9a1d7d3 Mon Sep 17 00:00:00 2001
From: jin yiting
Date: Wed, 31 Mar 2021 20:38:40 +0800
Subject: [PATCH] bonding: 3ad: update slave arr after initialize
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The bond works
d-off-by: Greg Kroah-Hartman
---
drivers/net/bonding/bond_main.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3917,15 +3917,11 @@ static int bond_neigh_init(struct neighb
rcu_read
From: Jia-Ju Bai
[ Upstream commit 2055a99da8a253a357bdfd359b3338ef3375a26c ]
When slave is NULL or slave_ops->ndo_neigh_setup is NULL, no error
return code of bond_neigh_init() is assigned.
To fix this bug, ret is assigned with -EINVAL in these cases.
Fixes: 9e99bfefdbce ("bond
1 - 100 of 1096 matches
Mail list logo
