t the
> > sock object retains the dangling sk pointer, which may cause use-after-free
> > later.
> >
> > Clear the sock sk pointer on error.
> >
> > Signed-off-by: Ignat Korchagin
>
> Reviewed-by: Kuniyuki Iwashima
Reviewed-by: Eric Dumazet
Iwashima
> > Signed-off-by: Ignat Korchagin
>
> Reviewed-by: Kuniyuki Iwashima
Reviewed-by: Eric Dumazet
gt; > Put a warning in place to make sure we don't break this promise in the
> > future.
> >
> > Suggested-by: Kuniyuki Iwashima
> > Signed-off-by: Ignat Korchagin
>
> Reviewed-by: Kuniyuki Iwashima
Reviewed-by: Eric Dumazet
t; > sock object retains the dangling pointer, which may create use-after-free
> > later.
> >
> > Clear the sk pointer in the sock object on error.
> >
> > Signed-off-by: Ignat Korchagin
>
> Reviewed-by: Kuniyuki Iwashima
Reviewed-by: Eric Dumazet
is
> > freed, but the dangling pointer remains in the provided sock object, which
> > may allow use-after-free.
> >
> > Clear the sk pointer in the sock object on error.
> >
> > Signed-off-by: Ignat Korchagin
> > Reviewed-by: Miquel Raynal
>
> Reviewed-by: Kuniyuki Iwashima
Reviewed-by: Eric Dumazet
> > dangling pointer in the sock object, which may cause use-after-free.
> >
> > Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().
> >
> > Signed-off-by: Ignat Korchagin
>
> Reviewed-by: Kuniyuki Iwashima
Reviewed-by: Eric Dumazet
> > dangling pointer is still attached to the sock object, which may create
> > use-after-free in other code.
> >
> > Signed-off-by: Ignat Korchagin
>
> Reviewed-by: Kuniyuki Iwashima
>
> Checked all bt_sock_alloc() paths and confirmed only rfcomm and l2cap
> need changes.
Reviewed-by: Eric Dumazet
gt; to use this pointer and cause use-after-free.
>
> Suggested-by: Eric Dumazet
> Signed-off-by: Ignat Korchagin
> ---
Reviewed-by: Eric Dumazet
Thanks.
On Wed, Oct 9, 2024 at 2:17 PM Menglong Dong wrote:
>
> In this commit, we introduce a new tracepoint "skb_latency", which is
> used to trace the latency on sending or receiving packet. For now, only
> TCP is supported. Maybe we should call it "tcp_latency"?
>
> There are 6 stages are introduced i
On Tue, Sep 24, 2024 at 3:33 PM Stephen Hemminger
wrote:
>
> On Tue, 24 Sep 2024 17:09:06 +0800
> yushengjin wrote:
>
> > When conducting WRK testing, the CPU usage rate of the testing machine was
> > 100%. forwarding through a bridge, if the network load is too high, it may
> > cause abnormal lo
On Mon, Sep 23, 2024 at 12:06 PM yushengjin wrote:
>
>
> 在 23/9/2024 下午5:29, Eric Dumazet 写道:
> > On Mon, Sep 23, 2024 at 11:16 AM yushengjin
> > wrote:
> >> When conducting WRK testing, the CPU usage rate of the testing machine was
> >> 100%. forwarding t
On Mon, Sep 23, 2024 at 11:16 AM yushengjin wrote:
>
> When conducting WRK testing, the CPU usage rate of the testing machine was
> 100%. forwarding through a bridge, if the network load is too high, it may
> cause abnormal load on the ebt_do_table of the kernel ebtable module, leading
> to excess
is ipv6_mapped and
> use ip_queue_xmit, inet_sk(sk)->tos.
>
> Bpf_get/setsockopt use sk_is_inet() helper to fix this case.
>
> Signed-off-by: Feng Zhou
Reviewed-by: Eric Dumazet
On Fri, Sep 13, 2024 at 11:39 AM Tiago Lam wrote:
>
> This follows the same rationale provided for the ipv4 counterpart, where
> it now runs a reverse socket lookup when source addresses and/or ports
> are changed, on sendmsg, to check whether egress traffic should be
> allowed to go through or no
On Mon, Sep 9, 2024 at 5:02 PM Sean Anderson wrote:
>
> On 9/6/24 22:05, Willem de Bruijn wrote:
> > Sean Anderson wrote:
> >> Padding is not included in UDP and TCP checksums. Therefore, reduce the
> >> length of the checksummed data to include only the data in the IP
> >> payload. This fixes spu
On Wed, Sep 4, 2024 at 5:18 PM Mina Almasry wrote:
>
> On Tue, Sep 3, 2024 at 2:40 PM Jakub Kicinski wrote:
> >
> > On Sat, 31 Aug 2024 00:43:08 + Mina Almasry wrote:
> > > static inline bool tcp_skb_can_collapse_to(const struct sk_buff *skb)
> > > {
> > > - return likely(!TCP_SKB_CB(sk
On Wed, Sep 4, 2024 at 5:18 PM Mina Almasry wrote:
>
> On Tue, Sep 3, 2024 at 2:40 PM Jakub Kicinski wrote:
> >
> > On Sat, 31 Aug 2024 00:43:08 + Mina Almasry wrote:
> > > static inline bool tcp_skb_can_collapse_to(const struct sk_buff *skb)
> > > {
> > > - return likely(!TCP_SKB_CB(sk
firmed via email that these were
> intended to be run.
>
> Enable these two tests.
>
> Fixes: 13715acf8ab5 ("selftest: Add test for bind() conflicts.")
> Fixes: 2c042e8e54ef ("tcp: Add selftest for bind() and TIME_WAIT.")
> Signed-off-by: Jamie Bainbridge
Reviewed-by: Eric Dumazet
t; Reviewed-by: David Gibson
> Reviewed-by: Stefano Brivio
> Tested-by: Stefano Brivio
> Signed-off-by: Jon Maloy
Reviewed-by: Eric Dumazet
Thanks.
et: introduce a config option to tweak MAX_SKB_FRAGS")
> Reported-by: Jan Tluka
> Reported-by: Jirka Hladky
> Reported-by: Sabrina Dubroca
> Tested-by: Sabrina Dubroca
> Tested-by: Corinna Vinschen
> Signed-off-by: Paolo Abeni
Reviewed-by: Eric Dumazet
; >
> > Subject: [PATCH net-next v2] tcp: ...
> >
> > That notwithstanding, this looks good to me.
> >
> > Reviewed-by: Simon Horman
>
> @Eric: I can fix the prefix when applying the patch. Please LMK if you
> prefer otherwise.
Sure thing, thanks for taking care of this Paolo, Simon, and Kees.
Reviewed-by: Eric Dumazet
a pointer, the size can't be
> trivially determined by the compiler. ca->name is the same length,
> so strscpy() won't fail (when ca->name is NUL-terminated). Include the
> length explicitly instead of using the 2-argument strscpy().
>
> Link: https://github.com/KSPP/linux
On Thu, Jul 11, 2024 at 5:54 AM Alexander Lobakin
wrote:
>
> From: Eric Dumazet
> Date: Wed, 10 Jul 2024 10:04:39 -0700
>
> > This is because of the ‘const’ qualifier of the parameter.
> >
> > This could be solved with _Generic() later, if we want to keep the
&g
On Wed, Jul 10, 2024 at 4:19 AM Breno Leitao wrote:
>
> Hello Eric,
>
> On Tue, Jul 09, 2024 at 08:27:45AM -0700, Eric Dumazet wrote:
> > On Tue, Jul 9, 2024 at 5:54 AM Breno Leitao wrote:
>
> > > @@ -2596,7 +2599,7 @@ void dev_net_set(struct net_devic
riv_len);
> +} cacheline_aligned;
> #define to_net_dev(d) container_of(d, struct net_device, dev)
>
> /*
> @@ -2596,7 +2599,7 @@ void dev_net_set(struct net_device *dev, struct net
> *net)
> */
> static inline void *netdev_priv(const struct net_device *dev)
> {
> - return (char *)dev + ALIGN(sizeof(struct net_device), NETDEV_ALIGN);
> + return (void *)dev->priv;
Minor remark : the cast is not needed, but this is fine.
Reviewed-by: Eric Dumazet
It would be great to get rid of NETDEV_ALIGN eventually.
Thanks.
ol != IPPROTO_TCP)
> + return -EBADF;
This might use sk_is_tcp() helper.
> +
> + if (optlen % sizeof(struct dmabuf_token) ||
> + optlen > sizeof(*tokens) * 128)
> + return -EINVAL;
> +
> + tokens = kvmalloc_array(128, sizeof(*tokens), GFP_KERNEL);
This allocates 8192 bytes even for small optlen ?
Probably no big deal, no need to send a new version.
Reviewed-by: Eric Dumazet
ol != IPPROTO_TCP)
> + return -EBADF;
This might use sk_is_tcp() helper.
> +
> + if (optlen % sizeof(struct dmabuf_token) ||
> + optlen > sizeof(*tokens) * 128)
> + return -EINVAL;
> +
> + tokens = kvmalloc_array(128, sizeof(*tokens), GFP_KERNEL);
This allocates 8192 bytes even for small optlen ?
Probably no big deal, no need to send a new version.
Reviewed-by: Eric Dumazet
g this page. All pages are released when the socket is
> destroyed.
>
> Signed-off-by: Willem de Bruijn
> Signed-off-by: Kaiyuan Zhang
> Signed-off-by: Mina Almasry
Reviewed-by: Eric Dumazet
g this page. All pages are released when the socket is
> destroyed.
>
> Signed-off-by: Willem de Bruijn
> Signed-off-by: Kaiyuan Zhang
> Signed-off-by: Mina Almasry
Reviewed-by: Eric Dumazet
b1->unreadable = skb->unreadable;
> skb_shinfo(skb)->nr_frags = 0;
> skb1->data_len = skb->data_len;
> skb1->len += skb1->data_len;
> @@ -4071,6 +4099,7 @@ static inline void skb_split_no_header(struct sk_buff
> *skb,
> {
> int i, k = 0;
> const int nfrags = skb_shinfo(skb)->nr_frags;
> + const int unreadable = skb->unreadable;
>
> skb_shinfo(skb)->nr_frags = 0;
> skb1->len = skb1->data_len = skb->len - len;
> @@ -4104,6 +4133,12 @@ static inline void skb_split_no_header(struct sk_buff
> *skb,
> pos += size;
> }
> skb_shinfo(skb1)->nr_frags = k;
> +
Minor point : skb->unreadable can be left as is ?
> + if (skb_shinfo(skb)->nr_frags)
> + skb->unreadable = unreadable;
Minor point : skb_shinfo(skb1)->nr_frags can't be zero at this point.
> +
> + if (skb_shinfo(skb1)->nr_frags)
> + skb1->unreadable = unreadable;
> }
This means we probably could remove the unreadable variable and
skb1->unreadable = skb->unreadable;
No need to send a new version, this can be incrementally changed later.
Reviewed-by: Eric Dumazet
b1->unreadable = skb->unreadable;
> skb_shinfo(skb)->nr_frags = 0;
> skb1->data_len = skb->data_len;
> skb1->len += skb1->data_len;
> @@ -4071,6 +4099,7 @@ static inline void skb_split_no_header(struct sk_buff
> *skb,
> {
> int i, k = 0;
> const int nfrags = skb_shinfo(skb)->nr_frags;
> + const int unreadable = skb->unreadable;
>
> skb_shinfo(skb)->nr_frags = 0;
> skb1->len = skb1->data_len = skb->len - len;
> @@ -4104,6 +4133,12 @@ static inline void skb_split_no_header(struct sk_buff
> *skb,
> pos += size;
> }
> skb_shinfo(skb1)->nr_frags = k;
> +
Minor point : skb->unreadable can be left as is ?
> + if (skb_shinfo(skb)->nr_frags)
> + skb->unreadable = unreadable;
Minor point : skb_shinfo(skb1)->nr_frags can't be zero at this point.
> +
> + if (skb_shinfo(skb1)->nr_frags)
> + skb1->unreadable = unreadable;
> }
This means we probably could remove the unreadable variable and
skb1->unreadable = skb->unreadable;
No need to send a new version, this can be incrementally changed later.
Reviewed-by: Eric Dumazet
On Fri, Jun 28, 2024 at 2:33 AM Mina Almasry wrote:
>
> Make skb_frag_page() fail in the case where the frag is not backed
> by a page, and fix its relevant callers to handle this case.
>
> Signed-off-by: Mina Almasry
>
Reviewed-by: Eric Dumazet
On Fri, Jun 28, 2024 at 2:33 AM Mina Almasry wrote:
>
> Make skb_frag_page() fail in the case where the frag is not backed
> by a page, and fix its relevant callers to handle this case.
>
> Signed-off-by: Mina Almasry
>
Reviewed-by: Eric Dumazet
On Tue, Jun 25, 2024 at 10:25 AM Geliang Tang wrote:
>
> From: Geliang Tang
>
> Run the following BPF selftests on Loongarch:
>
> ./test_progs -t sockmap_basic
>
> A Kernel panic occurs:
>
> '''
> Oops[#1]:
> CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+
> #18
>
On Tue, Jun 25, 2024 at 10:25 AM Geliang Tang wrote:
>
> From: Geliang Tang
>
> Run the following BPF selftests on Loongarch:
>
> ./test_progs -t sockmap_listen
>
> A Kernel panic occurs:
>
> '''
> Oops[#1]:
> CPU: 49 PID: 233429 Comm: new_name Tainted: G OE 6.10.0-rc2+
> #20
>
On Mon, Jun 24, 2024 at 3:28 PM Geliang Tang wrote:
>
> From: Geliang Tang
>
> Run the following BPF selftests on loongarch:
>
> # ./test_progs -t sockmap_basic
>
> A Kernel panic occurs:
>
> '''
> Oops[#1]:
> CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+
> #18
>
On Mon, Jun 24, 2024 at 3:28 PM Geliang Tang wrote:
>
> From: Geliang Tang
>
> Run the following BPF selftests on loongarch:
>
> # ./test_progs -t sockmap_listen
>
> A Kernel panic occurs:
>
> '''
> Oops[#1]:
> CPU: 49 PID: 233429 Comm: new_name Tainted: G OE 6.10.0-rc2+
> #20
>
On Thu, Jun 6, 2024 at 4:14 PM Denis Arefev wrote:
>
> Two missing check in virtio_net_hdr_to_skb() allowed syzbot
> to crash kernels again
>
> 1. After the skb_segment function the buffer may become non-linear
> (nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere
> the __skb
t;
> While at it, unexport and make static tcp_inbound_ao_hash().
>
> Signed-off-by: Dmitry Safonov <0x7f454...@gmail.com>
Reviewed-by: Eric Dumazet
On Thu, Jun 6, 2024 at 2:58 AM Dmitry Safonov via B4 Relay
wrote:
>
> From: Dmitry Safonov <0x7f454...@gmail.com>
>
> It's going to be used more in TCP-AO tracepoints.
>
> Signed-off-by: Dmitry Safonov <0x7f454...@gmail.com>
Reviewed-by: Eric Dumazet
On Wed, Jun 5, 2024 at 7:35 PM Dmitry Safonov <0x7f454...@gmail.com> wrote:
>
> Hi Eric,
>
> Thanks for the review,
>
> On Wed, 5 Jun 2024 at 09:07, Eric Dumazet wrote:
> >
> > On Wed, Jun 5, 2024 at 4:20 AM Dmitry Safonov via B4 Relay
> > wrote:
ed and provide filtering.
>
> This potentially may create a regression if a userspace depends on dmesg
> logs. Fingers crossed, let's see if anyone complains in reality.
>
> Signed-off-by: Dmitry Safonov <0x7f454...@gmail.com>
Reviewed-by: Eric Dumazet
On Wed, Jun 5, 2024 at 4:20 AM Dmitry Safonov via B4 Relay
wrote:
>
> From: Dmitry Safonov <0x7f454...@gmail.com>
>
> Two reasons:
> 1. It's grown up enough
> 2. In order to not do header spaghetti by including
>, which is necessary for TCP tracepoints.
>
> Signed-off-by: Dmitry Safonov <0x7f4
commit 4c8530dc7d7d ("net/tcp: Only produce
> AO/MD5 logs if there are any keys").
>
> Signed-off-by: Dmitry Safonov <0x7f454...@gmail.com>
Reviewed-by: Eric Dumazet
eters available readonly from within a
> network namespace, allowing a container to read them.
>
> Signed-off-by: Matteo Croce
Reviewed-by: Eric Dumazet
ftest to make sure the issue doesn't get reintroduced.
>
> Fixes: 09dbdf28f9f9 ("net/sched: taprio: fix calculation of maximum gate
> durations")
> Signed-off-by: Vladimir Oltean
Reviewed-by: Eric Dumazet
Thanks!
On Wed, May 15, 2024 at 6:32 PM Daniel Jurgens wrote:
>
> The rtnl_lock would stay locked if allocating promisc_allmulti failed.
> Also changed the allocation to GFP_KERNEL.
>
> Fixes: ff7c7d9f5261 ("virtio_net: Remove command data from control_buf")
> Reported-by: Er
On Wed, May 15, 2024 at 5:12 PM Daniel Jurgens wrote:
>
> The rtnl_lock would stay locked if allocating promisc_allmulti failed.
>
> Fixes: ff7c7d9f5261 ("virtio_net: Remove command data from control_buf")
> Reported-by: Eric Dumazet
> Link:
>
On Fri, May 3, 2024 at 10:25 PM Daniel Jurgens wrote:
>
> Allocate memory for the data when it's used. Ideally the struct could
> be on the stack, but we can't DMA stack memory. With this change only
> the header and status memory are shared between commands, which will
> allow using a tighter loc
On Thu, May 9, 2024 at 8:58 PM Richard Gobert wrote:
>
>
> Interesting, I think that is indeed a bug, that exists also in the current
> implementation.
> NAPI_GRO_CB(p)->ip_fixedid (is_atomic before we renamed it in this commit)
> is cleared as being part of NAPI_GRO_CB(skb)->zeroed in dev_gro_re
On Tue, May 7, 2024 at 2:40 PM Alexander Lobakin
wrote:
>
> In fact, this structure contains a flexible array at the end, but
> historically its size, alignment etc., is calculated manually.
> There are several instances of the structure embedded into other
> structures, but also there's ongoing e
On Tue, May 7, 2024 at 6:30 PM Richard Gobert wrote:
>
> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> iph->id, ...) against all packets in a loop. These flush checks are used in
> all merging UDP and TCP flows.
>
> These checks need to be done only once and only against th
ey will be free.
>
> To prevent this, it should be changed to hlist_for_each_entry_safe.
>
> Fixes: 94dc550a5062 ("gtp: fix an use-after-free in ipv4_pdp_find()")
> Signed-off-by: Hyunwoo Kim
Reviewed-by: Eric Dumazet
Thanks !
On Fri, Apr 26, 2024 at 4:30 PM Corinna Vinschen wrote:
>
> Hi Eric,
>
> On Apr 23 16:10, Eric Dumazet wrote:
> > On Tue, Apr 23, 2024 at 3:47 PM Corinna Vinschen
> > wrote:
> > >
> > > From: Paolo Abeni
> > >
> > > Sabri
On Fri, Apr 26, 2024 at 10:47 AM wrote:
>
> From: Peilin He
>
> Introduce a tracepoint for icmp_send, which can help users to get more
> detail information conveniently when icmp abnormal events happen.
>
> 1. Giving an usecase example:
> =
> When an application experi
x src=x dest=x state=x reason=NOT_SPECIFIED
> -0 [002] ..s1. 1830.262425: tcp_send_reset: skbaddr=x
> skaddr=x src=x dest=x state=x reason=NO_SOCKET
>
> [1]
> Link:
> https://lore.kernel.org/all/CANn89iJw8x-LqgsWOeJQQvgVg6DnL5aBRLi10QN2WBdr+X4k=w...@mail.gmail.com/
Reviewed-by: Eric Dumazet
Thanks !
tate=TCP_ESTABLISHED reason=NOT_SPECIFIED
>
> Signed-off-by: Jason Xing
> Reviewed-by: Steven Rostedt (Google)
> ---
Reviewed-by: Eric Dumazet
ason.
>
> Note: using SK_RST_REASON_NOT_SPECIFIED is the same as
> SK_RST_REASON_MPTCP_RST_EUNSPEC. They are both unknown. So we can convert
> it directly.
>
> Suggested-by: Paolo Abeni
> Signed-off-by: Jason Xing
> Reviewed-by: Matthieu Baerts (NGI0)
Reviewed-by: Eric Dumazet
ason Xing
> Reviewed-by: Matthieu Baerts (NGI0)
Reviewed-by: Eric Dumazet
On Thu, Apr 25, 2024 at 5:14 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Like what we did to passive reset:
> only passing possible reset reason in each active reset path.
>
> No functional changes.
>
> Signed-off-by: Jason Xing
> Acked-by: Matthieu Baerts (NGI0)
Reviewed-by: Eric Dumazet
On Thu, Apr 25, 2024 at 5:14 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Adjust the parameter and support passing reason of reset which
> is for now NOT_SPECIFIED. No functional changes.
>
> Signed-off-by: Jason Xing
> Acked-by: Matthieu Baerts (NGI0)
Reviewed-by: Eric Dumazet
gt; After this series applied, it will have the ability to open a new
> gate to let other people contribute more reasons into it :)
>
> Signed-off-by: Jason Xing
> Acked-by: Matthieu Baerts (NGI0)
Reviewed-by: Eric Dumazet
On Tue, Apr 23, 2024 at 3:47 PM Corinna Vinschen wrote:
>
> From: Paolo Abeni
>
> Sabrina reports that the igb driver does not cope well with large
> MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload
> corruption on TX.
>
> An easy reproducer is to run ssh to connect to the machine.
On Mon, Apr 22, 2024 at 3:48 PM Jakub Kicinski wrote:
>
> On Sun, 21 Apr 2024 13:32:24 -0600 David Ahern wrote:
> > On 4/21/24 1:17 PM, Eric Dumazet wrote:
> > > I wonder if NLM_F_DUMP_FILTERED should not be reported to user space ?
> >
> > good point. We do set
the key will be free.
>
> To prevent this, it should be changed to hlist_for_each_entry_safe.
>
> Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
> Signed-off-by: Hyunwoo Kim
Reviewed-by: Eric Dumazet
Thanks !
__
On Sat, Apr 20, 2024 at 4:35 AM Jakub Kicinski wrote:
>
> Having to filter the right ifindex in the tests is a bit tedious.
> Add support for dumping qstats for a single ifindex.
>
> Signed-off-by: Jakub Kicinski
> ---
> Documentation/netlink/specs/netdev.yaml | 1 +
> net/core/netdev-genl-gen.
On Fri, Apr 19, 2024 at 9:29 AM Jason Xing wrote:
>
> On Fri, Apr 19, 2024 at 3:02 PM Eric Dumazet wrote:
> >
> > On Fri, Apr 19, 2024 at 4:31 AM Jason Xing
> > wrote:
> > >
> > > On Fri, Apr 19, 2024 at 7:26 AM Jason Xing
> > > wrote:
>
On Fri, Apr 19, 2024 at 4:31 AM Jason Xing wrote:
>
> On Fri, Apr 19, 2024 at 7:26 AM Jason Xing wrote:
> >
> > > When I said "If you feel the need to put them in a special group, this
> > > is fine by me.",
> > > this was really about partitioning the existing enum into groups, if
> > > you pref
On Thu, Apr 18, 2024 at 6:24 PM Jason Xing wrote:
>
> On Thu, Apr 18, 2024 at 11:46 PM Jakub Kicinski wrote:
> >
> > On Thu, 18 Apr 2024 11:30:02 +0800 Jason Xing wrote:
> > > I'm not sure why the patch series has been changed to 'Changes
> > > Requested', until now I don't think I need to change
On Wed, Apr 17, 2024 at 10:51 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Add a new standalone file for the easy future extension to support
> both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
>
> This patch only does the preparations for reset reason mechanism,
> nothing els
On Wed, Apr 17, 2024 at 10:35 AM Simon Horman wrote:
>
> + Toke Høiland-Jørgensen
> cake@lists.bufferbloat.net
>
> On Mon, Apr 15, 2024 at 01:20:42PM +0000, Eric Dumazet wrote:
> > Instead of relying on RTNL, cake_dump() can use READ_ONCE()
> > annotations, paire
On Fri, Apr 5, 2024 at 3:06 PM Matthieu Baerts (NGI0)
wrote:
>
> From: Geliang Tang
>
> This patch adds "last time" fields last_data_sent, last_data_recv and
> last_ack_recv in struct mptcp_sock to record the last time data_sent,
> data_recv and ack_recv happened. They all are initialized as
> tc
On Fri, Mar 29, 2024 at 11:23 AM Jason Xing wrote:
>
> On Fri, Mar 29, 2024 at 5:07 PM Eric Dumazet wrote:
> >
> > On Fri, Mar 29, 2024 at 4:43 AM Jason Xing
> > wrote:
> > >
> > > From: Jason Xing
> > >
> > > Prior to this pat
On Fri, Mar 29, 2024 at 4:43 AM Jason Xing wrote:
>
> From: Jason Xing
>
> In addition to knowing the 4-tuple of the flow which generates RST,
> the reason why it does so is very important because we have some
> cases where the RST should be sent and have no clue which one
> exactly.
>
> Adding l
On Fri, Mar 29, 2024 at 4:43 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Prior to this patch, what we can see by enabling trace_tcp_send is
> only happening under two circumstances:
> 1) active rst mode
> 2) non-active rst mode and based on the full socket
>
> That means the inconsistency occur
igned-off-by: Jason Xing
Reviewed-by: Eric Dumazet
tats::rx-alloc-fail).
> >
> > The direct motivation for this patch is that one of the drivers
> > used at Meta calls napi_alloc_skb() (so prior to this patch without
> > __GFP_NOWARN), and the resulting OOM warning is the top networking
> > warning in our fleet.
> >
> > Reviewed-by: Alexander Lobakin
> > Signed-off-by: Jakub Kicinski
>
> Reviewed-by: Simon Horman
Reviewed-by: Eric Dumazet
On Tue, Mar 26, 2024 at 3:43 PM Richard Gobert wrote:
>
> Eric Dumazet wrote:
> > On Mon, Mar 25, 2024 at 7:27 PM Richard Gobert
> > wrote:
> >>
> >> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> >> iph->id, ...) against al
On Mon, Mar 25, 2024 at 7:27 PM Richard Gobert wrote:
>
> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> iph->id, ...) against all packets in a loop. These flush checks are used
> currently only in tcp flows in GRO.
I think this is a bug.
GRO should not aggregate packets i
On Tue, Mar 26, 2024 at 11:44 AM Jason Xing wrote:
> Well, it's a pity that it seems that we are about to abandon this
> method but it's not that friendly to the users who are unable to
> deploy BPF...
It is a pity these tracepoint patches are consuming a lot of reviewer
time, just because
some
On Thu, Mar 21, 2024 at 4:09 AM wrote:
>
> From: he peilin
>
> Introduce a tracepoint for icmp_send, which can help users to get more
> detail information conveniently when icmp abnormal events happen.
>
> 1. Giving an usecase example:
> =
> When an application experie
On Sat, Mar 9, 2024 at 4:35 PM Richard Gobert wrote:
>
> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> iph->id, ...) against all packets in a loop. These flush checks are
> relevant only to tcp flows, and as such they're used to determine whether
> the packets can be merged
On Thu, Mar 7, 2024 at 2:28 PM Richard Gobert wrote:
>
> This patch sets network_header and inner_network_header to their respective
> values during the receive phase of GRO. This allows us to use
> inner_network_header later on in GRO. network_header is already set in
> dev_gro_receive and under
On Mon, Mar 4, 2024 at 10:29 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Use the existing parameter and print the address of skbaddr
> as other trace functions do.
>
> Signed-off-by: Jason Xing
Reviewed-by: Eric Dumazet
gt; and it will print like below:
>
> ...tcp_retransmit_skb: skbaddr=XXX skaddr=XXX family=AF_INET...
>
> Signed-off-by: Jason Xing
Reviewed-by: Eric Dumazet
On Thu, Feb 29, 2024 at 6:10 PM Jason Xing wrote:
>
> From: Jason Xing
>
> Prio to this patch, the trace function doesn't print addresses
> which might be forgotten. As we can see, it already fetches
> those, use it directly and it will print like below:
>
> ...tcp_retransmit_skb: skbaddr=XXX ska
On Mon, Mar 4, 2024 at 8:01 AM Jason Xing wrote:
>
> On Fri, Mar 1, 2024 at 1:10 AM Jason Xing wrote:
> >
> > From: Jason Xing
> >
> > When I reviewed other people's patch [1], I noticed that similar thing
> > also happens in tcp_event_skb class and tcp_event_sk_skb class. They
> > don't print t
On Mon, Mar 4, 2024 at 4:46 AM fuyuanli wrote:
>
> It is useful to expose skb addr and sock addr to user in tracepoint
> tcp_probe, so that we can get more information while monitoring
> receiving of tcp data, by ebpf or other ways.
>
> For example, we need to identify a packet by seq and end_seq
On Fri, Mar 1, 2024 at 1:59 PM Alexander Lobakin
wrote:
>
> From: Eric Dumazet
> Date: Fri, 1 Mar 2024 09:03:55 +0100
>
> > On Fri, Mar 1, 2024 at 7:59 AM Jakub Kicinski wrote:
> >>
> >> On Thu, 29 Feb 2024 13:30:22 -0800 Kees Cook wrote:
>
> Re WARN
On Fri, Mar 1, 2024 at 4:50 AM Yan Zhai wrote:
>
> On Thu, Feb 29, 2024 at 9:47 PM Yan Zhai wrote:
> >
> > We noticed task RCUs being blocked when threaded NAPIs are very busy at
> > workloads: detaching any BPF tracing programs, i.e. removing a ftrace
> > trampoline, will simply block for very l
On Fri, Mar 1, 2024 at 7:59 AM Jakub Kicinski wrote:
>
> On Thu, 29 Feb 2024 13:30:22 -0800 Kees Cook wrote:
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index 118c40258d07..b476809d0bae 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
>
On Fri, Mar 1, 2024 at 8:03 AM Jakub Kicinski wrote:
>
> struct net_device poll_dev in struct igc_q_vector was added
> in one of the initial commits, but never used.
>
> Signed-off-by: Jakub Kicinski
Reviewed-by: Eric Dumazet
On Thu, Feb 29, 2024 at 2:22 PM Richard Gobert wrote:
>
>
>
> Eric Dumazet wrote:
> >
> > My intuition is that this patch has a high cost for normal GRO processing.
> > SW-GRO is already a bottleneck on ARM cores in smart NICS.
> >
> > I would suggest
On Thu, Feb 29, 2024 at 3:53 PM Eric Dumazet wrote:
>
> On Thu, Feb 29, 2024 at 3:47 PM Jakub Kicinski wrote:
> >
> > On Thu, 29 Feb 2024 09:55:22 +0100 Eric Dumazet wrote:
> > > I do not see other solution than this, otherwise we have to add more
> > > po
On Thu, Feb 29, 2024 at 3:47 PM Jakub Kicinski wrote:
>
> On Thu, 29 Feb 2024 09:55:22 +0100 Eric Dumazet wrote:
> > I do not see other solution than this, otherwise we have to add more
> > pollution to include/linux/netdevice.h
>
> Right :(
>
> > diff --git a/in
IZER’
> smp_store_release(&p, RCU_INITIALIZER((typeof(p))_r_a_p__v)); \
> ^~~
> net/core/dev.c:9081:2: note: in expansion of macro ‘rcu_assign_pointer’
>rcu_assign_pointer(dev->dpll_pin, dpll_pin);
>^~
>
> O
On Wed, Feb 28, 2024 at 3:07 PM Vadim Fedorenko
wrote:
>
> On 28/02/2024 11:09, Tasmiya Nalatwad wrote:
> > Greetings,
> >
> > [revert 0d60d8df6f49] [net/net-next] [6.8-rc5] Build Failure
> >
> > Reverting below commit fixes the issue
> >
> > commit 0d60d8df6f493bb46bf5db40d39dd60a1bafdd4e
> >
On Tue, Feb 27, 2024 at 4:44 PM Yan Zhai wrote:
>
> We noticed task RCUs being blocked when threaded NAPIs are very busy in
> production: detaching any BPF tracing programs, i.e. removing a ftrace
> trampoline, will simply block for very long in rcu_tasks_wait_gp. This
> ranges from hundreds of se
On Tue, Feb 27, 2024 at 3:50 AM wrote:
>
> From: xu xin
>
> Introduce a tracepoint for icmp_send, which can help users to get more
> detail information conveniently when icmp abnormal events happen.
>
> 1. Giving an usecase example:
> =
> When an application experience
On Sat, Feb 24, 2024 at 10:04 AM Dmitry Safonov wrote:
>
> Two reasons:
> 1. It's grown up enough
> 2. In order to not do header spaghetti by including
>, which is necessary for TCP tracepoints.
>
> Signed-off-by: Dmitry Safonov
Okay, but what about CONFIG_IPV6=m ?
I do not see any EXPORT_S
1 - 100 of 2565 matches
Mail list logo
