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
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
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
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
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 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 experience
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 second
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
>
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 ftrac
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. Acco
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 command
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 <--seq=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 rtnl_l
) {
> 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 lo
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 by
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
ive_skb".
> 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 R
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 va
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 924a9bc362a5 (
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, tcp_set_default_con
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:00
&g
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 rseq_cs
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"
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
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 architect
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 changed
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 __get_user
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
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
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
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
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 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 co
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;
> state
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:
> https://syzkaller.appspot.com/bug?id=abe95dc3e3e9667fc23b8d81f
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
> ---
> net/rds/m
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 pfmemall
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 unfair
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
On Tue, Apr 6, 2021 at 8:41 AM kernel test robot wrote:
>
>
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 4ecc1baf362c5df2dcabe242511e38ee28486545 ("tcp: convert elligible
> sysctls to u8")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
On 4/2/21 10:53 PM, Eric Dumazet wrote:
>
>
> On 4/2/21 8:10 PM, Phillip Potter wrote:
>> On Fri, Apr 02, 2021 at 07:49:44PM +0200, Eric Dumazet wrote:
>>>
>>>
>>> On 4/2/21 7:36 PM, Phillip Potter wrote:
>>>> Use memset to initialize two
On 4/2/21 8:10 PM, Phillip Potter wrote:
> On Fri, Apr 02, 2021 at 07:49:44PM +0200, Eric Dumazet wrote:
>>
>>
>> On 4/2/21 7:36 PM, Phillip Potter wrote:
>>> Use memset to initialize two local buffers in net/ipv6/mcast.c,
>>> and another in net/ipv4/i
On 4/2/21 7:20 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.
>
...
> @@ -2504,6 +2537,7 @@ static int atl1c_init_netdev(struct net_de
On 4/2/21 7:20 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 un
On 4/2/21 7:36 PM, Phillip Potter wrote:
> Use memset to initialize two local buffers in net/ipv6/mcast.c,
> and another in net/ipv4/igmp.c. Fixes a KMSAN found uninit-value
> bug reported by syzbot at:
> https://syzkaller.appspot.com/bug?id=0766d38c656abeace60621896d705743aeefed51
According t
On 4/1/21 7:32 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 un
On Thu, Apr 1, 2021 at 5:58 PM Otto Hollmann wrote:
>
> If there is overlapp between ip_local_port_range and
> ip_local_reserved_ports with a huge reserved block, it will affect
> probability of selecting ephemeral ports, see file
> net/ipv4/inet_hashtables.c:723
>
> int __inet_hash_con
On 3/30/21 12:21 AM, Sasha Levin wrote:
> From: liuyacan
>
> [ Upstream commit f211ac154577ec9ccf07c15f18a6abf0d9bdb4ab ]
>
> The "backlog" argument in listen() specifies
> the maximom length of pending connections,
> so the accept queue should be considered full
> if there are exactly "backl
On 3/30/21 12:11 PM, Hao Sun wrote:
> Hi
>
> When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz
> the Linux kernel, I found a use-after-free vulnerability in
> macvlan_broadcast.
> Hope the report can help you locate the problem.
>
> Details:
> commit: 5695e5161 Linux 5.1
On 3/30/21 7:22 PM, Alaa Emad wrote:
> This change fix KMSAN uninit-value in net/wireless/nl80211.c:225 , That
> because of `fixedlen` variable uninitialized,So I initialized it by zero.
>
> Reported-by: syzbot+72b99dcf4607e8c77...@syzkaller.appspotmail.com
> Signed-off-by: Alaa Emad
> ---
>
On 3/29/21 9:57 PM, Dmitry Safonov wrote:
> Hi,
>
> On 3/29/21 8:04 PM, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:6c996e19 net: change netdev_unregister_timeout_secs min va..
>> git tree: net-next
>> console output: https://syzkaller.appspot.
e introduced by
> "net: make unregister netdev warning timeout configurable":
> it changed "refcnt != 1" to "refcnt".
>
> Signed-off-by: Dmitry Vyukov
> Suggested-by: Eric Dumazet
> Fixes: 5aa3afe107d9 ("net: make unregister netdev warning timeout
On 3/25/21 3:38 PM, Dmitry Vyukov wrote:
> On Thu, Mar 25, 2021 at 3:34 PM Eric Dumazet wrote:
>> On 3/25/21 11:31 AM, Dmitry Vyukov wrote:
>>> netdev_unregister_timeout_secs=0 can lead to printing the
>>> "waiting for dev to become free" message ever
On 3/25/21 11:31 AM, Dmitry Vyukov wrote:
> netdev_unregister_timeout_secs=0 can lead to printing the
> "waiting for dev to become free" message every jiffy.
> This is too frequent and unnecessary.
> Set the min value to 1 second.
>
> Signed-off-by: Dmitry Vyukov
On Thu, Mar 25, 2021 at 8:39 AM Dmitry Vyukov wrote:
>
> On Wed, Mar 24, 2021 at 10:40 AM Eric Dumazet wrote:
> >
> > On Tue, Mar 23, 2021 at 7:49 AM Dmitry Vyukov wrote:
> > >
> > > netdev_wait_allrefs() issues a warning if refcount does not drop to 0
>
On Tue, Mar 23, 2021 at 7:49 AM Dmitry Vyukov wrote:
>
> netdev_wait_allrefs() issues a warning if refcount does not drop to 0
> after 10 seconds. While 10 second wait generally should not happen
> under normal workload in normal environment, it seems to fire falsely
> very often during fuzzing an
1 - 100 of 1873 matches
Mail list logo
