ect implementation should always be able to bind to
> an skb without prior ubuf_info, otherwise we could end up in a situation
> when the send would not be able to progress.
>
> Reviewed-by: Jens Axboe
> Reviewed-by: David Ahern
> Signed-off-by: Pavel Begunkov
Reviewed-by: Willem de Bruijn
() and also store
> ->sg_from_iter, which is currently passed in struct msghdr.
>
> Reviewed-by: Jens Axboe
> Reviewed-by: David Ahern
> Signed-off-by: Pavel Begunkov
Reviewed-by: Willem de Bruijn
Igor Raits wrote:
> Hello Willem,
>
> On Tue, Mar 19, 2024 at 2:08 PM Willem de Bruijn
> wrote:
> >
> > Igor Raits wrote:
> > > Hello,
> > >
> > > We have started to observe kernel crashes on 6.7.y kernels (atm we
> > > have h
Igor Raits wrote:
> Hello,
>
> We have started to observe kernel crashes on 6.7.y kernels (atm we
> have hit the issue 5 times on 6.7.5 and 6.7.10). On 6.6.9 where we
> have nodes of cluster it looks stable. Please see stacktrace below. If
> you need more information please let me know.
>
> We do
Heng Qi wrote:
>
>
> 在 2023/12/20 下午10:45, Willem de Bruijn 写道:
> > Heng Qi wrote:
> >> virtio-net has two ways to switch napi_tx: one is through the
> >> module parameter, and the other is through coalescing parameter
> >> settings (provided that the n
Heng Qi wrote:
> virtio-net has two ways to switch napi_tx: one is through the
> module parameter, and the other is through coalescing parameter
> settings (provided that the nic status is down).
>
> Sometimes we face performance regression caused by napi_tx,
> then we need to switch napi_tx when
> > >
> > >
> > > but even yours is also fixed I think.
> > >
> > > The common point is that a single spurious interrupt is not a problem.
> > > The problem only exists if there are tons of spurious interrupts with no
> > > real ones. For this to trigger, we keep polling the ring and while we do
>
On Tue, Apr 13, 2021 at 6:55 PM Xie He wrote:
>
> On Tue, Apr 13, 2021 at 1:51 PM Gong, Sishuai wrote:
> >
> > Hi,
> >
> > We found a data race in linux-5.12-rc3 between af_packet.c functions
> > fanout_demux_rollover() and __fanout_unlink() and we are able to reproduce
> > it under x86.
> >
>
does not do any
> other filtering and passes the packet to the designated socket.
>
> Pass incoming RFC 8335 ICMP Extended Echo Reply packets to the ping_rcv
> handler instead of discarding the packet.
>
> Signed-off-by: Andreas Roeseler
Acked-by: Willem de Bruijn
for future
On Tue, Apr 13, 2021 at 3:54 PM Michael S. Tsirkin wrote:
>
> On Tue, Apr 13, 2021 at 10:01:11AM -0400, Willem de Bruijn wrote:
> > On Tue, Apr 13, 2021 at 1:47 AM Michael S. Tsirkin wrote:
> > >
> > > virtio_disable_cb is currently a nop for split ring with event i
On Tue, Apr 13, 2021 at 1:06 AM Michael S. Tsirkin wrote:
>
> On Mon, Apr 24, 2017 at 01:49:30PM -0400, Willem de Bruijn wrote:
> > From: Willem de Bruijn
> >
> > Tx napi mode increases the rate of transmit interrupts. Suppress some
> > by masking interrupts while
On Tue, Apr 13, 2021 at 10:03 AM Michael S. Tsirkin wrote:
>
> On Tue, Apr 13, 2021 at 04:54:42PM +0800, Jason Wang wrote:
> >
> > 在 2021/4/13 下午1:47, Michael S. Tsirkin 写道:
> > > It's unsafe to operate a vq from multiple threads.
> > > Unfortunately this is exactly what we do when invoking
> > >
On Tue, Apr 13, 2021 at 4:53 AM Jason Wang wrote:
>
>
> 在 2021/4/13 下午1:47, Michael S. Tsirkin 写道:
> > There are currently two cases where we poll TX vq not in response to a
> > callback: start xmit and rx napi. We currently do this with callbacks
> > enabled which can cause extra interrupts from
On Tue, Apr 13, 2021 at 1:47 AM Michael S. Tsirkin wrote:
>
> virtio_disable_cb is currently a nop for split ring with event index.
> This is because it used to be always called from a callback when we know
> device won't trigger more events until we update the index. However,
> now that we run w
On Mon, Apr 12, 2021 at 3:41 PM Andreas Roeseler
wrote:
>
> On Mon, 2021-04-12 at 15:28 -0400, Willem de Bruijn wrote:
> > On Mon, Apr 12, 2021 at 3:09 PM Andreas Roeseler
> > wrote:
> > >
> > > The current icmp_rcv function drops all unknown ICMP types,
>
On Mon, Apr 12, 2021 at 3:09 PM Andreas Roeseler
wrote:
>
> The current icmp_rcv function drops all unknown ICMP types, including
> ICMP_EXT_ECHOREPLY (type 43). In order to parse Extended Echo Reply messages,
> we have
> to pass these packets to the ping_rcv function, which does not do any
> oth
On Sun, Apr 11, 2021 at 9:31 PM Hao Sun wrote:
>
> Hi
>
> When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz
> the Linux kernel, I found the following bug report, but I'm not sure
> about this.
> Sorry, I do not have a reproducing program for this bug.
> I hope that the stack t
es has also been
merged by now.
>
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Ron Bonica
> Sent: Monday, March 29, 2021 10:50 AM
> To: David Ahern ; Zachary Dodds ; Ishaan
> Gandhi
> Cc: Andreas Roeseler ; David Miller
> ; Networ
d range (Willem)
>
> Signed-off-by: Paolo Abeni
Acked-by: Willem de Bruijn
- even more verbose commit message and comments
>
> v1 -> v2:
> - restrict the csum update to the packets strictly needing them
> - hopefully clarify the commit message and code comments
>
> Signed-off-by: Paolo Abeni
Reviewed-by: Willem de Bruijn
let the UDP socket to accept any
> L4 aggregation and use it in the vxlan driver.
>
> v1 -> v2:
> - updated to use the newly introduced UDP socket 'accept*' fields
>
> Signed-off-by: Paolo Abeni
Reviewed-by: Willem de Bruijn
uot;udp: Support UDP fraglist GRO/GSO.")
> Signed-off-by: Paolo Abeni
Reviewed-by: Willem de Bruijn
On Mon, Mar 29, 2021 at 12:24 PM Paolo Abeni wrote:
>
> On Mon, 2021-03-29 at 11:24 -0400, Willem de Bruijn wrote:
> > On Mon, Mar 29, 2021 at 11:01 AM Paolo Abeni wrote:
> > > On Mon, 2021-03-29 at 09:52 -0400, Willem de Bruijn wrote:
> > > > > +
On Mon, Mar 29, 2021 at 2:34 PM Andreas Roeseler
wrote:
>
> On Sun, 2021-03-28 at 13:00 -0400, Willem de Bruijn wrote:
> > On Wed, Mar 24, 2021 at 2:20 PM Andreas Roeseler
> > wrote:
> > >
> >
> > > + if (!ext_hdr || !iio)
> > > +
On Mon, Mar 29, 2021 at 11:01 AM Paolo Abeni wrote:
>
> On Mon, 2021-03-29 at 09:52 -0400, Willem de Bruijn wrote:
> > > > That breaks the checksum-and-copy optimization when delivering to
> > > > local sockets. I wonder if that is a regression.
> > >
>
> > > > > Additionally the segmented packets UDP CB still refers to the original
> > > > > GSO packet len. Overall that causes unexpected/wrong csum validation
> > > > > errors later in the UDP receive path.
> > > > >
> > > > > We could possibly address the issue with some additional checks and
> >
On Mon, Mar 29, 2021 at 4:14 AM Paolo Abeni wrote:
>
> On Fri, 2021-03-26 at 14:15 -0400, Willem de Bruijn wrote:
> > On Thu, Mar 25, 2021 at 1:24 PM Paolo Abeni wrote:
> > > Currently the UDP protocol delivers GSO_FRAGLIST packets to
> > > the sockets wit
On Mon, Mar 29, 2021 at 7:26 AM Paolo Abeni wrote:
>
> On Fri, 2021-03-26 at 14:30 -0400, Willem de Bruijn wrote:
> > On Thu, Mar 25, 2021 at 1:24 PM Paolo Abeni wrote:
> > > When UDP packets generated locally by a socket with UDP_SEGMENT
> > > traverse the followin
On Wed, Mar 24, 2021 at 2:20 PM Andreas Roeseler
wrote:
>
> Modify the icmp_rcv function to check PROBE messages and call icmp_echo
> if a PROBE request is detected.
>
> Modify the existing icmp_echo function to respond ot both ping and PROBE
> requests.
>
> This was tested using a custom modifica
On Fri, Mar 26, 2021 at 11:49 AM Kurt Kanzenbach wrote:
>
> Reset MAC header in case of using packet_direct_xmit(), e.g. by specifying
> PACKET_QDISC_BYPASS. This is needed, because other code such as the HSR layer
> expects the MAC header to be correctly set.
>
> This has been observed using the
On Thu, Mar 25, 2021 at 1:24 PM Paolo Abeni wrote:
>
> When UDP packets generated locally by a socket with UDP_SEGMENT
> traverse the following path:
>
> UDP tunnel(xmit) -> veth (segmentation) -> veth (gro) ->
> UDP tunnel (rx) -> UDP socket (no UDP_GRO)
>
> they are segmented as part of
e and covering it would add
> quite a bit of complexity.
>
> v1 -> v2:
> - hopefully clarify the commit message
>
> Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
> Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO
> packets&q
On Thu, Mar 25, 2021 at 1:24 PM Paolo Abeni wrote:
>
> Currently the UDP protocol delivers GSO_FRAGLIST packets to
> the sockets without the expected segmentation.
>
> This change addresses the issue introducing and maintaining
> a couple of new fields to explicitly accept SKB_GSO_UDP_L4
> or GSO_
processing
> when while encap_mark == 1, identifying processing of the outer tunnel
> header.
> Additionally, clears the field in udp_gro_complete() so that we can enter
> the frag list path on the next round, for the inner header.
>
> v1 -> v2:
> - hopefully clarified the commit
On Thu, Mar 25, 2021 at 6:57 AM Paolo Abeni wrote:
>
> Hello,
>
> On Wed, 2021-03-24 at 18:36 -0400, Willem de Bruijn wrote:
> > > > This is a UDP GSO packet egress packet that was further encapsulated
> > > > with a GSO_UDP_TUNNEL on egress, then looped to th
On Wed, Mar 24, 2021 at 10:51 AM Paolo Abeni wrote:
>
> On Tue, 2021-03-23 at 21:54 -0400, Willem de Bruijn wrote:
> > > I did not look at that before your suggestion. Thanks for pointing out.
> > >
> > > I think the problem is specific to UDP: when processing t
> > This is a UDP GSO packet egress packet that was further encapsulated
> > with a GSO_UDP_TUNNEL on egress, then looped to the ingress path?
> >
> > Then in the ingress path it has traversed the GRO layer.
> >
> > Is this veth with XDP? That seems unlikely for GSO packets. But there
> > aren't ma
On Wed, Mar 24, 2021 at 3:00 PM Paolo Abeni wrote:
>
> On Tue, 2021-03-23 at 22:21 -0400, Willem de Bruijn wrote:
> > On Mon, Mar 22, 2021 at 1:12 PM Paolo Abeni wrote:
> > > On Mon, 2021-03-22 at 09:42 -0400, Willem de Bruijn wrote:
> > > > On Sun, Mar 21, 2
On Mon, Mar 22, 2021 at 1:12 PM Paolo Abeni wrote:
>
> On Mon, 2021-03-22 at 09:42 -0400, Willem de Bruijn wrote:
> > On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni wrote:
> > > Currently the UDP protocol delivers GSO_FRAGLIST packets to
> > > the sockets wit
On Mon, Mar 22, 2021 at 1:00 PM Paolo Abeni wrote:
>
> On Mon, 2021-03-22 at 09:30 -0400, Willem de Bruijn wrote:
> > On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni wrote:
> > > After the previous patch the stack can do L4 UDP aggregation
> > > on top of an UDP tunne
> > > and there are
> > > udp tunnel available in the system, we could end-up doing L4
> > > aggregation for packets targeting the UDP tunnel.
> >
> > Is this specific to UDP tunnels, or can this also occur with others,
> > such as GRE? (not implying that this patchset needs to address those
> > at
> > > > @@ -2168,6 +2168,7 @@ static int udp_queue_rcv_one_skb(struct sock *sk,
> > > > struct sk_buff *skb)
> > > > static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> > > > {
> > > > struct sk_buff *next, *segs;
> > > > + int csum_level;
> > > > int ret;
On Mon, Mar 22, 2021 at 12:36 PM Paolo Abeni wrote:
>
> On Mon, 2021-03-22 at 09:18 -0400, Willem de Bruijn wrote:
> > On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni wrote:
> > > When looping back UDP GSO over UDP tunnel packets to an UDP socket,
> > > the individual p
On Tue, Mar 23, 2021 at 12:30 PM Arnd Bergmann wrote:
>
> On Tue, Mar 23, 2021 at 3:42 PM Willem de Bruijn
> wrote:
> >
> > On Tue, Mar 23, 2021 at 8:52 AM Arnd Bergmann wrote:
> > >>
> > A similar fix already landed in 5.12-rc3: commit b228c9b05876 (&quo
On Tue, Mar 23, 2021 at 8:52 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> gcc-11 warns that the TS_SKB_CB(&state)) cast in skb_find_text()
> leads to an out-of-bounds access in skb_prepare_seq_read() after
> the addition of a new struct member made skb_seq_state longer
> than ts_state:
>
>
On Sun, Mar 21, 2021 at 1:02 PM Paolo Abeni wrote:
>
> create a bunch of virtual topology and verify that
> GRO_FRAG_LIST and GRO_FWD aggregate the ingress
what are these constants? Aliases for SKB_GSO_FRAGLIST and ?
> packets as expected, and the aggregate packets
> are segmented correctly when
On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni wrote:
>
> Currently the UDP protocol delivers GSO_FRAGLIST packets to
> the sockets without the expected segmentation.
>
> This change addresses the issue introducing and maintaining
> a per socket bitmask of GSO types requiring segmentation.
> Enabling
On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni wrote:
>
> After the previous patch the stack can do L4 UDP aggregation
> on top of an UDP tunnel.
>
> The current GRO complete code tries frag based aggregation first;
> in the above scenario will generate corrupted frames.
>
> We need to try first UDP
On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni wrote:
>
> If UDP GRO forwarding (or list) is enabled,
Please explicitly mention the gso type SKB_GSO_FRAGLIST. I, at least,
didn't immediately grasp that gro forwarding is an alias for that.
> and there are
> udp tunnel available in the system, we cou
On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni wrote:
>
> When looping back UDP GSO over UDP tunnel packets to an UDP socket,
> the individual packet csum is currently set to CSUM_NONE. That causes
> unexpected/wrong csum validation errors later in the UDP receive path.
>
> We could possibly addressi
On Fri, Mar 19, 2021 at 7:54 PM David Ahern wrote:
>
> On 3/19/21 10:11 AM, Ishaan Gandhi wrote:
> > Thank you. Would it be better to do instead:
> >
> > + if_index = skb->skb_iif;
> >
> > or
> >
> > + if_index = ip_version == 4 ? inet_iif(skb) : skb->skb_iif;
> >
>
> If the packet comes i
> + if (ip_version != 4 && ip_version != 6) {
> + pr_debug("ip_version must be 4 or 6\n");
> + return;
> + }
>
>
> always true
>
>
> I should remove this check, then?
>
> What is the standard way to differentiate IPV4 vs v6 paths in network code?
> Is there a
On Mon, Mar 15, 2021 at 3:10 PM Andreas Roeseler
wrote:
>
> On Mon, 2021-03-15 at 11:50 -0400, Willem de Bruijn wrote:
> > On Sun, Mar 14, 2021 at 12:50 PM Andreas Roeseler
> > wrote:
> > >
> > > Modify the icmp_rcv function to check PROBE messages and c
On Sat, Mar 13, 2021 at 1:35 AM ishaangandhi wrote:
>
> From: Ishaan Gandhi
>
> This patch identifies the interface a packet arrived on when sending
> ICMP time exceeded, destination unreachable, and parameter problem
> messages, in accordance with RFC 5837.
>
> It was tested by pinging a machine
On Sun, Mar 14, 2021 at 12:50 PM Andreas Roeseler
wrote:
>
> Modify the icmp_rcv function to check PROBE messages and call icmp_echo
> if a PROBE request is detected.
>
> Modify the existing icmp_echo function to respond ot both ping and PROBE
> requests.
>
> This was tested using a custom modific
On Thu, Mar 11, 2021 at 7:47 PM ishaangandhi wrote:
>
> From: Ishaan Gandhi
>
> This patch identifies the interface a packet arrived on when sending
> ICMP time exceeded, destination unreachable, and parameter problem
> messages, in accordance with RFC 5837.
>
> It was tested by pinging a machine
col set by virtio_net_hdr_set_proto. Note that since the protocol
> is only checked if skb->dev implements header_ops->parse_protocol,
> packets from devices without the implementation are not checked at this
> stage.
>
> Fixes: 9274124f023b ("net: stricter validation of u
> again call mpls_gso_segment with the same packet leading to an infinite
> loop. In addition, ensure that the header length is a multiple of four,
> which should hold irrespective of the number of stacked labels.
>
> Signed-off-by: Balazs Nemeth
Acked-by: Willem de Bruijn
The compiler will
On Tue, Mar 9, 2021 at 6:26 AM Michael S. Tsirkin wrote:
>
> On Mon, Mar 08, 2021 at 11:31:25AM +0100, Balazs Nemeth wrote:
> > For gso packets, virtio_net_hdr_set_proto sets the protocol (if it isn't
> > set) based on the type in the virtio net hdr, but the skb could contain
> > anything since it
On Mon, Mar 8, 2021 at 11:43 AM David Ahern wrote:
>
> On 3/8/21 9:26 AM, Balazs Nemeth wrote:
> > On Mon, 2021-03-08 at 09:17 -0700, David Ahern wrote:
> >> On 3/8/21 9:07 AM, Willem de Bruijn wrote:
> >>>> diff --git a/net/mpls/mpls_gso.c b/net/mpls/
On Mon, Mar 8, 2021 at 5:32 AM Balazs Nemeth wrote:
>
> A packet with skb_inner_network_header(skb) == skb_network_header(skb)
> and ETH_P_MPLS_UC will prevent mpls_gso_segment from pulling any headers
> from the packet. Subsequently, the call to skb_mac_gso_segment will
> again call mpls_gso_segm
On Mon, Mar 8, 2021 at 5:32 AM Balazs Nemeth wrote:
>
> For gso packets, virtio_net_hdr_set_proto sets the protocol (if it isn't
> set) based on the type in the virtio net hdr, but the skb could contain
> anything since it could come from packet_snd through a raw socket. If
> there is a mismatch b
On Fri, Mar 5, 2021 at 11:10 AM Daniel Borkmann wrote:
>
> On 3/5/21 4:08 PM, Willem de Bruijn wrote:
> > On Fri, Mar 5, 2021 at 7:34 AM Xuesen Huang wrote:
> >>
> >> From: Xuesen Huang
> >>
> >> Add BPF_F_ADJ_ROOM_ENCAP_L2_ETH flag to the existi
g
> Signed-off-by: Li Wang
> Signed-off-by: Willem de Bruijn
Please don't add my signed off by without asking.
That said,
Acked-by: Willem de Bruijn
g
> Signed-off-by: Li Wang
> Signed-off-by: Willem de Bruijn
Please mark patch target: [PATCH bpf-next]
> ---
> tools/testing/selftests/bpf/progs/test_tc_tunnel.c | 113
> ++---
> tools/testing/selftests/bpf/test_tc_tunnel.sh | 15 ++-
>
ncap L2 type and set the inner_protocol
> as ETH_P_TEB.
>
> Suggested-by: Willem de Bruijn
> Signed-off-by: Xuesen Huang
> Signed-off-by: Zhiyong Cheng
> Signed-off-by: Li Wang
Acked-by: Willem de Bruijn
> > Instead of untyped macros, I'd define encap_ipv4 as a function that
> > calls __encap_ipv4.
> >
> > And no need for encap_ipv4_with_ext_proto equivalent to __encap_ipv4.
> >
> I defined these macros to try to keep the existing invocation for
> encap_ipv4/6
> as the same, if we define this as
ncap L2 type and set the inner_protocol
> as ETH_P_TEB.
>
> Update test_tc_tunnel to verify adding vxlan encapsulation works with
> this flag.
>
> Suggested-by: Willem de Bruijn
> Signed-off-by: Xuesen Huang
> Signed-off-by: Zhiyong Cheng
> Signed-off-by: Li Wang
Than
From: Willem de Bruijn
The referenced commit expands the skb_seq_state used by
skb_find_text with a 4B frag_off field, growing it to 48B.
This exceeds container ts_state->cb, causing a stack corruption:
[ 73.238353] Kernel panic - not syncing: stack-protector: Kernel stack
is corrupted
STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 10.55.10.4 () port 0 AF_INET : demo
> Recv SendSend
> Socket Socket Message Elapsed
> Size SizeSize Time Throughput
> bytes bytes bytessecs.10^6bits/sec
>
>87380 16384 163842
in net/ rather than in drivers/net/.
>
> Cc: Florian Westphal
> Cc: Willem de Bruijn
> Cc: David S. Miller
> Cc: Hideaki YOSHIFUJI
> Cc: David Ahern
> Cc: Jakub Kicinski
> Cc: Steffen Klassert
> Fixes: 803381f9f117 ("Merge branch
> 'icmp-account-for-NAT-when-sending-icmps-from-ndo-layer'")
> Signed-off-by: Jason A. Donenfeld
Acked-by: Willem de Bruijn
On Fri, Feb 26, 2021 at 7:42 PM Jason A. Donenfeld wrote:
>
> On Sat, Feb 27, 2021 at 12:29 AM Willem de Bruijn
> wrote:
> >
> > On Fri, Feb 26, 2021 at 5:39 PM Jason A. Donenfeld wrote:
> > >
> > > On Fri, Feb 26, 2021 at 10:25 PM Willem de Bruijn
>
On Fri, Feb 26, 2021 at 5:39 PM Jason A. Donenfeld wrote:
>
> On Fri, Feb 26, 2021 at 10:25 PM Willem de Bruijn
> wrote:
> >
> > On Thu, Feb 25, 2021 at 6:46 PM Jason A. Donenfeld wrote:
> > >
> > > There were a few remaining tunnel drivers that didn'
On Fri, Feb 26, 2021 at 3:15 PM Cong Wang wrote:
>
> On Thu, Feb 25, 2021 at 7:59 PM Xuesen Huang wrote:
> > v3:
> > - Fix the code format.
> >
> > v2:
> > Suggested-by: Willem de Bruijn
> > - Add a new flag to specify the type of the inne
d opts from
> icmp{,v6}_ndo_send before sending") for details), there's even more
> imperative to have these all converted. So this commit goes through the
> remaining cases that I could find and does a boring translation to the
> ndo variety.
>
> Cc: Willem de Bruijn
> Signe
On Wed, Feb 24, 2021 at 6:21 PM Andreas Roeseler
wrote:
>
> On Sun, 2021-02-21 at 23:49 -0500, Willem de Bruijn wrote:
> On Wed, Feb 17, 2021 at 1:14 PM Andreas Roeseler
> wrote:
> >
> > Modify the icmp_rcv function to check for PROBE messages and call
> > i
On Tue, Feb 23, 2021 at 12:37 PM Wei Wang wrote:
>
> On Tue, Feb 23, 2021 at 6:26 AM Michael S. Tsirkin wrote:
> >
> > On Fri, Feb 19, 2021 at 05:44:34PM -0800, Wei Wang wrote:
> > > With the implementation of napi-tx in virtio driver, we clean tx
> > > descriptors from rx napi handler, for the p
On Mon, Feb 22, 2021 at 6:30 PM Gong, Sishuai wrote:
>
> Hello,
>
> We found a data race on dev->mtu between function __dev_set_mtu() and
> rawv6_send_hdrinc(). It happens with the following interleaving.
>
> writer: __dev_set_mtu()
>
On Tue, Feb 23, 2021 at 8:48 AM Balazs Nemeth wrote:
>
> On Mon, 2021-02-22 at 11:39 +0800, Jason Wang wrote:
> >
> > On 2021/2/19 10:55 下午, Willem de Bruijn wrote:
> > > On Fri, Feb 19, 2021 at 3:53 AM Jason Wang
> > > wrote:
> > > >
>
On Wed, Feb 17, 2021 at 1:14 PM Andreas Roeseler
wrote:
>
> Modify the icmp_rcv function to check for PROBE messages and call
> icmp_echo if a PROBE request is detected.
>
> Modify the existing icmp_echo function to respond to both ping and PROBE
> requests.
>
> This was tested using a custom modi
On Wed, Feb 17, 2021 at 1:10 PM Andreas Roeseler
wrote:
>
> Add definitions for PROBE ICMP types and codes.
>
> Add AFI definitions for IP and IPV6 as specified by IANA
>
> Add a struct to represent the additional header when probing by IP
> address (ctype == 3) for use in parsing incoming PROBE m
>
> This commit fixes the issue by passing an empty IPCB or IP6CB along to
> the functions that actually do the work. For the icmp_send, this was
> already trivial, thanks to __icmp_send providing the plumbing function.
> For icmpv6_send, this required a tiny bit of refactoring to mak
On Fri, Feb 19, 2021 at 3:53 AM Jason Wang wrote:
>
>
> On 2021/2/18 11:50 下午, Willem de Bruijn wrote:
> > On Thu, Feb 18, 2021 at 10:01 AM Balazs Nemeth wrote:
> >> For gso packets, virtio_net_hdr_set_proto sets the protocol (if it isn't
> >> set) based
p_send, this was
> already trivial, thanks to __icmp_send providing the plumbing function.
> For icmpv6_send, this required a tiny bit of refactoring to make it
> behave like the v4 case, after which it was straight forward.
>
> Fixes: a2b78e9b2cac ("sunvnet: generate ICMP P
On Thu, Feb 18, 2021 at 3:25 PM Jason A. Donenfeld wrote:
>
> On Thu, Feb 18, 2021 at 9:16 PM Willem de Bruijn
> wrote:
> >
> > On Thu, Feb 18, 2021 at 12:58 PM Jason A. Donenfeld wrote:
> > >
> > > On Thu, Feb 18, 2021 at 5:34 PM Willem de Bruijn
>
On Thu, Feb 18, 2021 at 12:58 PM Jason A. Donenfeld wrote:
>
> On Thu, Feb 18, 2021 at 5:34 PM Willem de Bruijn
> wrote:
> > Thanks for respinning.
> >
> > Making ipv4 and ipv6 more aligned is a good goal, but more for
> > net-next than bug fixes that nee
On Thu, Feb 18, 2021 at 10:40 AM Jason A. Donenfeld wrote:
>
> Hi Willem,
>
> On Thu, Feb 18, 2021 at 3:57 PM Willem de Bruijn
> wrote:
> >
> > On Thu, Feb 18, 2021 at 7:31 AM Jason A. Donenfeld wrote:
> > >
> > > The icmp{,v6}_send functio
refactoring to make it
> behave like the v4 case, after which it was straight forward.
>
> Fixes: a2b78e9b2cac ("sunvnet: generate ICMP PTMUD messages for smaller port
> MTUs")
> Reported-by: SinYu
> Cc: Willem de Bruijn
> Link:
> https://lore.kernel.org/net
On Thu, Feb 18, 2021 at 10:01 AM Balazs Nemeth wrote:
>
> For gso packets, virtio_net_hdr_set_proto sets the protocol (if it isn't
> set) based on the type in the virtio net hdr, but the skb could contain
> anything since it could come from packet_snd through a raw socket. If
> there is a mismatch
rt_xmit downstream from, e.g., segmentation
(SKB_GSO_CB). Which are fixed (all?) in commit 5146d1f15112
("tunnel: Clear IPCB(skb)->opt before dst_link_failure called").
Might be even better to do the memset in __icmp_send/icmp6_send,
rather than in the wrapper. What do you think?
&g
On Wed, Feb 17, 2021 at 6:18 PM Jason A. Donenfeld wrote:
>
> On 2/18/21, Willem de Bruijn wrote:
> > On Wed, Feb 17, 2021 at 5:56 PM Jason A. Donenfeld wrote:
> >>
> >> Hi Willem,
> >>
> >> On Wed, Feb 17, 2021 at 11:27 PM Willem de Bruijn
&
On Wed, Feb 17, 2021 at 5:56 PM Jason A. Donenfeld wrote:
>
> Hi Willem,
>
> On Wed, Feb 17, 2021 at 11:27 PM Willem de Bruijn
> wrote:
> > A vmlinux image might help. I couldn't find one for this kernel.
>
> https://data.zx2c4.com/icmp_send-crash-e03b4a42-70
On Wed, Feb 17, 2021 at 1:12 PM Jason A. Donenfeld wrote:
>
> Hi Netdev & Willem,
>
> I've received a report of stack corruption -- via the stack protector
> check -- in icmp_send. I was sent a vmcore, and was able to extract
> the OOPS from there. However, I've been unable to produce the bug and
ncap L2 type and set the inner_protocol
> as ETH_P_TEB.
>
> Suggested-by: Willem de Bruijn
> Signed-off-by: huangxuesen
> Signed-off-by: chengzhiyong
> Signed-off-by: wangli
Thanks, this is exactly what I meant.
Acked-by: Willem de Bruijn
One small point regarding Signed-off-by
On Tue, Feb 9, 2021 at 11:15 PM Jason Wang wrote:
>
>
> On 2021/2/10 上午10:36, Willem de Bruijn wrote:
> > On Tue, Feb 9, 2021 at 11:39 AM Michael S. Tsirkin wrote:
> >> On Tue, Feb 09, 2021 at 01:45:11PM +0800, Jason Wang wrote:
> >>> On 2021/2/9 上午2:55,
On Tue, Feb 9, 2021 at 11:39 AM Michael S. Tsirkin wrote:
>
> On Tue, Feb 09, 2021 at 01:45:11PM +0800, Jason Wang wrote:
> >
> > On 2021/2/9 上午2:55, Willem de Bruijn wrote:
> > > From: Willem de Bruijn
> > >
> > > Add optional PTP
> >>> I have no preference. Just curious, especially if it complicates the
> >>> patch.
> >>>
> >> My understanding is that. It's probably ok for net. But we probably need
> >> to document the assumptions to make sure it was not abused in other
> >> drivers.
> >>
> >> Introduce new parameters for
On Tue, Feb 9, 2021 at 4:43 AM Michael S. Tsirkin wrote:
>
> On Mon, Feb 08, 2021 at 01:55:57PM -0500, Willem de Bruijn wrote:
> > From: Willem de Bruijn
> >
> > Add optional PTP hardware tx timestamp offload for virtio-net.
> >
> > Accurate RTT measurement r
On Mon, Feb 8, 2021 at 11:13 PM Jason Wang wrote:
>
>
> On 2021/2/9 上午2:55, Willem de Bruijn wrote:
> > From: Willem de Bruijn
> >
> > Add optional PTP hardware rx timestamp offload for virtio-net.
> >
> > Accurate RTT measurement requires timestamps
ac header.
I would only not infer it based on some imprecise measure, such as
inner_maclen being 14. But add a new explicit flag
BPF_F_ADJ_ROOM_ENCAP_L2_ETH. Update inner protocol if the flag is
passed and inner_maclen >= ETH_HLEN. Fail the operation if the flag is
passed and inner_maclen is t
1 - 100 of 2027 matches
Mail list logo
