On Thu, Jul 24, 2025 at 11:57:53AM +0200, Jay Vosburgh wrote:
> FWIW, I usually reference the older standards 2008 or 2014, as
> the 2020 edition changes a lot of things and bonding isn't necessarily
> conformant to those changes (e.g., many of the state machines are
> different in large or s
Hangbin Liu wrote:
>On Tue, Jul 15, 2025 at 09:19:49PM -0700, Jay Vosburgh wrote:
>> Presuming that I'm correct that we're not implementing 6.4.1 d),
>> above, correctly, then I don't think this is a proper fix, as it kind of
>> band-aids over the problem a bit.
>>
>> Looking at the co
On Tue, Jul 15, 2025 at 09:19:49PM -0700, Jay Vosburgh wrote:
> Presuming that I'm correct that we're not implementing 6.4.1 d),
> above, correctly, then I don't think this is a proper fix, as it kind of
> band-aids over the problem a bit.
>
> Looking at the code, I suspect the problem
On 07/22, Simon Horman wrote:
> On Mon, Jul 21, 2025 at 09:54:22AM -0700, Stanislav Fomichev wrote:
> > Cosmin reports the following locking issue:
> >
> > # BUG: sleeping function called from invalid context at
> > kernel/locking/mutex.c:275
> > # dump_stack_lvl+0x4f/0x60
> > # __migh
On Mon, Jul 21, 2025 at 09:54:22AM -0700, Stanislav Fomichev wrote:
> Cosmin reports the following locking issue:
>
> # BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:275
> # dump_stack_lvl+0x4f/0x60
> # __might_resched+0xeb/0x140
> # mutex_lock+0x1a
Cosmin reports the following locking issue:
# BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:275
# dump_stack_lvl+0x4f/0x60
# __might_resched+0xeb/0x140
# mutex_lock+0x1a/0x40
# dev_set_promiscuity+0x26/0x90
# __dev_set_promiscuity+0x85/0x170
Hangbin Liu wrote:
>On Tue, Jul 15, 2025 at 09:19:49PM -0700, Jay Vosburgh wrote:
>> Hangbin Liu wrote:
>>
>> >When lacp_active is set to off, the bond operates in passive mode, meaning
>> >it
>> >will only "speak when spoken to." However, the current kernel implementation
>> >only sends an LA
On Tue, Jul 15, 2025 at 09:19:49PM -0700, Jay Vosburgh wrote:
> Hangbin Liu wrote:
>
> >When lacp_active is set to off, the bond operates in passive mode, meaning it
> >will only "speak when spoken to." However, the current kernel implementation
> >only sends an LACPDU in response when the partne
Hangbin Liu wrote:
>When lacp_active is set to off, the bond operates in passive mode, meaning it
>will only "speak when spoken to." However, the current kernel implementation
>only sends an LACPDU in response when the partner's state changes.
>
>In this situation, once LACP negotiation succeeds,
The "mmap" and "sendfile" alternate modes for mptcp_connect.sh/.c are
available from the beginning, but only tested when mptcp_connect.sh is
manually launched with "-m mmap" or "-m sendfile", not via the
kselftests helpers.
The MPTCP CI was manually running "mptcp_connect.sh -m mmap", but not
"-m
When lacp_active is set to off, the bond operates in passive mode, meaning it
will only "speak when spoken to." However, the current kernel implementation
only sends an LACPDU in response when the partner's state changes.
In this situation, once LACP negotiation succeeds, the actor stops sending
L
On Thu, Jun 26, 2025 at 11:34 PM Bui Quang Minh
wrote:
>
> On 6/26/25 09:34, Jason Wang wrote:
> > On Thu, Jun 26, 2025 at 12:10 AM Bui Quang Minh
> > wrote:
> >> In xdp_linearize_page, when reading the following buffers from the ring,
> >> we forget to check the received length with the true all
On 6/26/25 09:34, Jason Wang wrote:
On Thu, Jun 26, 2025 at 12:10 AM Bui Quang Minh
wrote:
In xdp_linearize_page, when reading the following buffers from the ring,
we forget to check the received length with the true allocate size. This
can lead to an out-of-bound read. This commit adds that mi
On Thu, Jun 26, 2025 at 12:10 AM Bui Quang Minh
wrote:
>
> In xdp_linearize_page, when reading the following buffers from the ring,
> we forget to check the received length with the true allocate size. This
> can lead to an out-of-bound read. This commit adds that missing check.
>
> Fixes: 4941d47
In xdp_linearize_page, when reading the following buffers from the ring,
we forget to check the received length with the true allocate size. This
can lead to an out-of-bound read. This commit adds that missing check.
Fixes: 4941d472bf95 ("virtio-net: do not reset during XDP set")
Signed-off-by: Bu
On 6/20/25 16:43, Stefano Garzarella wrote:
> On Fri, 20 Jun 2025 at 16:23, Michal Luczaj wrote:
>>
>> On 6/20/25 15:20, Stefano Garzarella wrote:
>>> On Fri, Jun 20, 2025 at 02:58:49PM +0200, Michal Luczaj wrote:
On 6/20/25 10:32, Stefano Garzarella wrote:
> On Wed, Jun 18, 2025 at 02:34
On Fri, Jun 20, 2025 at 02:58:49PM +0200, Michal Luczaj wrote:
On 6/20/25 10:32, Stefano Garzarella wrote:
On Wed, Jun 18, 2025 at 02:34:00PM +0200, Michal Luczaj wrote:
Checking transport_{h2g,g2h} != NULL may race with vsock_core_unregister().
Make sure pointers remain valid.
KASAN: null-ptr
On Fri, 20 Jun 2025 at 16:23, Michal Luczaj wrote:
>
> On 6/20/25 15:20, Stefano Garzarella wrote:
> > On Fri, Jun 20, 2025 at 02:58:49PM +0200, Michal Luczaj wrote:
> >> On 6/20/25 10:32, Stefano Garzarella wrote:
> >>> On Wed, Jun 18, 2025 at 02:34:00PM +0200, Michal Luczaj wrote:
> Checkin
On 6/20/25 15:20, Stefano Garzarella wrote:
> On Fri, Jun 20, 2025 at 02:58:49PM +0200, Michal Luczaj wrote:
>> On 6/20/25 10:32, Stefano Garzarella wrote:
>>> On Wed, Jun 18, 2025 at 02:34:00PM +0200, Michal Luczaj wrote:
Checking transport_{h2g,g2h} != NULL may race with vsock_core_unregiste
On 6/20/25 10:32, Stefano Garzarella wrote:
> On Wed, Jun 18, 2025 at 02:34:00PM +0200, Michal Luczaj wrote:
>> Checking transport_{h2g,g2h} != NULL may race with vsock_core_unregister().
>> Make sure pointers remain valid.
>>
>> KASAN: null-ptr-deref in range [0x0118-0x011f
On Wed, Jun 18, 2025 at 02:34:00PM +0200, Michal Luczaj wrote:
Checking transport_{h2g,g2h} != NULL may race with vsock_core_unregister().
Make sure pointers remain valid.
KASAN: null-ptr-deref in range [0x0118-0x011f]
RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0
Call Tr
On Thu, 19 Jun 2025 21:17:03 +0700 Bui Quang Minh wrote:
> > I think Michael mention he's AFK so while we wait could you fix this
> > kdoc? I'm not sure whether the kdoc is really necessary here, but if
> > you want to keep it you have to document the return value:
> >
> > Warning: drivers/net/virt
On 6/19/25 09:11, Jakub Kicinski wrote:
On Sun, 15 Jun 2025 22:13:32 +0700 Bui Quang Minh wrote:
+/**
+ * buf_to_xdp() - convert the @buf context to xdp_buff
+ * @vi: virtnet_info struct
+ * @rq: the receive queue struct
+ * @buf: the xdp_buff pointer that is passed to virtqueue_add_inbuf_premap
On Sun, 15 Jun 2025 22:13:32 +0700 Bui Quang Minh wrote:
> +/**
> + * buf_to_xdp() - convert the @buf context to xdp_buff
> + * @vi: virtnet_info struct
> + * @rq: the receive queue struct
> + * @buf: the xdp_buff pointer that is passed to
> virtqueue_add_inbuf_premapped in
> + * virtnet_add
Checking transport_{h2g,g2h} != NULL may race with vsock_core_unregister().
Make sure pointers remain valid.
KASAN: null-ptr-deref in range [0x0118-0x011f]
RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0
Call Trace:
__x64_sys_ioctl+0x12d/0x190
do_syscall_64+0x92/0x1c0
entr
When calling buf_to_xdp, the len argument is the frame data's length
without virtio header's length (vi->hdr_len). We check that len with
xsk_pool_get_rx_frame_size() + vi->hdr_len
to ensure the provided len does not larger than the allocated chunk
size. The additional vi->hdr_len is beca
Simplest setup to reproduce the issue: connect 2 ports of the
LS1028A-RDB together (eno0 with swp0) and run:
$ ip link set eno0 up && ip link set swp0 up
$ tc qdisc replace dev swp0 parent root handle 100 taprio num_tc 8 \
queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 map 0 1 2 3 4 5 6 7 \
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski :
On Fri, 25 Apr 2025 01:37:33 +0300 you wrote:
> The following set of commands:
>
> ip link add br0 type bridge vlan_filtering 1 # vlan_default_pvid 1 is implicit
> ip link set swp0 master br0
> bridge vlan add dev swp0 v
The following set of commands:
ip link add br0 type bridge vlan_filtering 1 # vlan_default_pvid 1 is implicit
ip link set swp0 master br0
bridge vlan add dev swp0 vid 1
should result in the dropping of untagged and 802.1p-tagged traffic, but
we see that it continues to be accepted. Whereas, had w
From: Mat Martineau
When path manager entries are deleted from the local address list, they
are first unlinked from the address list using list_del_rcu(). The
entries must not be freed until after the RCU grace period, but the
existing code immediately frees the entry.
Use kfree_rcu_mightsleep()
On Mon, Apr 07, 2025 at 08:26:32PM +0200, Matthieu Baerts (NGI0) wrote:
> Recently, during a debugging session using local MPTCP connections, I
> noticed MPJoinAckHMacFailure was not zero on the server side. The
> counter was in fact incremented when the PM rejected new subflows,
> because the 'sub
Recently, during a debugging session using local MPTCP connections, I
noticed MPJoinAckHMacFailure was not zero on the server side. The
counter was in fact incremented when the PM rejected new subflows,
because the 'subflow' limit was reached.
The fix is easy, simply dissociating the two cases: on
From: Gang Yan
When testing valkey benchmark tool with MPTCP, the kernel panics in
'mptcp_can_accept_new_subflow' because subflow_req->msk is NULL.
Call trace:
mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P)
subflow_syn_recv_sock (./net/mptcp/subflow.c:854)
t
From: Dmitry Safonov <0x7f454...@gmail.com>
Before:
># 13145[lib/ftrace-tcp.c:427] trace event filter tcp_ao_key_not_found
>[2001:db8:1::1:-1 => 2001:db8:254::1:7010, L3index 0, flags: !FS!R!P!., keyid:
>100, rnext: 100, maclen: -1, sne: -1] = 1
After:
># 13487[lib/ftrace-tcp.c:427] trace event
On Fri, Feb 14, 2025 at 02:11:48PM +0100, Michal Luczaj wrote:
...
Another design detail is that listening vsocks are not supposed to have any
transport assigned at all. Which implies they are not supported by the
sockmap. But this is complicated by the fact that a socket, before
switching to TCP
> ...
> Another design detail is that listening vsocks are not supposed to have any
> transport assigned at all. Which implies they are not supported by the
> sockmap. But this is complicated by the fact that a socket, before
> switching to TCP_LISTEN, may have had some transport assigned during a
On Thu, 13 Feb 2025 at 15:47, Stefano Garzarella wrote:
>I forgot to mention that IMHO it's better to split this series.
>This first patch (this one) seems ready, without controversy, and it's
>a real fix, so for me v3 should be a version ready to be merged.
>
>While the other patch is more contro
On Thu, 13 Feb 2025 at 10:25, Stefano Garzarella wrote:
>
> On Thu, Feb 13, 2025 at 09:28:05AM +0800, Junnan Wu wrote:
> >>You need to update the title now that you're moving also queued_replies.
> >>
> >
> >Well, I will update the title in V3 version.
> >
> >>On Tue, Feb 11, 2025 at 03:19:21PM +0
sockmap expects all vsocks to have a transport assigned, which is expressed
in vsock_proto::psock_update_sk_prot(). However, there is an edge case
where an unconnected (connectible) socket may lose its previously assigned
transport. This is handled with a NULL check in the vsock/BPF recv path.
Ano
On Thu, Feb 13, 2025 at 09:28:05AM +0800, Junnan Wu wrote:
You need to update the title now that you're moving also queued_replies.
Well, I will update the title in V3 version.
On Tue, Feb 11, 2025 at 03:19:21PM +0800, Junnan Wu wrote:
When executing suspend to ram twice in a row,
the `rx_b
>You need to update the title now that you're moving also queued_replies.
>
Well, I will update the title in V3 version.
>On Tue, Feb 11, 2025 at 03:19:21PM +0800, Junnan Wu wrote:
>>When executing suspend to ram twice in a row,
>>the `rx_buf_nr` and `rx_buf_max_nr` increase to three times vq->nu
You need to update the title now that you're moving also queued_replies.
On Tue, Feb 11, 2025 at 03:19:21PM +0800, Junnan Wu wrote:
When executing suspend to ram twice in a row,
the `rx_buf_nr` and `rx_buf_max_nr` increase to three times vq->num_free.
Then after virtqueue_get_buf and `rx_buf_n
When executing suspend to ram twice in a row,
the `rx_buf_nr` and `rx_buf_max_nr` increase to three times vq->num_free.
Then after virtqueue_get_buf and `rx_buf_nr` decreased
in function virtio_transport_rx_work,
the condition to fill rx buffer
(rx_buf_nr < rx_buf_max_nr / 2) will never be met.
It
Oh, I just found the subject is incorrect. We want to receive the NS
message, not NA message on backup slaves.
Thanks
Hangbin
On Wed, Feb 05, 2025 at 08:03:35AM +, Hangbin Liu wrote:
> In order to receive the neighbor solicitation messages on the backup slave,
> we should add the NS target's
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 first and then convert
On 1/21/25 18:30, Luigi Leonardi wrote:
> On Thu, Jan 09, 2025 at 02:34:28PM +0100, Michal Luczaj wrote:
>> FWIW, I've tried simplifying Hyunwoo's repro to toy with some tests.
>> Ended
>> up with
>>
>> ```
>>from threading import *
>>from socket import *
>>from signal import *
>>
>> def listener(
On Thu, Jan 09, 2025 at 02:34:28PM +0100, Michal Luczaj wrote:
FWIW, I've tried simplifying Hyunwoo's repro to toy with some tests.
Ended
up with
```
from threading import *
from socket import *
from signal import *
def listener(tid):
while True:
s = socket(AF_VSOCK, SO
From: Paolo Abeni
mptcp_cleanup_rbuf() is responsible to send acks when the user-space
reads enough data to update the receive windows significantly.
It tries hard to avoid acquiring the subflow sockets locks by checking
conditions similar to the ones implemented at the TCP level.
To avoid too
On Thu, Jan 09, 2025 at 02:34:28PM +0100, Michal Luczaj wrote:
On 1/8/25 19:06, Stefano Garzarella wrote:
If the socket has been de-assigned or assigned to another transport,
we must discard any packets received because they are not expected
and would cause issues when we access vsk->transport.
On 1/9/25 14:42, Stefano Garzarella wrote:
> On Thu, Jan 09, 2025 at 02:34:28PM +0100, Michal Luczaj wrote:
>> ...
>> That said, when I apply this patch, but drop the `sk->sk_state !=
>> TCP_LISTEN &&`: no more splats.
>
> We can't drop `sk->sk_state != TCP_LISTEN &&` because listener socket
> do
On Thu, Jan 09, 2025 at 02:34:28PM +0100, Michal Luczaj wrote:
On 1/8/25 19:06, Stefano Garzarella wrote:
If the socket has been de-assigned or assigned to another transport,
we must discard any packets received because they are not expected
and would cause issues when we access vsk->transport.
On 1/8/25 19:06, Stefano Garzarella wrote:
> If the socket has been de-assigned or assigned to another transport,
> we must discard any packets received because they are not expected
> and would cause issues when we access vsk->transport.
>
> A possible scenario is described by Hyunwoo Kim in the
On Thu, Jan 09, 2025 at 11:59:21AM +0100, Stefano Garzarella wrote:
> On Thu, Jan 09, 2025 at 04:13:44AM -0500, Hyunwoo Kim wrote:
> > On Thu, Jan 09, 2025 at 10:01:31AM +0100, Stefano Garzarella wrote:
> > > On Wed, Jan 08, 2025 at 02:31:19PM -0500, Hyunwoo Kim wrote:
> > > > On Wed, Jan 08, 2025
On Thu, Jan 09, 2025 at 04:13:44AM -0500, Hyunwoo Kim wrote:
On Thu, Jan 09, 2025 at 10:01:31AM +0100, Stefano Garzarella wrote:
On Wed, Jan 08, 2025 at 02:31:19PM -0500, Hyunwoo Kim wrote:
> On Wed, Jan 08, 2025 at 07:06:16PM +0100, Stefano Garzarella wrote:
> > If the socket has been de-assign
On Thu, Jan 09, 2025 at 10:01:31AM +0100, Stefano Garzarella wrote:
> On Wed, Jan 08, 2025 at 02:31:19PM -0500, Hyunwoo Kim wrote:
> > On Wed, Jan 08, 2025 at 07:06:16PM +0100, Stefano Garzarella wrote:
> > > If the socket has been de-assigned or assigned to another transport,
> > > we must discard
On Thu, Jan 09, 2025 at 10:01:31AM +0100, Stefano Garzarella wrote:
> On Wed, Jan 08, 2025 at 02:31:19PM -0500, Hyunwoo Kim wrote:
> > On Wed, Jan 08, 2025 at 07:06:16PM +0100, Stefano Garzarella wrote:
> > > If the socket has been de-assigned or assigned to another transport,
> > > we must discard
On Wed, Jan 08, 2025 at 02:31:19PM -0500, Hyunwoo Kim wrote:
On Wed, Jan 08, 2025 at 07:06:16PM +0100, Stefano Garzarella wrote:
If the socket has been de-assigned or assigned to another transport,
we must discard any packets received because they are not expected
and would cause issues when we
On Wed, Jan 08, 2025 at 07:06:16PM +0100, Stefano Garzarella wrote:
> If the socket has been de-assigned or assigned to another transport,
> we must discard any packets received because they are not expected
> and would cause issues when we access vsk->transport.
>
> A possible scenario is describ
If the socket has been de-assigned or assigned to another transport,
we must discard any packets received because they are not expected
and would cause issues when we access vsk->transport.
A possible scenario is described by Hyunwoo Kim in the attached link,
where after a first connect() interrup
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, struct
> >>> net_device *bond_dev,
> >>> str
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/drivers/net/bonding/bond_main.c
>>> +++ b/driver
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/drivers/net/bonding/bond_main.c
> > @@ -4389,7
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 because, in bon
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 reg
On Fri, Nov 15, 2024 at 12:46:27PM -0800, Sam Edwards wrote:
> Hi Hangbin,
>
> It took me a while to grasp but the problem seems to be a confusion
> about what it means to set a temporary's lifetimes to 0/0:
> 1) "The mngtmpaddrs has gone away; this temporary is slated for
> deletion by addrconf_v
On 11/15/24 1:46 PM, Sam Edwards wrote:
> Hi Hangbin,
>
> It took me a while to grasp but the problem seems to be a confusion
> about what it means to set a temporary's lifetimes to 0/0:
> 1) "The mngtmpaddrs has gone away; this temporary is slated for
> deletion by addrconf_verify_rtnl()"
> 2) "T
On Wed, Nov 13, 2024 at 11:38 PM Hangbin Liu wrote:
>
> On Wed, Nov 13, 2024 at 01:03:13PM -0800, Sam Edwards wrote:
> > On Wed, Nov 13, 2024 at 4:52 AM Hangbin Liu wrote:
> > >
> > > RFC8981 section 3.4 says that existing temporary addresses must have their
> > > lifetimes adjusted so that no te
On Wed, Nov 13, 2024 at 01:03:13PM -0800, Sam Edwards wrote:
> On Wed, Nov 13, 2024 at 4:52 AM Hangbin Liu wrote:
> >
> > RFC8981 section 3.4 says that existing temporary addresses must have their
> > lifetimes adjusted so that no temporary addresses should ever remain "valid"
> > or "preferred" l
On Wed, Nov 13, 2024 at 4:52 AM Hangbin Liu wrote:
>
> RFC8981 section 3.4 says that existing temporary addresses must have their
> lifetimes adjusted so that no temporary addresses should ever remain "valid"
> or "preferred" longer than the incoming SLAAC Prefix Information. This would
> strongly
RFC8981 section 3.4 says that existing temporary addresses must have their
lifetimes adjusted so that no temporary addresses should ever remain "valid"
or "preferred" longer than the incoming SLAAC Prefix Information. This would
strongly imply in Linux's case that if the "mngtmpaddr" address is del
On Mon, Nov 04, 2024 at 04:57:03PM +0800, Philo Lu wrote:
> When reading/writing virtio_net_ctrl_rss, we get the indirection table
> size from vi->rss_indir_table_size, which is initialized in
> virtnet_probe(). However, the actual size of indirection_table was set
> as VIRTIO_NET_RSS_MAX_TABLE_LEN
When reading/writing virtio_net_ctrl_rss, we get the indirection table
size from vi->rss_indir_table_size, which is initialized in
virtnet_probe(). However, the actual size of indirection_table was set
as VIRTIO_NET_RSS_MAX_TABLE_LEN=128. This collision may cause issues if
the vi->rss_indir_table_s
On Mon, Oct 21, 2024 at 12:25:26PM +0200, Matthieu Baerts (NGI0) wrote:
> Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT
> creates this splat when an MPTCP socket is created:
>
> =
> WARNING: suspicious RCU usage
> 6.12.0-rc2+ #11 Not tainted
Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT
creates this splat when an MPTCP socket is created:
=
WARNING: suspicious RCU usage
6.12.0-rc2+ #11 Not tainted
-
net/mptcp/sched.c:44 RCU-list traversed in non-re
A new endpoint using the IP of the initial subflow has been recently
added to increase the code coverage. But it breaks the test when using
old kernels not having commit 86e39e04482b ("mptcp: keep track of local
endpoint still available for each msk"), e.g. on v5.15.
Similar to commit d4c81bbb8600
> From: Leon Romanovsky [mailto:l...@kernel.org]
> Sent: Monday, April 5, 2021 1:43 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; k...@kernel.org; net...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Linuxarm ;
> linux...@openeuler.org
> Subject: Re: [PATCH net 1/2]
vger.kernel.org;
> > linux-kernel@vger.kernel.org; Linuxarm ;
> > linux...@openeuler.org
> > Subject: Re: [PATCH net 1/2] net: hns3: Remove the left over redundant check
> > & assignment
> >
> > On Sat, Apr 03, 2021 at 02:35:19AM +0100, Salil Mehta wrote:
; Subject: Re: [PATCH net 1/2] net: hns3: Remove the left over redundant check
> & assignment
>
> On Sat, Apr 03, 2021 at 02:35:19AM +0100, Salil Mehta wrote:
> > This removes the left over check and assignment which is no longer used
> > anywhere in the function and sho
On Sat, Apr 03, 2021 at 02:35:19AM +0100, Salil Mehta wrote:
> This removes the left over check and assignment which is no longer used
> anywhere in the function and should have been removed as part of the
> below mentioned patch.
>
> Fixes: 012fcb52f67c ("net: hns3: activate reset timer when call
This removes the left over check and assignment which is no longer used
anywhere in the function and should have been removed as part of the
below mentioned patch.
Fixes: 012fcb52f67c ("net: hns3: activate reset timer when calling reset_event")
Signed-off-by: Salil Mehta
---
drivers/net/ethernet
>> diff --git a/net/core/xdp.c b/net/core/xdp.c
>> index 05354976c1fc..4eaa28972af2 100644
>> --- a/net/core/xdp.c
>> +++ b/net/core/xdp.c
>> @@ -350,7 +350,8 @@ static void __xdp_return(void *data, struct
>xdp_mem_info *mem, bool napi_direct,
>> /* mem->id is valid, checked in
>xdp_rx
Jesper Dangaard Brouer writes:
> On Mon, 29 Mar 2021 16:00:39 +0800
> Ong Boon Leong wrote:
>
>> xdp_return_frame() may be called outside of NAPI context to return
>> xdpf back to page_pool. xdp_return_frame() calls __xdp_return() with
>> napi_direct = false. For page_pool memory model, __xdp_re
On Mon, 29 Mar 2021 16:00:39 +0800
Ong Boon Leong wrote:
> xdp_return_frame() may be called outside of NAPI context to return
> xdpf back to page_pool. xdp_return_frame() calls __xdp_return() with
> napi_direct = false. For page_pool memory model, __xdp_return() calls
> xdp_return_frame_no_direct
xdp_return_frame() may be called outside of NAPI context to return
xdpf back to page_pool. xdp_return_frame() calls __xdp_return() with
napi_direct = false. For page_pool memory model, __xdp_return() calls
xdp_return_frame_no_direct() unconditionally and below false negative
kernel BUG throw happen
On 3/27/2021 2:53 AM, Geert Uytterhoeven wrote:
Hi Samudrala,
On Fri, Mar 26, 2021 at 11:45 PM Samudrala, Sridhar
wrote:
On 3/26/2021 1:06 AM, Geert Uytterhoeven wrote:
On Thu, Mar 25, 2021 at 11:29 PM Tony Nguyen wrote:
From: Norbert Ciosek
Remove padding from RSS structures. Previous lay
Hi Samudrala,
On Fri, Mar 26, 2021 at 11:45 PM Samudrala, Sridhar
wrote:
> On 3/26/2021 1:06 AM, Geert Uytterhoeven wrote:
> > On Thu, Mar 25, 2021 at 11:29 PM Tony Nguyen
> > wrote:
> > From: Norbert Ciosek
> >
> > Remove padding from RSS structures. Previous layout
> > could lead to unwanted
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Mon, 15 Mar 2021 12:33:42 +0800 you wrote:
> if pl->mac_ops->mac_finish() failed, phylink_err should use
> "mac_finish" instead of "mac_prepare".
>
> Fixes: b7ad14c2fe2d4 ("net: phylink: re-implement interface configuration
if pl->mac_ops->mac_finish() failed, phylink_err should use
"mac_finish" instead of "mac_prepare".
Fixes: b7ad14c2fe2d4 ("net: phylink: re-implement interface configuration with
PCS")
Signed-off-by: Ong Boon Leong
---
drivers/net/phy/phylink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Fri, 5 Mar 2021 13:49:30 +0800 you wrote:
> For Intel mGbE controller, MAC VLAN filter delete operation will time-out
> if serdes power-down sequence happened first during driver remove() with
> below message.
>
> [82294.76
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Fri, 5 Mar 2021 14:03:42 +0800 you wrote:
> From: Wong Vee Khee
>
> Issue seen when enumerating multiple Intel mGbE interfaces in EHL.
>
> [6.898141] intel-eth-pci :00:1d.2: enabling device ( -> 0002)
> [6
From: Wong Vee Khee
Issue seen when enumerating multiple Intel mGbE interfaces in EHL.
[6.898141] intel-eth-pci :00:1d.2: enabling device ( -> 0002)
[6.900971] intel-eth-pci :00:1d.2: Fail to register stmmac-clk
[6.906434] intel-eth-pci :00:1d.2: User ID: 0x51, Synops
For Intel mGbE controller, MAC VLAN filter delete operation will time-out
if serdes power-down sequence happened first during driver remove() with
below message.
[82294.764958] intel-eth-pci :00:1e.4 eth2: stmmac_dvr_remove: removing
driver
[82294.778677] intel-eth-pci :00:1e.4 eth2: Time
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Wed, 3 Mar 2021 20:38:40 +0530 you wrote:
> From: Ong Boon Leong
>
> We introduce dwmac410_dma_init_channel() here for both EQoS v4.10 and
> above which use different DMA_CH(n)_Interrupt_Enable bit definitions for
> NIE an
ply.com;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Ong Boon
> Leong ; Voon Wei Feng
> ; Wong Vee Khee ;
> Ramesh Babu B
> Subject: [PATCH net 1/1] net: stmmac: fix incorrect DMA channel intr enable
> setting of EQoS v4.10
>
> From: Ong Boon Leong
&g
From: Ong Boon Leong
We introduce dwmac410_dma_init_channel() here for both EQoS v4.10 and
above which use different DMA_CH(n)_Interrupt_Enable bit definitions for
NIE and AIE.
Fixes: 48863ce5940f ("stmmac: add DMA support for GMAC 4.xx")
Signed-off-by: Ong Boon Leong
Signed-off-by: Ramesh Babu
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Tue, 2 Mar 2021 16:57:21 +0800 you wrote:
> On Intel platforms which consist of two Ethernet Controllers such as
> TGL-H and ADL-S, a unique MDIO bus id is required for MDIO bus to be
> successful registered:
>
> [ 13.076
On Intel platforms which consist of two Ethernet Controllers such as
TGL-H and ADL-S, a unique MDIO bus id is required for MDIO bus to be
successful registered:
[ 13.076133] sysfs: cannot create duplicate filename
'/class/mdio_bus/stmmac-1'
[ 13.083404] CPU: 8 PID: 1898 Comm: systemd-udevd Ta
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Thu, 18 Feb 2021 21:40:53 +0800 you wrote:
> From: "Song, Yoong Siang"
>
> When link speed is not 100 Mbps, port transmit rate and speed divider
> are set to 8 and 100 respectively. These values are incorrect for
> CBS
From: "Song, Yoong Siang"
When link speed is not 100 Mbps, port transmit rate and speed divider
are set to 8 and 100 respectively. These values are incorrect for
CBS idleslope and sendslope HW values calculation if the link speed is
not 1 Gbps.
This patch adds switch statement to set the val
On 06/02/2021 22.47, Horatiu Vultur wrote:
> The function br_mrp_port_switchdev_set_state was called both with MRP
> port state and STP port state, which is an issue because they don't
> match exactly.
>
> Therefore, update the function to be used only with STP port state and
> use the id SWITCHDE
1 - 100 of 676 matches
Mail list logo
