:
>
> Hello leonardi and stefanha：
>
> Thanks for your review. And I will add other maintainers CCd in
> next push. And I want to discuss more about the second patch.
Why are you sending a v2 if we didn't reach an agreement on the second
patch?
>
>
> Fi
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
in
virtio_vsock_probe(), but they should be reset whenever virtqueues
are recreated, like after a suspend/resume. ...
[Desribe the fix, what this patch does]
Move the `rx_buf_nr` and `rx_buf_max_nr` initialization in
virtio_vsock_vqs_init(), so we are sure that they are properly
initializ
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->p
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
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 executing s2r twice in a row without
initializing rx_buf_nr an
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 in function virtio_vsock_vqs_del,
only when the function is invoked by virtio_vsock_remove,
all vsock connections will be res
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
entional API feature, a failing connect() making the socket
> impossible to use for any subsequent connect() attempts.
>
> Luigi, I took the opportunity to comment vsock_bind() (patch 3/6), and I've
> kept your Reviewed-by. Is this okay?
>
> [...]
Here is the summary with
for any subsequent connect() attempts.
Luigi, I took the opportunity to comment vsock_bind() (patch 3/6), and I've
kept your Reviewed-by. Is this okay?
Hi Michal,
Yes, absolutely! Thanks for adding the comment :)
Cheers,
Luigi
Signed-off-by: Michal Luczaj
---
Changes in v3:
- Rebase
- Co
Preserve sockets bindings; this includes both resulting from an explicit
bind() and those implicitly bound through autobind during connect().
Prevents socket unbinding during a transport reassignment, which fixes a
use-after-free:
1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (ref
sk_err is set when a (connectible) connect() fails. Effectively, this makes
an otherwise still healthy SS_UNCONNECTED socket impossible to use for any
subsequent connection attempts.
Clear sk_err upon trying to establish a connection.
Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Reviewed-b
Distill timeout-guarded vsock_connect_fd(). Adapt callers.
Suggested-by: Stefano Garzarella
Reviewed-by: Stefano Garzarella
Signed-off-by: Michal Luczaj
---
tools/testing/vsock/util.c | 45 +
tools/testing/vsock/util.h | 1 +
2 files changed, 18 ins
Deliberately fail a connect() attempt; expect error. Then verify that
subsequent attempt (using the same socket) can still succeed, rather than
fail outright.
Reviewed-by: Stefano Garzarella
Reviewed-by: Luigi Leonardi
Signed-off-by: Michal Luczaj
---
tools/testing/vsock/vsock_test.c | 47
Fail the autobind, then trigger a transport reassign. Socket might get
unbound from unbound_sockets, which then leads to a reference count
underflow.
Reviewed-by: Stefano Garzarella
Signed-off-by: Michal Luczaj
---
tools/testing/vsock/vsock_test.c | 58
Add a helper for socket()+bind(). Adapt callers.
Reviewed-by: Stefano Garzarella
Reviewed-by: Luigi Leonardi
Signed-off-by: Michal Luczaj
---
tools/testing/vsock/util.c | 57 +---
tools/testing/vsock/util.h | 1 +
tools/testing/vsock/vsock_test.
opportunity to comment vsock_bind() (patch 3/6), and I've
kept your Reviewed-by. Is this okay?
Signed-off-by: Michal Luczaj
---
Changes in v3:
- Rebase
- Comment vsock_bind() (Luigi)
- Collect Reviewed-by (Stefano, Luigi)
- Link to v2:
https://lore.kernel.org/r/20250121-vsock-transport-vs-autobind
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
t;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
> > >
> > >[You don't often
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;
/debugfs.c | 6 ++
> include/linux/virtio_net.h | 16 ++--
> include/uapi/linux/virtio_net.h | 5 +
> 4 files changed, 32 insertions(+), 9 deletions(-)
Is there a link to the spec patch? It needs to be accepted first.
Thanks
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
From: Ilpo Järvinen
ECN bits in TOS are always cleared when sending in ACKs in TW. Clearing
them is problematic for TCP flows that used Accurate ECN because ECN bits
decide which service queue the packet is placed into (L4S vs Classic).
Effectively, TW ACKs are always downgraded from L4S to Class
From: Chia-Yu Chang
In Accurate ECN, ACE counter (AE, ECE, CWR flags) changes only when new
CE packets arrive, while setting SKB_GSO_TCP_ECN in case of not knowing
the ECN variant can result in header change that corrupts the ACE field.
The new flag SKB_GSO_TCP_ACCECN is to prevent SKB_GSO_TCP_EC
From: Ilpo Järvinen
Accurate ECN needs to send custom flags to handle IP-ECN
field reflection during handshake.
Signed-off-by: Ilpo Järvinen
Signed-off-by: Chia-Yu Chang
Reviewed-by: Eric Dumazet
---
include/net/tcp.h | 2 +-
net/ipv4/bpf_tcp_ca.c | 2 +-
net/ipv4/tcp_dctcp.h | 2 +-
ne
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 NETIF_F_GSO_ACCECN to ensure that the CWR flag should not
From: Ilpo Järvinen
AE flag needs to be preserved for AccECN.
Signed-off-by: Ilpo Järvinen
Signed-off-by: Chia-Yu Chang
Reviewed-by: Eric Dumazet
---
net/ipv4/tcp_ipv4.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index b0b8
should be evaluated per NIC basis
(not done in this patch series for any NICs).
For the cases, where TSO cannot keep its hands off the CWR flag,
a GSO fallback is provided by this patch.
Signed-off-by: Ilpo Järvinen
Signed-off-by: Chia-Yu Chang
Reviewed-by: Eric Dumazet
---
incl
From: Ilpo Järvinen
Create helpers for TCP ECN modes. No functional changes.
Signed-off-by: Ilpo Järvinen
Signed-off-by: Chia-Yu Chang
Reviewed-by: Eric Dumazet
---
include/net/tcp.h| 44
net/ipv4/tcp.c | 2 +-
net/ipv4/tcp_dctcp.c
From: Ilpo Järvinen
There are important differences in how the CWR field behaves
in RFC3168 and AccECN. With AccECN, CWR flag is part of the
ACE counter and its changes are important so adjust the flags
changed mask accordingly.
Also, if CWR is there, set the Accurate ECN GSO flag to avoid
corru
From: Ilpo Järvinen
With AccECN, there's one additional TCP flag to be used (AE)
and ACE field that overloads the definition of AE, CWR, and
ECE flags. As tcp_flags was previously only 1 byte, the
byte-order stuff needs to be added to it's handling.
Signed-off-by: Ilpo Järvinen
Signed-off-by: C
From: Ilpo Järvinen
Rename tcp_ecn_check_ce to tcp_data_ecn_check as it is
called only for data segments, not for ACKs (with AccECN,
also ACKs may get ECN bits).
The extra "layer" in tcp_ecn_check_ce() function just
checks for ECN being enabled, that can be moved into
tcp_ecn_field_check rather
From: Ilpo Järvinen
Prepare for AccECN that needs to have access here on IP ECN
field value which is only available after INET_ECN_xmit().
No functional changes.
Signed-off-by: Ilpo Järvinen
Signed-off-by: Chia-Yu Chang
Reviewed-by: Eric Dumazet
---
net/ipv4/tcp_output.c | 5 +++--
1 file c
From: Chia-Yu Chang
Use BIT() macro for TCP flags field and TCP congestion control
flags that will be used by the congestion control algorithm.
No functional changes.
Signed-off-by: Chia-Yu Chang
Reviewed-by: Ilpo Järvinen
Reviewed-by: Eric Dumazet
---
include/net/tcp.h | 21 +++
From: Ilpo Järvinen
Whenever timestamp advances, it declares progress which
can be used by the other parts of the stack to decide that
the ACK is the most recent one seen so far.
AccECN will use this flag when deciding whether to use the
ACK to update AccECN state or not.
Signed-off-by: Ilpo Jä
From: Ilpo Järvinen
- Move tcp_count_delivered() earlier and split tcp_count_delivered_ce()
out of it
- Move tcp_in_ack_event() later
- While at it, remove the inline from tcp_in_ack_event() and let
the compiler to decide
Accurate ECN's heuristics does not know if there is going
to be ACE fi
From: Chia-Yu Chang
Hello,
Specific changes in v6 (27-Dec-2024)
- Avoid removing removing the potential CA_ACK_WIN_UPDATE in ack_ev_flags of
patch #1 (Eric Dumazet )
- Add reviewed-by tag in patches #2, #3, #4, #5, #6, #7, #8, #12, #14
- Foloiwng 2 new pathces are added after patch #9 (Patch
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
apply your virtio_transport_recv_pkt() patch *and* make
it impossible-by-design to switch ->transport from non-NULL to NULL in
vsock_assign_transport().
I don't know if that's enough, in this case the problem is that some
response packets are intended for a socket, where the transport has
c
virtio-vsock), it's also
>>>>> important that the transport is the same.
>>>>
>>>> My vote would be to apply your virtio_transport_recv_pkt() patch *and* make
>>>> it impossible-by-design to switch ->transport from non-NULL to NULL in
>>>> vsock_
est 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 same.
> &g
han 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 same.
>>
>> My vote would be to apply your virtio_transport_recv_pkt() patch *and* make
>> it impos
ause in some cases (like the one in virtio-vsock), it's also
> > important that the transport is the same.
>
> My vote would be to apply your virtio_transport_recv_pkt() patch *and* make
> it impossible-by-design to switch ->transport from non-NULL to NULL in
> vsock_assign_
that the transport is the same.
My vote would be to apply your virtio_transport_recv_pkt() patch *and* make
it impossible-by-design to switch ->transport from non-NULL to NULL in
vsock_assign_transport().
If I'm not mistaken, that would require rewriting vsock_assign_transport()
so that a ne
sed before lock_sock */
>>> - if (sock_flag(sk, SOCK_DONE)) {
>>> + /* Check if sk has been closed or assigned to another transport
before
>>> +* lock_sock
>>> +*/
>>> + if (sock_flag(sk, SOCK_DONE) || vsk->transport != &t->t
; +*/
> >>> + if (sock_flag(sk, SOCK_DONE) || vsk->transport != &t->transport) {
> >>>(void)virtio_transport_reset_no_sock(t, skb);
> >>>release_sock(sk);
> >>>sock_put(sk);
>
>
eck if sk has been closed or assigned to another transport
>>> before
>>> +* lock_sock
>>> +*/
>>> + if (sock_flag(sk, SOCK_DONE) || vsk->transport != &t->transport) {
>>>(void)virtio_transport_reset_no_sock(t, skb);
>
> > @@ -1628,8 +1628,10 @@ void virtio_transport_recv_pkt(struct
> > > > virtio_transport *t,
> > > >
> > > >lock_sock(sk);
> > > >
> > > > - /* Check if sk has been closed before lock_sock */
> > > > -
(void)virtio_transport_reset_no_sock(t, skb);
release_sock(sk);
sock_put(sk);
And separately, I think applying the vsock_stream_has_data patch would help
prevent potential issues that could arise when vsock_stream_has_data is
called somewhere.
Not sure, with t
_transport
*t,
lock_sock(sk);
- /* Check if sk has been closed before lock_sock */
- if (sock_flag(sk, SOCK_DONE)) {
+ /* Check if sk has been closed or assigned to another transport before
+* lock_sock
+*/
+ if (sock_flag(sk, SOCK_DONE) || vsk->
lock_sock(sk);
>
> - /* Check if sk has been closed before lock_sock */
> - if (sock_flag(sk, SOCK_DONE)) {
> + /* Check if sk has been closed or assigned to another transport before
> +* lock_sock
> +*/
> + if (sock_flag(sk,
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
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 occurs because vsk->transport was set
to NULL in vsock_deassign_tran
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
efano
Signed-off-by: Michal Luczaj
---
Changes in v2:
- Remove the refactoring patch from the series [Stefano]
- PATCH 2: Drop "virtio" from the commit title [Stefano]
- Collect Reviewed-by [Stefano]
- Link to v1:
https://lore.kernel.org/r/20241106-vsock-mem-leaks-v1-0-8f4ffc309...@rbox
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:
s in v2:
> - Remove the refactoring patch from the series [Stefano]
> - PATCH 2: Drop "virtio" from the commit title [Stefano]
> - Collect Reviewed-by [Stefano]
> - Link to v1:
> https://lore.kernel.org/r/20241106-vsock-mem-leaks-v1-0-8f4ffc309...@rbox.co
>
> [...]
H
This patch implement the logic of bind/unbind xsk pool to sq and rq.
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/net/virtio_net.c | 53
1 file changed, 53 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
The driver's tx napi is very important for XSK. It is responsible for
obtaining data from the XSK queue and sending it out.
At the beginning, we need to trigger tx napi.
virtnet_free_old_xmit distinguishes three type ptr(skb, xdp frame, xsk
buffer) by the last bits of the pointer.
Signed-off-by:
Since xsk's TX queue is consumed by TX NAPI, if sq is bound to xsk, then
we must stop tx napi from being disabled.
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/net/virtio_net.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/
Now, we support AF_XDP(xsk). Add NETDEV_XDP_ACT_XSK_ZEROCOPY to
xdp_features.
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/net/virtio_net.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 7db586770249..
virtio-net rq submits premapped per-buffer by setting sg page to NULL;
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/net/virtio_net.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
inde
If send queue sent some packets, we update the tx timeout
record to prevent the tx timeout.
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/net/virtio_net.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 57642bd83b7
To make the code readable, introduce vring_need_unmap_buffer() to
replace do_unmap.
use_dma_api premapped -> vring_need_unmap_buffer()
1. false falsefalse
2. truefalsetrue
3. truetrue false
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drive
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,
void *ctx,
The current configuration sets the virtqueue (vq) to premapped mode,
implying that all buffers submitted to this queue must be mapped ahead
of time. This presents a challenge for the virtnet send queue (sq): the
virtnet driver would be required to keep track of dma information for vq
size * 17, whi
Because the af-xdp will introduce a new xmit type, so I refactor the
xmit type mechanism first.
We know both xdp_frame and sk_buff are at least 4 bytes aligned.
For the xdp tx, we do not pass any pointer to virtio core as data,
we just need to pass the len of the packet. So we will push len
to the
2. fix the gcc error for commit #3
3. use virtqueue_dma_ for tx hdr
4. rename virtnet_ptr_to_xsk to virtnet_ptr_to_xsk_buff_len
5. squash #11 in last patch set to #10
## AF_XDP
XDP soc
Now, this API is useless. remove it.
Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
---
drivers/net/virtio_net.c | 13 --
drivers/virtio/virtio_ring.c | 48
include/linux/virtio.h | 2 --
3 files changed, 63 deletions(-)
diff --git a/drive
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
---
drivers/virtio/virtio_ring.c | 112 ---
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
---
drivers/virtio/virtio_ring.c | 60 +---
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
; I meant for hardening we need to check the flags stored in the extra
> > instead of the descriptor itself as it could be mangled by the device.
> >
> > Thanks
>
> Good point. Jason, want to cook up a patch?
Will do.
Thanks
>
> --
> MST
>
vsock_insert_connected() where it's
been open-coded.
No functional change intended.
Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
This is not a fix, so please remove the Fixes tag, we don't need to
backport this patch in stable branches.
Also in this case this is not relate
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
been open-coded.
>>
>> No functional change intended.
>>
>> Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
>
> This is not a fix, so please remove the Fixes tag, we don't need to
> backport this patch in stable branches.
>
> Also in this ca
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 refactoring patch from the series [Stefano]
- PATCH 2: Drop "virtio" from the commit title [Stefano]
- Collect Reviewed-by [
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
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 enqueued after the flush would remain unremoved, leading to a
memory
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 changed, 1 insertion(+)
diff --git a/net/vmw_vsock/virtio_tr
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):
comm "vsock_test", pid 1218, jiffies 4294694897
hex
quot;VSOCK: Introduce VM Sockets")
This is not a fix, so please remove the Fixes tag, we don't need to
backport this patch in stable branches.
Also in this case this is not related at all with virtio transport, so
please remove `virtio` from the commit title.
In addition maybe you can re
1 - 100 of 27710 matches
Mail list logo
