If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
From: "Michael S. Tsirkin" <mst@redhat.com> Date: 2025-08-12 10:15:56
On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in virtio_transport_send_pkt_info
OK so the issue triggers on
commit 6693731487a8145a9b039bc983d77edc47693855
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:16 2025 +0100
vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
but does not trigger on:
commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:15 2025 +0100
vsock/virtio: Rename virtio_vsock_skb_rx_put()
Will, I suspect your patch merely uncovers a latent bug
in zero copy handling elsewhere.
Want to take a look?
From: Will Deacon <will@kernel.org> Date: 2025-08-15 10:09:30
On Tue, Aug 12, 2025 at 06:15:46AM -0400, Michael S. Tsirkin wrote:
On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
quoted
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in virtio_transport_send_pkt_info
OK so the issue triggers on
commit 6693731487a8145a9b039bc983d77edc47693855
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:16 2025 +0100
vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
but does not trigger on:
commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:15 2025 +0100
vsock/virtio: Rename virtio_vsock_skb_rx_put()
Will, I suspect your patch merely uncovers a latent bug
in zero copy handling elsewhere.
Want to take a look?
Sorry for the delay, I was debugging something else!
I see Hillf already tried some stuff in the other thread, but I can take
a look as well.
Will
From: "Michael S. Tsirkin" <mst@redhat.com> Date: 2025-08-15 10:44:56
On Fri, Aug 15, 2025 at 11:09:24AM +0100, Will Deacon wrote:
On Tue, Aug 12, 2025 at 06:15:46AM -0400, Michael S. Tsirkin wrote:
quoted
On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
quoted
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in virtio_transport_send_pkt_info
OK so the issue triggers on
commit 6693731487a8145a9b039bc983d77edc47693855
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:16 2025 +0100
vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
but does not trigger on:
commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:15 2025 +0100
vsock/virtio: Rename virtio_vsock_skb_rx_put()
Will, I suspect your patch merely uncovers a latent bug
in zero copy handling elsewhere.
Want to take a look?
Sorry for the delay, I was debugging something else!
I see Hillf already tried some stuff in the other thread, but I can take
a look as well.
Will
I will be frank I don't understand how that patch makes sense though.
--
MST
From: Will Deacon <will@kernel.org> Date: 2025-08-15 12:01:05
On Fri, Aug 15, 2025 at 06:44:47AM -0400, Michael S. Tsirkin wrote:
On Fri, Aug 15, 2025 at 11:09:24AM +0100, Will Deacon wrote:
quoted
On Tue, Aug 12, 2025 at 06:15:46AM -0400, Michael S. Tsirkin wrote:
quoted
On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
quoted
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in virtio_transport_send_pkt_info
OK so the issue triggers on
commit 6693731487a8145a9b039bc983d77edc47693855
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:16 2025 +0100
vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
but does not trigger on:
commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:15 2025 +0100
vsock/virtio: Rename virtio_vsock_skb_rx_put()
Will, I suspect your patch merely uncovers a latent bug
in zero copy handling elsewhere.
I'm still looking at this, but I'm not sure zero-copy is the right place
to focus on.
The bisected patch 6693731487a8 ("vsock/virtio: Allocate nonlinear SKBs
for handling large transmit buffers") only has two hunks. The first is
for the non-zcopy case and the latter is a no-op for zcopy, as
skb_len == VIRTIO_VSOCK_SKB_HEADROOM and so we end up with a linear SKB
regardless.
I'll keep digging...
Will
From: Will Deacon <will@kernel.org> Date: 2025-08-15 15:48:06
On Fri, Aug 15, 2025 at 01:00:59PM +0100, Will Deacon wrote:
On Fri, Aug 15, 2025 at 06:44:47AM -0400, Michael S. Tsirkin wrote:
quoted
On Fri, Aug 15, 2025 at 11:09:24AM +0100, Will Deacon wrote:
quoted
On Tue, Aug 12, 2025 at 06:15:46AM -0400, Michael S. Tsirkin wrote:
quoted
On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
quoted
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in virtio_transport_send_pkt_info
OK so the issue triggers on
commit 6693731487a8145a9b039bc983d77edc47693855
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:16 2025 +0100
vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
but does not trigger on:
commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:15 2025 +0100
vsock/virtio: Rename virtio_vsock_skb_rx_put()
Will, I suspect your patch merely uncovers a latent bug
in zero copy handling elsewhere.
I'm still looking at this, but I'm not sure zero-copy is the right place
to focus on.
The bisected patch 6693731487a8 ("vsock/virtio: Allocate nonlinear SKBs
for handling large transmit buffers") only has two hunks. The first is
for the non-zcopy case and the latter is a no-op for zcopy, as
skb_len == VIRTIO_VSOCK_SKB_HEADROOM and so we end up with a linear SKB
regardless.
It's looking like this is caused by moving from memcpy_from_msg() to
skb_copy_datagram_from_iter(), which is necessary to handle non-linear
SKBs correctly.
In the case of failure (i.e. faulting on the source and returning
-EFAULT), memcpy_from_msg() rewinds the message iterator whereas
skb_copy_datagram_from_iter() does not. If we have previously managed to
transmit some of the packet, then I think
virtio_transport_send_pkt_info() can end up returning a positive "bytes
written" error code and the caller will call it again. If we've advanced
the message iterator, then this can end up with the reported warning if
we run out of input data.
As a hack (see below), I tried rewinding the iterator in the error path
of skb_copy_datagram_from_iter() but I'm not sure whether other callers
would be happy with that. If not, then we could save/restore the
iterator state in virtio_transport_fill_skb() if the copy fails. Or we
could add a variant of skb_copy_datagram_from_iter(), say
skb_copy_datagram_from_iter_full(), which has the rewind behaviour.
What do you think?
Will
--->8
@@ -551,7 +551,7 @@ int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,intlen){intstart=skb_headlen(skb);-inti,copy=start-offset;+inti,copy=start-offset,start_off=offset;structsk_buff*frag_iter;/* Copy header. */
@@ -614,6 +614,7 @@ int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,return0;fault:+iov_iter_revert(from,offset-start_off);return-EFAULT;}EXPORT_SYMBOL(skb_copy_datagram_from_iter);
On Fri, 15 Aug 2025 16:48:00 +0100 Will Deacon wrote:
On Fri, Aug 15, 2025 at 01:00:59PM +0100, Will Deacon wrote:
quoted
On Fri, Aug 15, 2025 at 06:44:47AM -0400, Michael S. Tsirkin wrote:
quoted
On Fri, Aug 15, 2025 at 11:09:24AM +0100, Will Deacon wrote:
quoted
On Tue, Aug 12, 2025 at 06:15:46AM -0400, Michael S. Tsirkin wrote:
quoted
On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
quoted
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in virtio_transport_send_pkt_info
OK so the issue triggers on
commit 6693731487a8145a9b039bc983d77edc47693855
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:16 2025 +0100
vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
but does not trigger on:
commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:15 2025 +0100
vsock/virtio: Rename virtio_vsock_skb_rx_put()
Will, I suspect your patch merely uncovers a latent bug
in zero copy handling elsewhere.
I'm still looking at this, but I'm not sure zero-copy is the right place
to focus on.
The bisected patch 6693731487a8 ("vsock/virtio: Allocate nonlinear SKBs
for handling large transmit buffers") only has two hunks. The first is
for the non-zcopy case and the latter is a no-op for zcopy, as
skb_len == VIRTIO_VSOCK_SKB_HEADROOM and so we end up with a linear SKB
regardless.
It's looking like this is caused by moving from memcpy_from_msg() to
skb_copy_datagram_from_iter(), which is necessary to handle non-linear
SKBs correctly.
In the case of failure (i.e. faulting on the source and returning
-EFAULT), memcpy_from_msg() rewinds the message iterator whereas
skb_copy_datagram_from_iter() does not. If we have previously managed to
transmit some of the packet, then I think
virtio_transport_send_pkt_info() can end up returning a positive "bytes
written" error code and the caller will call it again. If we've advanced
the message iterator, then this can end up with the reported warning if
we run out of input data.
As a hack (see below), I tried rewinding the iterator in the error path
of skb_copy_datagram_from_iter() but I'm not sure whether other callers
would be happy with that. If not, then we could save/restore the
iterator state in virtio_transport_fill_skb() if the copy fails. Or we
could add a variant of skb_copy_datagram_from_iter(), say
skb_copy_datagram_from_iter_full(), which has the rewind behaviour.
What do you think?
Will
--->8
@@ -551,7 +551,7 @@ int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,intlen){intstart=skb_headlen(skb);-inti,copy=start-offset;+inti,copy=start-offset,start_off=offset;structsk_buff*frag_iter;/* Copy header. */
@@ -614,6 +614,7 @@ int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,return0;fault:+iov_iter_revert(from,offset-start_off);return-EFAULT;}EXPORT_SYMBOL(skb_copy_datagram_from_iter);--
From: "Michael S. Tsirkin" <mst@redhat.com> Date: 2025-08-16 10:34:38
On Fri, Aug 15, 2025 at 04:48:00PM +0100, Will Deacon wrote:
On Fri, Aug 15, 2025 at 01:00:59PM +0100, Will Deacon wrote:
quoted
On Fri, Aug 15, 2025 at 06:44:47AM -0400, Michael S. Tsirkin wrote:
quoted
On Fri, Aug 15, 2025 at 11:09:24AM +0100, Will Deacon wrote:
quoted
On Tue, Aug 12, 2025 at 06:15:46AM -0400, Michael S. Tsirkin wrote:
quoted
On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
quoted
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in virtio_transport_send_pkt_info
OK so the issue triggers on
commit 6693731487a8145a9b039bc983d77edc47693855
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:16 2025 +0100
vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
but does not trigger on:
commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:15 2025 +0100
vsock/virtio: Rename virtio_vsock_skb_rx_put()
Will, I suspect your patch merely uncovers a latent bug
in zero copy handling elsewhere.
I'm still looking at this, but I'm not sure zero-copy is the right place
to focus on.
The bisected patch 6693731487a8 ("vsock/virtio: Allocate nonlinear SKBs
for handling large transmit buffers") only has two hunks. The first is
for the non-zcopy case and the latter is a no-op for zcopy, as
skb_len == VIRTIO_VSOCK_SKB_HEADROOM and so we end up with a linear SKB
regardless.
It's looking like this is caused by moving from memcpy_from_msg() to
skb_copy_datagram_from_iter(), which is necessary to handle non-linear
SKBs correctly.
In the case of failure (i.e. faulting on the source and returning
-EFAULT), memcpy_from_msg() rewinds the message iterator whereas
skb_copy_datagram_from_iter() does not. If we have previously managed to
transmit some of the packet, then I think
virtio_transport_send_pkt_info() can end up returning a positive "bytes
written" error code and the caller will call it again. If we've advanced
the message iterator, then this can end up with the reported warning if
we run out of input data.
As a hack (see below), I tried rewinding the iterator in the error path
of skb_copy_datagram_from_iter() but I'm not sure whether other callers
would be happy with that. If not, then we could save/restore the
iterator state in virtio_transport_fill_skb() if the copy fails. Or we
could add a variant of skb_copy_datagram_from_iter(), say
skb_copy_datagram_from_iter_full(), which has the rewind behaviour.
What do you think?
Will
It is, at least, self-contained. I don't much like hacking around
it in virtio_transport_fill_skb. If your patch isn't acceptable,
skb_copy_datagram_from_iter_full seem like a better approach, I think.
@@ -551,7 +551,7 @@ int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,intlen){intstart=skb_headlen(skb);-inti,copy=start-offset;+inti,copy=start-offset,start_off=offset;structsk_buff*frag_iter;/* Copy header. */
@@ -614,6 +614,7 @@ int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,return0;fault:+iov_iter_revert(from,offset-start_off);return-EFAULT;}EXPORT_SYMBOL(skb_copy_datagram_from_iter);
From: Will Deacon <will@kernel.org> Date: 2025-08-18 14:52:54
On Sat, Aug 16, 2025 at 06:34:29AM -0400, Michael S. Tsirkin wrote:
On Fri, Aug 15, 2025 at 04:48:00PM +0100, Will Deacon wrote:
quoted
On Fri, Aug 15, 2025 at 01:00:59PM +0100, Will Deacon wrote:
quoted
On Fri, Aug 15, 2025 at 06:44:47AM -0400, Michael S. Tsirkin wrote:
quoted
On Fri, Aug 15, 2025 at 11:09:24AM +0100, Will Deacon wrote:
quoted
On Tue, Aug 12, 2025 at 06:15:46AM -0400, Michael S. Tsirkin wrote:
quoted
On Tue, Aug 12, 2025 at 03:03:02AM -0700, syzbot wrote:
quoted
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in virtio_transport_send_pkt_info
OK so the issue triggers on
commit 6693731487a8145a9b039bc983d77edc47693855
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:16 2025 +0100
vsock/virtio: Allocate nonlinear SKBs for handling large transmit buffers
but does not trigger on:
commit 8ca76151d2c8219edea82f1925a2a25907ff6a9d
Author: Will Deacon [off-list ref]
Date: Thu Jul 17 10:01:15 2025 +0100
vsock/virtio: Rename virtio_vsock_skb_rx_put()
Will, I suspect your patch merely uncovers a latent bug
in zero copy handling elsewhere.
I'm still looking at this, but I'm not sure zero-copy is the right place
to focus on.
The bisected patch 6693731487a8 ("vsock/virtio: Allocate nonlinear SKBs
for handling large transmit buffers") only has two hunks. The first is
for the non-zcopy case and the latter is a no-op for zcopy, as
skb_len == VIRTIO_VSOCK_SKB_HEADROOM and so we end up with a linear SKB
regardless.
It's looking like this is caused by moving from memcpy_from_msg() to
skb_copy_datagram_from_iter(), which is necessary to handle non-linear
SKBs correctly.
In the case of failure (i.e. faulting on the source and returning
-EFAULT), memcpy_from_msg() rewinds the message iterator whereas
skb_copy_datagram_from_iter() does not. If we have previously managed to
transmit some of the packet, then I think
virtio_transport_send_pkt_info() can end up returning a positive "bytes
written" error code and the caller will call it again. If we've advanced
the message iterator, then this can end up with the reported warning if
we run out of input data.
As a hack (see below), I tried rewinding the iterator in the error path
of skb_copy_datagram_from_iter() but I'm not sure whether other callers
would be happy with that. If not, then we could save/restore the
iterator state in virtio_transport_fill_skb() if the copy fails. Or we
could add a variant of skb_copy_datagram_from_iter(), say
skb_copy_datagram_from_iter_full(), which has the rewind behaviour.
What do you think?
Will
It is, at least, self-contained. I don't much like hacking around
it in virtio_transport_fill_skb. If your patch isn't acceptable,
skb_copy_datagram_from_iter_full seem like a better approach, I think.
Thanks. I'll send something out shortly with you on cc.
Will