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
st=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
: Jason 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
fter 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 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
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
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
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
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
igned-off-by: Jason Xing
Reviewed-by: Eric Dumazet
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
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
nd 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
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
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 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
oesn't have to bother with error
> handling (allocation failure checking, making sure free happens in the
> right spot, etc). This is core responsibility now.
>
> Remove the allocation in the vsockmon driver and leverage the network
> core allocation instead.
>
> Signed-off-by: Breno Leitao
Reviewed-by: Eric Dumazet
On Fri, Feb 23, 2024 at 12:58 PM Breno Leitao wrote:
>
> Do not set rtnl_link_stats64 fields to zero, since they are zeroed
> before ops->ndo_get_stats64 is called in core dev_get_stats() function.
>
> Signed-off-by: Breno Leitao
Reviewed-by: Eric Dumazet
On Wed, Feb 14, 2024 at 5:49 PM Breno Leitao wrote:
>
> On Wed, Feb 14, 2024 at 04:41:36PM +0100, Eric Dumazet wrote:
> > On Wed, Feb 14, 2024 at 3:45 PM Breno Leitao wrote:
> > >
> > > On Tue, Feb 13, 2024 at 10:04:57AM -0800, Jakub Kicinski wrote:
> > &g
On Wed, Feb 14, 2024 at 3:45 PM Breno Leitao wrote:
>
> On Tue, Feb 13, 2024 at 10:04:57AM -0800, Jakub Kicinski wrote:
> > On Tue, 13 Feb 2024 14:57:49 +0100 Eric Dumazet wrote:
> > > Please note that adding other sysfs entries is expensive for workloads
> > > crea
On Fri, Feb 2, 2024 at 5:55 PM Breno Leitao wrote:
>
> From: Jakub Kicinski
>
> softnet_data->time_squeeze is sometimes used as a proxy for
> host overload or indication of scheduling problems. In practice
> this statistic is very noisy and has hard to grasp units -
> e.g. is 10 squeezes a
On Tue, Dec 5, 2023 at 3:11 AM Xuan Zhuo wrote:
>
> On Mon, 4 Dec 2023 13:28:21 +0100, Eric Dumazet wrote:
> > On Mon, Dec 4, 2023 at 12:43 PM Philo Lu wrote:
> > >
> > > Add 3 tracepoints, namely tcp_data_send/tcp_data_recv/tcp_data_acked,
> > > whi
On Mon, Dec 4, 2023 at 12:43 PM Philo Lu wrote:
>
> Add 3 tracepoints, namely tcp_data_send/tcp_data_recv/tcp_data_acked,
> which will be called every time a tcp data packet is sent, received, and
> acked.
> tcp_data_send: called after a data packet is sent.
> tcp_data_recv: called after a data
On Mon, Oct 9, 2023 at 11:43 AM Yajun Deng wrote:
>
>
> On 2023/10/9 17:30, Eric Dumazet wrote:
> > On Mon, Oct 9, 2023 at 10:36 AM Yajun Deng wrote:
> >>
> >> On 2023/10/9 16:20, Eric Dumazet wrote:
> >>> On Mon, Oct 9, 2023 at 10:14 AM Yajun Deng w
On Mon, Oct 9, 2023 at 10:36 AM Yajun Deng wrote:
>
>
> On 2023/10/9 16:20, Eric Dumazet wrote:
> > On Mon, Oct 9, 2023 at 10:14 AM Yajun Deng wrote:
> >>
> >> On 2023/10/9 15:53, Eric Dumazet wrote:
> >>> On Mon, Oct 9, 2023 at 5:07 AM Y
On Mon, Oct 9, 2023 at 10:14 AM Yajun Deng wrote:
>
>
> On 2023/10/9 15:53, Eric Dumazet wrote:
> > On Mon, Oct 9, 2023 at 5:07 AM Yajun Deng wrote:
> >
> >> 'this_cpu_read + this_cpu_write' and 'pr_info + this_cpu_inc' will make
> >> the trace
On Mon, Oct 9, 2023 at 5:07 AM Yajun Deng wrote:
> 'this_cpu_read + this_cpu_write' and 'pr_info + this_cpu_inc' will make
> the trace work well.
>
> They all have 'pop' instructions in them. This may be the key to making
> the trace work well.
>
> Hi all,
>
> I need your help on percpu and
On 4/20/21 5:41 PM, Kuniyuki Iwashima wrote:
> The SO_REUSEPORT option allows sockets to listen on the same port and to
> accept connections evenly. However, there is a defect in the current
> implementation [1]. When a SYN packet is received, the connection is tied
> to a listening socket.
On Tue, Apr 20, 2021 at 3:45 PM Naresh Kamboju
wrote:
>
> Following kernel BUG reported on qemu-arm64 running linux next 20210420
> the config is enabled with KASAN.
>
> steps to reproduce:
>
> - Build the arm64 kernel with KASAN enabled.
> - boot it with below
On Tue, Apr 20, 2021 at 2:00 PM zhaoya wrote:
>
> When using syncookie, since $MSSID is spliced into cookie and
> the legal index of msstab is 0,1,2,3, this gives client 3 bytes
> of freedom, resulting in at most 3 bytes of silent loss.
>
> C seq=12345-> S
> C
On Tue, Apr 20, 2021 at 9:54 AM AceLan Kao wrote:
>
> From: "Chia-Lin Kao (AceLan)"
>
> The rtnl_lock() has been called in rtnetlink_rcv_msg(), and then in
> __dev_open() it calls pm_runtime_resume() to resume devices, and in
> some devices' resume function(igb_resum,igc_resume) they calls
eth = skb_gro_header_slow(skb, hlen, 0);
> --
> 2.31.1
>
>
Good catch, thanks.
This has the unfortunate effect of increasing code length on x86,
maybe we should have an exception to
normal rules so that skb_gro_reset_offset() is inlined.
Reviewed-by: Eric Dumazet
On Sun, Apr 18, 2021 at 4:31 PM Matt Corallo
wrote:
>
> Should the default, though, be so low? If someone is still using a old modem
> they can crank up the sysctl, it does seem
> like such things are pretty rare these days :). Its rather trivial to,
> without any kind of attack, hit 1Mbps of
On Sat, Apr 17, 2021 at 6:03 PM Linus Torvalds
wrote:
>
> On Fri, Apr 16, 2021 at 12:24 PM Eric Dumazet wrote:
> >
> > From: Eric Dumazet
> >
> > We have to loop only to copy u64 values.
> > After this first loop, we copy at most one u32, one u16 and one
On Sat, Apr 17, 2021 at 12:45 AM 赵亚 wrote:
>
> On Fri, Apr 16, 2021 at 7:52 PM Eric Dumazet wrote:
> >
> > On Fri, Apr 16, 2021 at 12:52 PM zhaoya wrote:
> > >
> > > When syncookie is triggered, since $MSSID is spliced into cookie and
> > > the
kb".
> This patch also fixes it.
>
> Fixes: b4b9e3558508 ("netvm: set PF_MEMALLOC as appropriate during SKB
> processing")
> Cc: Mel Gorman
> Cc: David S. Miller
> Cc: Neil Brown
> Cc: Peter Zijlstra
> Cc: Jiri Slaby
> Cc: Mike Christie
>
On Sat, Apr 17, 2021 at 2:31 AM David Ahern wrote:
>
> [ cc author of 648700f76b03b7e8149d13cc2bdb3355035258a9 ]
I think this has been discussed already. There is no strategy that
makes IP reassembly units immune to DDOS attacks.
We added rb-tree and sysctls to let admins choose to use GB of
On Fri, Apr 16, 2021 at 10:11 PM Eric Dumazet wrote:
>
> On Fri, Apr 16, 2021 at 9:44 PM Al Viro wrote:
> >
> > On Fri, Apr 16, 2021 at 12:24:13PM -0700, Eric Dumazet wrote:
> > > From: Eric Dumazet
> > >
> > > We have to loop only to copy u64
On Fri, Apr 16, 2021 at 9:44 PM Al Viro wrote:
>
> On Fri, Apr 16, 2021 at 12:24:13PM -0700, Eric Dumazet wrote:
> > From: Eric Dumazet
> >
> > We have to loop only to copy u64 values.
> > After this first loop, we copy at most one u32, one u16 and one byte.
>
From: Eric Dumazet
We have to loop only to copy u64 values.
After this first loop, we copy at most one u32, one u16 and one byte.
Signed-off-by: Eric Dumazet
---
arch/x86/include/asm/uaccess.h | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include
On Fri, Apr 16, 2021 at 12:52 PM zhaoya wrote:
>
> When syncookie is triggered, since $MSSID is spliced into cookie and
> the legal index of msstab is 0,1,2,3, this gives client 3 bytes
> of freedom, resulting in at most 3 bytes of silent loss.
>
> C seq=12345-> S
> C
On Fri, Apr 16, 2021 at 10:49 AM Balazs Nemeth wrote:
>
> On Thu, 2021-04-15 at 16:46 +0200, Greg Kroah-Hartman wrote:
> > From: Eric Dumazet
> >
> > commit 61431a5907fc36d0738e9a547c7e1556349a03e9 upstream.
> >
> > Commit 924a9bc362a
On Thu, Apr 15, 2021 at 5:47 PM Gong, Sishuai wrote:
>
> Hi,
>
> We found a data race between tcp_set_default_congestion_control() and
> tcp_set_congestion_control() in linux-5.12-rc3.
> In general, when tcp_set_congestion_control() is reading ca->flags with a
> lock grabbed,
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 60af388d23889636011488c42763876bcdda3eab
Gitweb:
https://git.kernel.org/tip/60af388d23889636011488c42763876bcdda3eab
Author:Eric Dumazet
AuthorDate:Tue, 13 Apr 2021 13:33:50 -07:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 0ed96051531ecc6965f6456d25b19b9b6bdb5c28
Gitweb:
https://git.kernel.org/tip/0ed96051531ecc6965f6456d25b19b9b6bdb5c28
Author:Eric Dumazet
AuthorDate:Tue, 13 Apr 2021 13:33:51 -07:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 5e0ccd4a3b01c5a71732a13186ca110a138516ea
Gitweb:
https://git.kernel.org/tip/5e0ccd4a3b01c5a71732a13186ca110a138516ea
Author:Eric Dumazet
AuthorDate:Tue, 13 Apr 2021 13:33:52 -07:00
On Wed, Apr 14, 2021 at 10:09 PM Shakeel Butt wrote:
>
> I will let TCP RX zerocopy experts respond to this but from my high
> level code inspection, I didn't see page->private usage.
Indeed, we do not use page->private, since we do not own the page(s).
On Wed, Apr 14, 2021 at 10:15 PM Arjun Roy wrote:
>
> On Wed, Apr 14, 2021 at 10:35 AM Eric Dumazet wrote:
> >
> > On Wed, Apr 14, 2021 at 7:15 PM Arjun Roy wrote:
> > >
> > > On Wed, Apr 14, 2021 at 9:10 AM Eric Dumazet wrote:
> > > >
>
On Wed, Apr 14, 2021 at 7:15 PM Arjun Roy wrote:
>
> On Wed, Apr 14, 2021 at 9:10 AM Eric Dumazet wrote:
> >
> > On Wed, Apr 14, 2021 at 6:08 PM David Laight
> > wrote:
> > >
> > > From: Eric Dumazet
> > > > Sent: 14 April 2021 17:0
From: Eric Dumazet
Removes this annoying warning:
arch/sh/kernel/traps.c: In function ‘nmi_trap_handler’:
arch/sh/kernel/traps.c:183:15: warning: unused variable ‘cpu’
[-Wunused-variable]
183 | unsigned int cpu = smp_processor_id();
Fixes: fe3f1d5d7cd3 ("sh: Get rid of nmi_count()&quo
On Wed, Apr 14, 2021 at 6:08 PM David Laight wrote:
>
> From: Eric Dumazet
> > Sent: 14 April 2021 17:00
> ...
> > > Repeated unsafe_get_user() calls are crying out for an optimisation.
> > > You get something like:
> > > failed = 0;
> >
On Wed, Apr 14, 2021 at 9:55 AM David Laight wrote:
>
> From: Arjun Roy
> > Sent: 13 April 2021 23:04
> >
> > On Tue, Apr 13, 2021 at 2:19 PM David Laight
> > wrote:
> > >
> > > > If we're special-casing 64-bit architectures anyways - unrolling the
> > > > 32B copy_from_user() for struct
From: Eric Dumazet
After commit 8f2817701492 ("rseq: Use get_user/put_user rather
than __get_user/__put_user") we no longer need
an access_ok() call from __rseq_handle_notify_resume()
Mathieu pointed out the same cleanup can be done
in rseq_syscall().
Signed-off-by: Eric Dumazet
C
From: Eric Dumazet
Commit ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union,
update includes") added regressions for our servers.
Using copy_from_user() and clear_user() for 64bit values
is suboptimal.
We can use faster put_user() and get_user() on 64bit arches.
Signed-of
From: Eric Dumazet
rseq is a heavy user of copy to/from user data in fast paths.
This series tries to reduce the cost.
v3: Third patch going back to v1 (only deal with 64bit arches)
v2: Addressed Peter and Mathieu feedbacks, thanks !
Eric Dumazet (3):
rseq: optimize rseq_update_cpu_id
From: Eric Dumazet
Two put_user() in rseq_update_cpu_id() are replaced
by a pair of unsafe_put_user() with appropriate surroundings.
This removes one stac/clac pair on x86 in fast path.
Signed-off-by: Eric Dumazet
Cc: Mathieu Desnoyers
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
On Tue, Apr 13, 2021 at 8:00 PM Mathieu Desnoyers
wrote:
>
> As long as the ifdefs are localized within clearly identified wrappers in the
> rseq code I don't mind doing the special-casing there.
>
> The point which remains is that I don't think we want to optimize for speed
> on 32-bit
On Tue, Apr 13, 2021 at 7:20 PM Mathieu Desnoyers
wrote:
>
> - On Apr 13, 2021, at 1:07 PM, Eric Dumazet eduma...@google.com wrote:
>
> > On Tue, Apr 13, 2021 at 7:01 PM Eric Dumazet wrote:
> >>
> >> On Tue, Apr 13, 2021 at 6:57 PM Eric Dumazet wrote:
> &
On Tue, Apr 13, 2021 at 7:01 PM Eric Dumazet wrote:
>
> On Tue, Apr 13, 2021 at 6:57 PM Eric Dumazet wrote:
> >
> > On Tue, Apr 13, 2021 at 6:54 PM Mathieu Desnoyers
> > wrote:
> > >
> > > - On Apr 13, 2021, at 12:22 PM, Eric Dumazet eric.duma...@
On Tue, Apr 13, 2021 at 6:57 PM Eric Dumazet wrote:
>
> On Tue, Apr 13, 2021 at 6:54 PM Mathieu Desnoyers
> wrote:
> >
> > - On Apr 13, 2021, at 12:22 PM, Eric Dumazet eric.duma...@gmail.com
> > wrote:
> >
> > > From: Eric Dumazet
> > &
On Tue, Apr 13, 2021 at 6:54 PM Mathieu Desnoyers
wrote:
>
> - On Apr 13, 2021, at 12:22 PM, Eric Dumazet eric.duma...@gmail.com wrote:
>
> > From: Eric Dumazet
> >
> > Commit ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union,
> > update includ
From: Eric Dumazet
Commit ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union,
update includes") added regressions for our servers.
Using copy_from_user() and clear_user() for 64bit values
is suboptimal.
We can use faster put_user() and get_user().
32bit arches can be chan
From: Eric Dumazet
After commit 8f2817701492 ("rseq: Use get_user/put_user rather
than __get_user/__put_user") we no longer need
an access_ok() call from __rseq_handle_notify_resume()
Mathieu pointed out the same cleanup can be done
in rseq_syscall().
Signed-off-by: Eric Dumazet
C
From: Eric Dumazet
Two put_user() in rseq_update_cpu_id() are replaced
by a pair of unsafe_put_user() with appropriate surroundings.
This removes one stac/clac pair on x86 in fast path.
Signed-off-by: Eric Dumazet
Cc: Mathieu Desnoyers
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
From: Eric Dumazet
rseq is a heavy user of copy to/from user data in fast paths.
This series tries to reduce the cost.
v2: Addressed Peter and Mathieu feedbacks, thanks !
Eric Dumazet (3):
rseq: optimize rseq_update_cpu_id()
rseq: remove redundant access_ok()
rseq: optimise
On Tue, Apr 13, 2021 at 4:29 PM Mathieu Desnoyers
wrote:
>
> - On Apr 13, 2021, at 3:36 AM, Eric Dumazet eric.duma...@gmail.com wrote:
>
> > From: Eric Dumazet
> >
> > Two put_user() in rseq_update_cpu_id() are replaced
> > by a pair of unsafe_put_use
On Tue, Apr 13, 2021 at 4:34 PM Mathieu Desnoyers
wrote:
>
> - On Apr 13, 2021, at 3:36 AM, Eric Dumazet eric.duma...@gmail.com wrote:
>
> > From: Eric Dumazet
> >
> > After commit 8f2817701492 ("rseq: Use get_user/put_user rather
> > than __g
On Tue, Apr 13, 2021 at 3:38 PM Michael S. Tsirkin wrote:
>
> On Tue, Apr 13, 2021 at 03:33:40PM +0200, Eric Dumazet wrote:
> > On Tue, Apr 13, 2021 at 3:27 PM Eric Dumazet wrote:
> > >
> > > On Tue, Apr 13, 2021 at 2:57 PM Michael S. Tsirkin
> > > wrot
On Tue, Apr 13, 2021 at 3:27 PM Eric Dumazet wrote:
>
> On Tue, Apr 13, 2021 at 2:57 PM Michael S. Tsirkin wrote:
> >
> > On Mon, Apr 12, 2021 at 06:47:07PM +0200, Eric Dumazet wrote:
> > > On Mon, Apr 12, 2021 at 6:31 PM Eric Dumazet wrote:
> > > >
> &
On Tue, Apr 13, 2021 at 2:57 PM Michael S. Tsirkin wrote:
>
> On Mon, Apr 12, 2021 at 06:47:07PM +0200, Eric Dumazet wrote:
> > On Mon, Apr 12, 2021 at 6:31 PM Eric Dumazet wrote:
> > >
> > > On Mon, Apr 12, 2021 at 6:28 PM Linus Torvalds
> > > wrote:
>
On Tue, Apr 13, 2021 at 12:43 PM Eric Dumazet wrote:
>
> On Tue, Apr 13, 2021 at 11:24 AM Eric Dumazet wrote:
> >
> > On Mon, Apr 12, 2021 at 10:05 PM Guenter Roeck wrote:
> > >
> > > On 4/12/21 10:38 AM, Eric Dumazet wrote:
> > > [ ... ]
> >
On Tue, Apr 13, 2021 at 11:24 AM Eric Dumazet wrote:
>
> On Mon, Apr 12, 2021 at 10:05 PM Guenter Roeck wrote:
> >
> > On 4/12/21 10:38 AM, Eric Dumazet wrote:
> > [ ... ]
> >
> > > Yes, I think this is the real issue here. This smells like some memory
>
On Mon, Apr 12, 2021 at 10:05 PM Guenter Roeck wrote:
>
> On 4/12/21 10:38 AM, Eric Dumazet wrote:
> [ ... ]
>
> > Yes, I think this is the real issue here. This smells like some memory
> > corruption.
> >
> > In my traces, packet is correctly received in AF_
From: Eric Dumazet
Commit ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union,
update includes") added regressions for our servers.
Using copy_from_user() and clear_user() for 64bit values
on 64bit arches is suboptimal.
We might revisit this patch once all 32bit arches suppor
From: Eric Dumazet
After commit 8f2817701492 ("rseq: Use get_user/put_user rather
than __get_user/__put_user") we no longer need
an access_ok() call from __rseq_handle_notify_resume()
Signed-off-by: Eric Dumazet
Cc: Mathieu Desnoyers
Cc: Peter Zijlstra
Cc: "Paul E. McKenney&q
From: Eric Dumazet
Two put_user() in rseq_update_cpu_id() are replaced
by a pair of unsafe_put_user() with appropriate surroundings.
This removes one stac/clac pair on x86 in fast path.
Signed-off-by: Eric Dumazet
Cc: Mathieu Desnoyers
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
From: Eric Dumazet
rseq is a heavy user of copy to/from user data in fast paths.
This series tries to reduce the cost.
Eric Dumazet (3):
rseq: optimize rseq_update_cpu_id()
rseq: remove redundant access_ok()
rseq: optimise for 64bit arches
kernel/rseq.c | 26
On Mon, Apr 12, 2021 at 7:31 PM Guenter Roeck wrote:
>
> On 4/12/21 9:31 AM, Eric Dumazet wrote:
> > On Mon, Apr 12, 2021 at 6:28 PM Linus Torvalds
> > wrote:
> >>
> >> On Sun, Apr 11, 2021 at 10:14 PM Guenter Roeck wrote:
> >>>
> >>>
On Mon, Apr 12, 2021 at 6:31 PM Eric Dumazet wrote:
>
> On Mon, Apr 12, 2021 at 6:28 PM Linus Torvalds
> wrote:
> >
> > On Sun, Apr 11, 2021 at 10:14 PM Guenter Roeck wrote:
> > >
> > > Qemu test results:
> > >
On Mon, Apr 12, 2021 at 6:28 PM Linus Torvalds
wrote:
>
> On Sun, Apr 11, 2021 at 10:14 PM Guenter Roeck wrote:
> >
> > Qemu test results:
> > total: 460 pass: 459 fail: 1
> > Failed tests:
> > sh:rts7751r2dplus_defconfig:ata:net,virtio-net:rootfs
> >
> > The failure bisects to
On 4/12/21 2:38 AM, Matteo Croce wrote:
> From: Matteo Croce
>
> use the new helper macro skb_for_each_frag() which allows to iterate
> through all the SKB fragments.
>
> The patch was created with Coccinelle, this was the semantic patch:
>
> @@
> struct sk_buff *skb;
> identifier i;
>
On 3/30/21 3:26 PM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:29ad81a1 arch/x86: add missing include to sparsemem.h
> git tree: https://github.com/google/kmsan.git master
> console output: https://syzkaller.appspot.com/x/log.txt?x=166fe481d0
On Sun, Apr 11, 2021 at 1:28 PM Phillip Potter wrote:
>
> Check within geneve_xmit_skb/geneve6_xmit_skb that sk_buff structure
> is large enough to include IPv4 or IPv6 header, and reject if not. The
> geneve_xmit_skb portion and overall idea was contributed by Eric Dumazet.
> Fixe
On Sat, Apr 10, 2021 at 12:12 PM Eric Dumazet wrote:
>
> On Sat, Apr 10, 2021 at 11:51 AM Phillip Potter wrote:
> >
> > Zero-fill skb->data in __alloc_skb function of net/core/skbuff.c,
> > up to start of struct skb_shared_info bytes. Fixes a KMSAN-found
> > un
On Sat, Apr 10, 2021 at 11:51 AM Phillip Potter wrote:
>
> Zero-fill skb->data in __alloc_skb function of net/core/skbuff.c,
> up to start of struct skb_shared_info bytes. Fixes a KMSAN-found
> uninit-value bug reported by syzbot at:
>
On 4/9/21 12:14 PM, Xie He wrote:
> On Fri, Apr 9, 2021 at 3:04 AM Eric Dumazet wrote:
>>
>> Note that pfmemalloc skbs are normally dropped in sk_filter_trim_cap()
>>
>> Simply make sure your protocol use it.
>
> It seems "sk_filter_trim_cap" ne
On 4/7/21 2:09 AM, Aditya Pakki wrote:
> In case of rs failure in rds_send_remove_from_sock(), the 'rm' resource
> is freed and later under spinlock, causing potential use-after-free.
> Set the free pointer to NULL to avoid undefined behavior.
>
> Signed-off-by: Aditya Pakki
> ---
>
On 4/9/21 11:14 AM, Xie He wrote:
> On Fri, Apr 9, 2021 at 1:44 AM Mel Gorman wrote:
>>
>> That would imply that the tap was communicating with a swap device to
>> allocate a pfmemalloc skb which shouldn't happen. Furthermore, it would
>> require the swap device to be deactivated while
imediately calls teql_destroy() which does not expect
> zero master pointer and we get OOPS.
>
> Signed-off-by: Pavel Tikhomirov
> ---
This makes sense, thanks !
Reviewed-by: Eric Dumazet
I would think bug origin is
Fixes: 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation")
Can you confirm you have this backported to 3.10.0-1062.7.1.el7.x86_64 ?
On 4/6/21 4:49 PM, Gatis Peisenieks wrote:
> Tx queue cleanup happens in interrupt handler on same core as rx queue
> processing. Both can take considerable amount of processing in high
> packet-per-second scenarios.
>
> Sending big amounts of packets can stall the rx processing which is
d uninit-value bug reported by syzbot at:
> https://syzkaller.appspot.com/bug?id=0766d38c656abeace60621896d705743aeefed51
>
> Reported-by: syzbot+001516d86dbe88862...@syzkaller.appspotmail.com
> Diagnosed-by: Eric Dumazet
> Signed-off-by: Phillip Potter
> ---
SGTM, thanks a lot.
Reviewed-by: Eric Dumazet
d uninit-value bug reported by syzbot at:
> https://syzkaller.appspot.com/bug?id=0766d38c656abeace60621896d705743aeefed51
>
> Reported-by: syzbot+001516d86dbe88862...@syzkaller.appspotmail.com
> Signed-off-by: Phillip Potter
> ---
Please give credits to people who helped.
You could h
1 - 100 of 5669 matches
Mail list logo
