stall under the
instance lock, which the reconfig path needs to re-enable the NAPI and
therefore unblock the stalled thread.
There are two cases where we re-enable refill too early. One is in the
virtnet_set_queues() handler. We call it when installing XDP:
virtnet_
On Wed, 30 Apr 2025 01:29:06 -0400 Michael S. Tsirkin wrote:
> > > @@ -3728,7 +3731,7 @@ static int virtnet_set_queues(struct virtnet_info
> > > *vi, u16 queue_pairs)
> > > succ:
> > > vi->curr_queue_pairs = queue_pairs;
> > > /* virtnet_open() will refill when device is going to
On Tue, Apr 29, 2025 at 09:43:23AM -0700, Jakub Kicinski wrote:
> The selftests added to our CI by Bui Quang Minh recently reveals
> that there is a mem leak on the error path of virtnet_xsk_pool_enable():
>
> unreferenced object 0x88800a68a000 (size 2048):
> comm "xdp_helper", pid 318, jiff
ng to disable
> > the same NAPI instance. The refill work can't run in parallel with reconfig
> > because trying to double-disable a NAPI instance causes a stall under the
> > instance lock, which the reconfig path needs to re-enable the NAPI and
> > therefore unblock
n parallel with reconfig
> because trying to double-disable a NAPI instance causes a stall under the
> instance lock, which the reconfig path needs to re-enable the NAPI and
> therefore unblock the stalled thread.
>
> There are two cases where we re-enable refill too early. One is in
lel with reconfig
> because trying to double-disable a NAPI instance causes a stall under the
> instance lock, which the reconfig path needs to re-enable the NAPI and
> therefore unblock the stalled thread.
>
> There are two cases where we re-enable refill too early. One is in the
On Wed, Apr 30, 2025 at 12:43 AM Jakub Kicinski wrote:
>
> The selftests added to our CI by Bui Quang Minh recently reveals
> that there is a mem leak on the error path of virtnet_xsk_pool_enable():
>
> unreferenced object 0x88800a68a000 (size 2048):
> comm "xdp_helper", pid 318, jiffies 429
rying to double-disable a NAPI instance causes a stall under the
instance lock, which the reconfig path needs to re-enable the NAPI and
therefore unblock the stalled thread.
There are two cases where we re-enable refill too early. One is in the
virtnet_set_queues() handler. We call it when
stall under the
instance lock, which the reconfig path needs to re-enable the NAPI and
therefore unblock the stalled thread.
There are two cases where we re-enable refill too early. One is in the
virtnet_set_queues() handler. We call it when installing XDP:
virtnet_
Hello Jamal,
On Wed, Mar 19, 2025 at 05:05:08PM -0400, Jamal Hadi Salim wrote:
> On Wed, Mar 19, 2025 at 2:12 PM Breno Leitao wrote:
> >
> > On Wed, Mar 19, 2025 at 09:05:07AM -0700, Paul E. McKenney wrote:
> >
> > > > I think we should redesign lockdep_unregister_key() to work on a
> > > > sepa
On Wed, Mar 19, 2025 at 2:12 PM Breno Leitao wrote:
>
> On Wed, Mar 19, 2025 at 09:05:07AM -0700, Paul E. McKenney wrote:
>
> > > I think we should redesign lockdep_unregister_key() to work on a
> > > separately
> > > allocated piece of memory,
> > > then use kfree_rcu() in it.
> > >
> > > Ie not
On Wed, Mar 19, 2025 at 8:08 AM Eric Dumazet wrote:
>
>
>
> On Wed, Mar 19, 2025 at 4:04 PM Paul E. McKenney wrote:
>>
>> On Wed, Mar 19, 2025 at 07:56:40AM -0700, Breno Leitao wrote:
>> > On Wed, Mar 19, 2025 at 03:41:37PM +0100, Eric Dumazet wrote:
>> > > On Wed, Mar 19, 2025 at 2:09 PM Breno L
On Wed, Mar 19, 2025 at 11:12:24AM -0700, Breno Leitao wrote:
> On Wed, Mar 19, 2025 at 09:05:07AM -0700, Paul E. McKenney wrote:
>
> > > I think we should redesign lockdep_unregister_key() to work on a
> > > separately
> > > allocated piece of memory,
> > > then use kfree_rcu() in it.
> > >
> >
On Wed, Mar 19, 2025 at 09:05:07AM -0700, Paul E. McKenney wrote:
> > I think we should redesign lockdep_unregister_key() to work on a separately
> > allocated piece of memory,
> > then use kfree_rcu() in it.
> >
> > Ie not embed a "struct lock_class_key" in the struct Qdisc, but a pointer to
> >
On Wed, Mar 19, 2025 at 04:08:48PM +0100, Eric Dumazet wrote:
> On Wed, Mar 19, 2025 at 4:04 PM Paul E. McKenney wrote:
>
> > On Wed, Mar 19, 2025 at 07:56:40AM -0700, Breno Leitao wrote:
> > > On Wed, Mar 19, 2025 at 03:41:37PM +0100, Eric Dumazet wrote:
> > > > On Wed, Mar 19, 2025 at 2:09 PM B
On Wed, Mar 19, 2025 at 07:56:40AM -0700, Breno Leitao wrote:
> On Wed, Mar 19, 2025 at 03:41:37PM +0100, Eric Dumazet wrote:
> > On Wed, Mar 19, 2025 at 2:09 PM Breno Leitao wrote:
> >
> > > Hello,
> > >
> > > I am experiencing an issue with upstream kernel when compiled with debug
> > > capabil
On Tue, Mar 04, 2025 at 03:59:22PM +, Simon Horman wrote:
> A minor nit from my side:
>
> As you are changing this line, and it seems like there will be another
> revision of this series anyway, please consider updating the indentation to
> use tabs.
The patch is already applied to upstream a
On Thu, Feb 27, 2025 at 03:06:31PM -0800, Keith Busch wrote:
> From: Sean Christopherson
>
> A VMM may send a signal to its threads while they've entered KVM_RUN. If
> that thread happens to be trying to make the huge page recovery vhost
> task, then it fails with -ERESTARTNOINTR. We need to retr
On 2/27/25 5:06 PM, Keith Busch wrote:
> From: Keith Busch
>
> Lets callers distinguish why the vhost task creation failed. No one
> currently cares why it failed, so no real runtime change from this
> patch, but that will not be the case for long.
>
> Signed-off-by: Keith Busch
> ---
> arch/x
On Fri, Feb 28, 2025, Paolo Bonzini wrote:
> On 2/28/25 16:36, Keith Busch wrote:
> > On Fri, Feb 28, 2025 at 07:29:45AM -0800, Sean Christopherson wrote:
> > > On Fri, Feb 28, 2025, Keith Busch wrote:
> > > > On Fri, Feb 28, 2025 at 06:32:47AM -0800, Sean Christopherson wrote:
> > > > > > @@ -35,1
On 2/28/25 16:36, Keith Busch wrote:
On Fri, Feb 28, 2025 at 07:29:45AM -0800, Sean Christopherson wrote:
On Fri, Feb 28, 2025, Keith Busch wrote:
On Fri, Feb 28, 2025 at 06:32:47AM -0800, Sean Christopherson wrote:
@@ -35,10 +35,12 @@ static inline int call_once(struct once *once, int
(*cb)(
On Fri, Feb 28, 2025 at 07:29:45AM -0800, Sean Christopherson wrote:
> On Fri, Feb 28, 2025, Keith Busch wrote:
> > On Fri, Feb 28, 2025 at 06:32:47AM -0800, Sean Christopherson wrote:
> > > > @@ -35,10 +35,12 @@ static inline int call_once(struct once *once, int
> > > > (*cb)(struct once *))
> >
On Fri, Feb 28, 2025, Keith Busch wrote:
> On Fri, Feb 28, 2025 at 06:32:47AM -0800, Sean Christopherson wrote:
> > > diff --git a/include/linux/call_once.h b/include/linux/call_once.h
> > > index ddcfd91493ea..b053f4701c94 100644
> > > --- a/include/linux/call_once.h
> > > +++ b/include/linux/call
On Fri, Feb 28, 2025 at 06:32:47AM -0800, Sean Christopherson wrote:
> On Fri, Feb 28, 2025, Sean Christopherson wrote:
> > On Fri, Feb 28, 2025, Lei Yang wrote:
> > > Hi Keith
> > >
> > > V3 introduced a new bug, the following error messages from qemu output
> > > after applying this patch to boo
On Fri, Feb 28, 2025, Sean Christopherson wrote:
> On Fri, Feb 28, 2025, Lei Yang wrote:
> > Hi Keith
> >
> > V3 introduced a new bug, the following error messages from qemu output
> > after applying this patch to boot up a guest.
>
> Doh, my bug. Not yet tested, but this should fix things. Ass
On Fri, Feb 28, 2025, Lei Yang wrote:
> Hi Keith
>
> V3 introduced a new bug, the following error messages from qemu output
> after applying this patch to boot up a guest.
Doh, my bug. Not yet tested, but this should fix things. Assuming it does,
I'll
post a v3 so I can add my SoB.
diff --git
Hi Keith
V3 introduced a new bug, the following error messages from qemu output
after applying this patch to boot up a guest.
Error messages:
error: kvm run failed Invalid argument
error: kvm run failed Invalid argument
EAX= EBX= ECX= EDX=000806f4
ESI= EDI=
requirements of the specification: "in-order, guaranteed,
connection-oriented delivery".
Thanks,
Stefano
>
>
> Best Wish
>
> - Original Message -
>
> Sender : Stefano Garzarella
>
> Date : 2025-02-11 00:52 (GMT+8)
>
> Title : Re: [PATCH 2/2]
On Mon, Feb 10, 2025 at 12:48:03PM +0100, leona...@redhat.com wrote:
Like for the other patch, some maintainers have not been CCd.
Yes, please use `scripts/get_maintainer.pl`.
On Fri, Feb 07, 2025 at 01:20:33PM +0800, Junnan Wu wrote:
From: Ying Gao
If suspend is executed during vsock com
On Fri, Feb 07, 2025 at 01:20:32PM +0800, Junnan Wu wrote:
From: Ying Gao
In function virtio_vsock_probe, it initializes the variables
"rx_buf_nr" and "rx_buf_max_nr",
but in function virtio_vsock_restore it doesn't.
Move the initizalition position into function virtio_vsock_vqs_start.
Once e
Like for the other patch, some maintainers have not been CCd.
On Fri, Feb 07, 2025 at 01:20:33PM +0800, Junnan Wu wrote:
From: Ying Gao
If suspend is executed during vsock communication and the
socket is reset, the original socket will be unusable after resume.
Judge the value of vdev->priv i
Hi Junnan, Ying
Thank you for the contribution!
A few minor comments on the process:
I think this series is missing a cover letter, not all the maintainers
have been CCd, and you should add the tag net (because it's a fix) to
the subject. (e.g. [PATCH net 1/2]).
Here you can find some useful
On Wed, Feb 5, 2025 at 8:57 AM Eric Dumazet wrote:
>
>
> I will squash this diff to the following iteration, and keep rcu_dereference()
>
>
I will shrink the series in V4 to only include known bug fixes, to
lower the risk of having 10 more iterations.
On Tue, Feb 4, 2025 at 10:30 PM Jakub Kicinski wrote:
>
> On Tue, 4 Feb 2025 13:17:08 -0800 Paul E. McKenney wrote:
> > > > TBH I'm slightly confused by this, and the previous warnings.
> > > >
> > > > The previous one was from a timer callback.
> > > >
> > > > This one is with BH disabled.
> > >
On Tue, Feb 04, 2025 at 01:30:25PM -0800, Jakub Kicinski wrote:
> On Tue, 4 Feb 2025 13:17:08 -0800 Paul E. McKenney wrote:
> > > > TBH I'm slightly confused by this, and the previous warnings.
> > > >
> > > > The previous one was from a timer callback.
> > > >
> > > > This one is with BH disabled.
On Tue, 4 Feb 2025 13:17:08 -0800 Paul E. McKenney wrote:
> > > TBH I'm slightly confused by this, and the previous warnings.
> > >
> > > The previous one was from a timer callback.
> > >
> > > This one is with BH disabled.
> > >
> > > I thought BH implies RCU protection. We certainly depend on tha
On Tue, Feb 04, 2025 at 10:06:15PM +0100, Eric Dumazet wrote:
> On Tue, Feb 4, 2025 at 10:00 PM Jakub Kicinski wrote:
> >
> > On Tue, 4 Feb 2025 21:10:59 +0100 Eric Dumazet wrote:
> > > > Test output:
> > > > https://netdev-3.bots.linux.dev/vmksft-net-dbg/results/978202/61-l2tp-sh/
> > > > Decoded
On Tue, 4 Feb 2025 21:10:59 +0100 Eric Dumazet wrote:
> > Test output:
> > https://netdev-3.bots.linux.dev/vmksft-net-dbg/results/978202/61-l2tp-sh/
> > Decoded:
> > https://netdev-3.bots.linux.dev/vmksft-net-dbg/results/978202/vm-crash-thr2-0
> >
>
> Oh well. So many bugs.
TBH I'm slightly co
On Tue, Feb 4, 2025 at 10:00 PM Jakub Kicinski wrote:
>
> On Tue, 4 Feb 2025 21:10:59 +0100 Eric Dumazet wrote:
> > > Test output:
> > > https://netdev-3.bots.linux.dev/vmksft-net-dbg/results/978202/61-l2tp-sh/
> > > Decoded:
> > > https://netdev-3.bots.linux.dev/vmksft-net-dbg/results/978202/vm-c
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski :
On Tue, 28 Jan 2025 14:15:26 +0100 you wrote:
> Series deals with two issues:
> - socket reference count imbalance due to an unforgiving transport release
> (triggered by transport reassignment);
> - unintentional API f
On Tue, Jan 28, 2025 at 02:15:26PM +0100, Michal Luczaj wrote:
Series deals with two issues:
- socket reference count imbalance due to an unforgiving transport release
(triggered by transport reassignment);
- unintentional API feature, a failing connect() making the socket
impossible to use for
ingemar.s.johans...@ericsson.com;
> >mirja.kuehlew...@ericsson.com; chesh...@apple.com; rs.i...@gmx.at;
> >jason_living...@comcast.com; vidhi_g...@apple.com
> >Subject: Re: [PATCH v6 net-next 11/14] virtio_net: Accurate ECN flag in
> >virtio_net_hd
a.com; m...@redhat.com;
> > >xuanz...@linux.alibaba.com; epere...@redhat.com;
> > >virtualizat...@lists.linux.dev; i...@kernel.org; ncardw...@google.com;
> > >Koen De Schepper (Nokia) ;
> > >g.wh...@cablelabs.com; ingemar.s.johans...@ericsson.com;
> > &g
labs.com; ingemar.s.johans...@ericsson.com;
> >mirja.kuehlew...@ericsson.com; chesh...@apple.com; rs.i...@gmx.at;
> >jason_living...@comcast.com; vidhi_g...@apple.com
> >Subject: Re: [PATCH v6 net-next 11/14] virtio_net: Accurate ECN flag in
> >virtio_net_hdr
&
.alibaba.com; epere...@redhat.com;
>virtualizat...@lists.linux.dev; i...@kernel.org; ncardw...@google.com; Koen De
>Schepper (Nokia) ;
>g.wh...@cablelabs.com; ingemar.s.johans...@ericsson.com;
>mirja.kuehlew...@ericsson.com; chesh...@apple.com; rs.i...@gmx.at;
>jason_living...@comcast.com;
On Sat, Dec 28, 2024 at 3:13 AM wrote:
>
> From: Chia-Yu Chang
>
> Unlike RFC 3168 ECN, accurate ECN uses the CWR flag as part of the ACE
> field to count new packets with CE mark; however, it will be corrupted
> by the RFC 3168 ECN-aware TSO. Therefore, fallback shall be applied by
> seting NETI
On Fri, 27 Dec 2024 20:11:57 +0100 chia-yu.ch...@nokia-bell-labs.com
wrote:
> Hello
Hello.
Someone may still review, but:
## Form letter - winter-break
Networking development is suspended for winter holidays, until Jan 2nd.
We are currently accepting bug fixes only, see the announcements at:
h
On 12/20/24 11:49, Stefano Garzarella wrote:
> ...
> Note that non-NULL -> NULL should only occur before a connection is
> established, so before any data is passed. Is this a problem for BPF?
Please take a look at vsock_bpf_update_proto(). The condition is to have a
transport assigned. BPF assum
/net/vmw_vsock/vsock_bpf.c
+++ b/net/vmw_vsock/vsock_bpf.c
@@ -119,6 +119,7 @@ static void vsock_bpf_rebuild_protos(struct proto *prot,
const struct proto *bas
*prot= *base;
prot->close = sock_map_close;
prot->recvmsg = vsock_bpf_recvmsg;
+ prot->unhash
path can only be taken during vsock_connect(), where we
* have already held the sock lock. In the other cases, this
diff --git a/net/vmw_vsock/vsock_bpf.c b/net/vmw_vsock/vsock_bpf.c
index 4aa6e74ec295..80deb4d70aea 100644
--- a/net/vmw_vsock/vsock_bpf.c
+++ b/net/vmw_vsock/vsock_bpf.c
@@ -119,6 +119,7 @@ static void vsock_bpf_rebuild_protos(struct proto *prot,
const struct proto *bas
*prot= *base;
prot->close = sock_map_close;
prot->recvmsg = vsock_bpf_recvmsg;
+ prot->unhash = sock_map_unhash;
prot->sock_is_readable = sk_msg_is_readable;
}
>> Then a successful re-connect assigns
>> the transport (NULL -> non-NULL). And it's all good because all I wanted to
>> avoid (because of BPF) was non-NULL -> NULL. Anyway, that's my possibly
>> shallow understanding :)
connect() that requires a specific
> > transport, this one fails maybe because there's no peer with that cid.
> > Then the user can redo the connect() to a different cid that requires
> > a different transport.
>
> But the initial connect() failing does not change any
hange the transport.
>
> Because a user can do an initial connect() that requires a specific
> transport, this one fails maybe because there's no peer with that cid.
> Then the user can redo the connect() to a different cid that requires
> a different transport.
But the initial connect
On Thu, 19 Dec 2024 at 15:36, Michal Luczaj wrote:
>
> On 12/19/24 09:19, Stefano Garzarella wrote:
> > ...
> > I think the best thing though is to better understand how to handle
> > deassign, rather than checking everywhere that it's not null, also
> > because in some cases (like the one in virt
On 12/19/24 09:19, Stefano Garzarella wrote:
> ...
> I think the best thing though is to better understand how to handle
> deassign, rather than checking everywhere that it's not null, also
> because in some cases (like the one in virtio-vsock), it's also
> important that the transport is the sa
On Wed, Dec 18, 2024 at 08:37:38PM -0500, Hyunwoo Kim wrote:
On Thu, Dec 19, 2024 at 01:25:34AM +0100, Michal Luczaj wrote:
On 12/18/24 16:51, Hyunwoo Kim wrote:
> On Wed, Dec 18, 2024 at 04:31:03PM +0100, Stefano Garzarella wrote:
>> On Wed, Dec 18, 2024 at 03:40:40PM +0100, Stefano Garzarella
On Thu, Dec 19, 2024 at 01:25:34AM +0100, Michal Luczaj wrote:
> On 12/18/24 16:51, Hyunwoo Kim wrote:
> > On Wed, Dec 18, 2024 at 04:31:03PM +0100, Stefano Garzarella wrote:
> >> On Wed, Dec 18, 2024 at 03:40:40PM +0100, Stefano Garzarella wrote:
> >>> On Wed, Dec 18, 2024 at 09:19:08AM -0500, Hyu
On 12/18/24 16:51, Hyunwoo Kim wrote:
> On Wed, Dec 18, 2024 at 04:31:03PM +0100, Stefano Garzarella wrote:
>> On Wed, Dec 18, 2024 at 03:40:40PM +0100, Stefano Garzarella wrote:
>>> On Wed, Dec 18, 2024 at 09:19:08AM -0500, Hyunwoo Kim wrote:
At least for vsock_loopback.c, this change doesn’t
On Wed, Dec 18, 2024 at 04:31:03PM +0100, Stefano Garzarella wrote:
> On Wed, Dec 18, 2024 at 03:40:40PM +0100, Stefano Garzarella wrote:
> > On Wed, Dec 18, 2024 at 09:19:08AM -0500, Hyunwoo Kim wrote:
> > > On Wed, Dec 18, 2024 at 02:40:49PM +0100, Stefano Garzarella wrote:
> > > > On Wed, Dec 18
On Wed, Dec 18, 2024 at 03:40:40PM +0100, Stefano Garzarella wrote:
On Wed, Dec 18, 2024 at 09:19:08AM -0500, Hyunwoo Kim wrote:
On Wed, Dec 18, 2024 at 02:40:49PM +0100, Stefano Garzarella wrote:
On Wed, Dec 18, 2024 at 07:25:07AM -0500, Hyunwoo Kim wrote:
When calling connect to change the C
On Wed, Dec 18, 2024 at 09:19:08AM -0500, Hyunwoo Kim wrote:
On Wed, Dec 18, 2024 at 02:40:49PM +0100, Stefano Garzarella wrote:
On Wed, Dec 18, 2024 at 07:25:07AM -0500, Hyunwoo Kim wrote:
> When calling connect to change the CID of a vsock, the loopback
> worker for the VIRTIO_VSOCK_OP_RST com
On Wed, Dec 18, 2024 at 02:40:49PM +0100, Stefano Garzarella wrote:
> On Wed, Dec 18, 2024 at 07:25:07AM -0500, Hyunwoo Kim wrote:
> > When calling connect to change the CID of a vsock, the loopback
> > worker for the VIRTIO_VSOCK_OP_RST command is invoked.
> > During this process, vsock_stream_has
On Wed, Dec 18, 2024 at 07:25:07AM -0500, Hyunwoo Kim wrote:
When calling connect to change the CID of a vsock, the loopback
worker for the VIRTIO_VSOCK_OP_RST command is invoked.
During this process, vsock_stream_has_data() calls
vsk->transport->stream_has_data().
However, a null-ptr-deref occur
On 11/19/24 11:31, Stefano Garzarella wrote:
> Hi Michal,
>
> On Thu, Nov 07, 2024 at 09:46:11PM +0100, Michal Luczaj wrote:
>> Short series fixing some memory leaks that I've stumbled upon while
>> toying
>> with the selftests.
>
> Are these tests already upstream?
> I would like to add them to
Hi Michal,
On Thu, Nov 07, 2024 at 09:46:11PM +0100, Michal Luczaj wrote:
Short series fixing some memory leaks that I've stumbled upon while
toying
with the selftests.
Are these tests already upstream?
I would like to add them to my suite, can you tell me how to run them?
Thanks,
Stefano
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Tue, 12 Nov 2024 09:29:15 +0800 you wrote:
> v4:
> 1. rebase net-next
> 2. update the kdoc for the new APIs
>
> v3:
> 1. use sg_dma_address/length api to set the premapped sg
> 2. remove 'premappe
om; ingemar.s.johans...@ericsson.com;
>mirja.kuehlew...@ericsson.com; chesh...@apple.com; rs.i...@gmx.at;
>jason_living...@comcast.com; vidhi_g...@apple.com
>Subject: Re: [PATCH v5 net-next 09/13] gro: prevent ACE field corruption &
>better AccECN handling
>
>[You don't often ge
rja.kuehlew...@ericsson.com;
> > >chesh...@apple.com; rs.i...@gmx.at; jason_living...@comcast.com;
> > >vidhi_g...@apple.com
> > >Subject: Re: [PATCH v5 net-next 09/13] gro: prevent ACE field corruption &
> > >better AccECN handling
> > >
@netfilter.org; ncardw...@google.com; Koen De Schepper (Nokia)
> >; g.wh...@cablelabs.com;
> >ingemar.s.johans...@ericsson.com; mirja.kuehlew...@ericsson.com;
> >chesh...@apple.com; rs.i...@gmx.at; jason_living...@comcast.com;
> >vidhi_g...@apple.com
> >Subject:
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni :
On Thu, 07 Nov 2024 21:46:11 +0100 you wrote:
> Short series fixing some memory leaks that I've stumbled upon while toying
> with the selftests.
>
> Signed-off-by: Michal Luczaj
> ---
> Changes in v2:
> - Remove the refact
On Thu, 7 Nov 2024 16:54:56 +0800 Xuan Zhuo wrote:
> + * Returns zero or a negative error (ie. ENOSPC, ENOMEM, EIO).
> + * Returns zero or a negative error (ie. ENOSPC, ENOMEM, EIO).
Looks like we need a rebase, doesn't apply any more.
When you rebase please correct the kdoc, looks like the off
On 07.11.2024 23:46, Michal Luczaj wrote:
> Kernel queues MSG_ZEROCOPY completion notifications on the error queue.
> Where they remain, until explicitly recv()ed. To prevent memory leaks,
> clean up the queue when the socket is destroyed.
>
> unreferenced object 0x8881028beb00 (size 224):
On 07.11.2024 23:46, Michal Luczaj wrote:
> Add a missing kfree_skb() to prevent memory leaks.
>
> Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support")
> Reviewed-by: Stefano Garzarella
> Signed-off-by: Michal Luczaj
> ---
> net/vmw_vsock/virtio_transport_common.c | 1 +
> 1 file
On 06.11.2024 20:51, Michal Luczaj wrote:
> Add a missing kfree_skb() to prevent memory leaks.
>
> Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support")
> Signed-off-by: Michal Luczaj
> ---
> net/vmw_vsock/virtio_transport_common.c | 1 +
> 1 file changed, 1 insertion(+)
Acked-by:
On Mon, Nov 11, 2024 at 11:53 AM Xuan Zhuo wrote:
>
> On Thu, 7 Nov 2024 16:54:54 +0800, Xuan Zhuo
> wrote:
> > The subsequent commit needs to know whether every indirect buffer is
> > premapped or not. So we need to introduce an extra struct for every
> > indirect buffer to record this info.
>
On Thu, 7 Nov 2024 16:54:54 +0800, Xuan Zhuo
wrote:
> The subsequent commit needs to know whether every indirect buffer is
> premapped or not. So we need to introduce an extra struct for every
> indirect buffer to record this info.
>
> Signed-off-by: Xuan Zhuo
Hi, Jason
This also needs a rev
On Thu, Nov 7, 2024 at 4:55 PM Xuan Zhuo wrote:
>
> virtio-net rq submits premapped per-buffer by setting sg page to NULL;
>
> Signed-off-by: Xuan Zhuo
> ---
> drivers/net/virtio_net.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/v
On Thu, Nov 7, 2024 at 4:55 PM Xuan Zhuo wrote:
>
> Two APIs are introduced to submit premapped per-buffers.
>
> int virtqueue_add_inbuf_premapped(struct virtqueue *vq,
> struct scatterlist *sg, unsigned int num,
> void *data,
>
On Thu, Nov 7, 2024 at 4:55 PM Xuan Zhuo wrote:
>
> The subsequent commit needs to know whether every indirect buffer is
> premapped or not. So we need to introduce an extra struct for every
> indirect buffer to record this info.
>
> Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
Thanks
On Wed, Nov 6, 2024 at 3:42 PM Michael S. Tsirkin wrote:
>
> On Wed, Nov 06, 2024 at 09:44:39AM +0800, Jason Wang wrote:
> > > > > while (vq->split.vring.desc[i].flags & nextflag) {
> > > > > - vring_unmap_one_split(vq, i);
> > > > > + vring_unmap_one_split(vq,
On Thu, Nov 07, 2024 at 10:04:03PM +0100, Michal Luczaj wrote:
On 11/7/24 11:22, Stefano Garzarella wrote:
On Wed, Nov 06, 2024 at 06:51:21PM +0100, Michal Luczaj wrote:
Macro vsock_connected_sockets_vsk() has been unused since its introduction.
Instead of removing it, utilise it in vsock_inser
On Thu, Nov 07, 2024 at 09:46:13PM +0100, Michal Luczaj wrote:
Kernel queues MSG_ZEROCOPY completion notifications on the error queue.
Where they remain, until explicitly recv()ed. To prevent memory leaks,
clean up the queue when the socket is destroyed.
unreferenced object 0x8881028beb00 (s
On 11/7/24 11:22, Stefano Garzarella wrote:
> On Wed, Nov 06, 2024 at 06:51:21PM +0100, Michal Luczaj wrote:
>> Macro vsock_connected_sockets_vsk() has been unused since its introduction.
>> Instead of removing it, utilise it in vsock_insert_connected() where it's
>> been open-coded.
>>
>> No funct
On 11/7/24 11:17, Stefano Garzarella wrote:
> On Wed, Nov 06, 2024 at 06:51:19PM +0100, Michal Luczaj wrote:
>> Kernel queues MSG_ZEROCOPY completion notifications on the error queue.
>> Where they remain, until explicitly recv()ed. To prevent memory leaks,
>> clean up the queue when the socket is
On Wed, Nov 06, 2024 at 06:51:21PM +0100, Michal Luczaj wrote:
Macro vsock_connected_sockets_vsk() has been unused since its introduction.
Instead of removing it, utilise it in vsock_insert_connected() where it's
been open-coded.
No functional change intended.
Fixes: d021c344051a ("VSOCK: Intro
On Wed, Nov 06, 2024 at 06:51:20PM +0100, Michal Luczaj wrote:
Add a missing kfree_skb() to prevent memory leaks.
Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support")
Signed-off-by: Michal Luczaj
---
net/vmw_vsock/virtio_transport_common.c | 1 +
1 file changed, 1 insertion(+)
Revie
On Wed, Nov 06, 2024 at 06:51:19PM +0100, Michal Luczaj wrote:
Kernel queues MSG_ZEROCOPY completion notifications on the error queue.
Where they remain, until explicitly recv()ed. To prevent memory leaks,
clean up the queue when the socket is destroyed.
unreferenced object 0x8881028beb00 (s
On Wed, Nov 06, 2024 at 06:51:18PM +0100, Michal Luczaj wrote:
As the final stages of socket destruction may be delayed, it is possible
that virtio_transport_recv_listen() will be called after the accept_queue
has been flushed, but before the SOCK_DONE flag has been set. As a result,
sockets enqu
On Wed, 6 Nov 2024 04:16:07 -0500 Michael S. Tsirkin wrote:
> I thought it can but can't remember why now. OK, nm then, thanks!
FWIW (I think there was confusion in earlier discussions) we do merge
net into net-next once a week. So we can always apply stuff to net,
and then depending patches to ne
gt; > > In the last linux version, we disabled this feature to fix the
> > > > regress[1].
> > > >
> > > > The patch set is try to fix the problem and re-enable it.
> > > >
> > > > More info:
> > > > http://lore.kernel.org/al
regress[1].
> > >
> > > The patch set is try to fix the problem and re-enable it.
> > >
> > > More info:
> > > http://lore.kernel.org/all/20240820071913.68004-1-xuanz...@linux.alibaba.com
> >
> > Sorry to ping, Michael, Jason we're wa
On Wed, Nov 06, 2024 at 09:44:39AM +0800, Jason Wang wrote:
> > > > while (vq->split.vring.desc[i].flags & nextflag) {
> > > > - vring_unmap_one_split(vq, i);
> > > > + vring_unmap_one_split(vq, &extra[i]);
> > >
> > > Not sure if I've asked this before. But this
On Mon, Nov 04, 2024 at 06:46:41PM -0800, Jakub Kicinski wrote:
> On Tue, 29 Oct 2024 16:46:11 +0800 Xuan Zhuo wrote:
> > In the last linux version, we disabled this feature to fix the
> > regress[1].
> >
> > The patch set is try to fix the problem and re-enable it.
&g
On Tue, Oct 29, 2024 at 04:46:12PM +0800, Xuan Zhuo wrote:
> When the frag just got a page, then may lead to regression on VM.
> Specially if the sysctl net.core.high_order_alloc_disable value is 1,
> then the frag always get a page when do refill.
>
> Which could see reliable crashes or scp failu
On Wed, 6 Nov 2024 09:44:39 +0800, Jason Wang wrote:
> On Tue, Nov 5, 2024 at 2:53 PM Xuan Zhuo wrote:
> >
> > On Tue, 5 Nov 2024 11:42:09 +0800, Jason Wang wrote:
> > > On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo
> > > wrote:
> > > >
> > > > The subsequent commit needs to know whether every ind
On Wed, 6 Nov 2024 09:56:55 +0800, Jason Wang wrote:
> On Tue, Nov 5, 2024 at 3:23 PM Xuan Zhuo wrote:
> >
> > On Tue, 5 Nov 2024 11:23:50 +0800, Jason Wang wrote:
> > > On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo
> > > wrote:
> > > >
> > > > virtio-net rq submits premapped per-buffer by setting
On Tue, Nov 5, 2024 at 3:23 PM Xuan Zhuo wrote:
>
> On Tue, 5 Nov 2024 11:23:50 +0800, Jason Wang wrote:
> > On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo
> > wrote:
> > >
> > > virtio-net rq submits premapped per-buffer by setting sg page to NULL;
> > >
> > > Signed-off-by: Xuan Zhuo
> > > ---
>
On Tue, Nov 5, 2024 at 2:53 PM Xuan Zhuo wrote:
>
> On Tue, 5 Nov 2024 11:42:09 +0800, Jason Wang wrote:
> > On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo
> > wrote:
> > >
> > > The subsequent commit needs to know whether every indirect buffer is
> > > premapped or not. So we need to introduce an e
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni :
On Tue, 29 Oct 2024 16:46:11 +0800 you wrote:
> v1:
> 1. fix some small problems
> 2. remove commit "virtio_net: introduce vi->mode"
>
> In the last linux version, we disabled this feature to fix the
> regress[
On Tue, Oct 29, 2024 at 4:47 PM Xuan Zhuo wrote:
>
> Now, the premapped mode can be enabled unconditionally.
>
> So we can remove the failover code for merge and small mode.
>
> The virtnet_rq_xxx() helper would be only used if the mode is using pre
> mapping. A check is added to prevent misusing
On Tue, Oct 29, 2024 at 4:47 PM Xuan Zhuo wrote:
>
> When the frag just got a page, then may lead to regression on VM.
> Specially if the sysctl net.core.high_order_alloc_disable value is 1,
> then the frag always get a page when do refill.
>
> Which could see reliable crashes or scp failure (scp
1 - 100 of 17874 matches
Mail list logo
