Re: [PATCH v2 1/1] xen-netback: process malformed sk_buff correctly to avoid BUG_ON()

On 03/28/2018 08:51 PM, Dongli Zhang wrote: > The "BUG_ON(!frag_iter)" in function xenvif_rx_next_chunk() is triggered if > the received sk_buff is malformed, that is, when the sk_buff has pattern > (skb->data_len && !skb_shinfo(skb)->nr_frags). Below is a sample call > stack: > >... > > The

Re: [PATCH] x86, msr: fix rdmsrl_safe_on_cpu()

On 03/28/2018 03:08 AM, Borislav Petkov wrote: > I guess now that the rdmsr* side does this, you probably should convert > the wrmsr* side as well. Yes indeed, thanks for the reminder.

Re: [PATCH] x86, msr: fix rdmsrl_safe_on_cpu()

On 03/28/2018 03:08 AM, Borislav Petkov wrote: > I guess now that the rdmsr* side does this, you probably should convert > the wrmsr* side as well. Yes indeed, thanks for the reminder.

Re: net_tx_action race condition?

On 03/28/2018 12:30 AM, Saurabh Kr wrote: > Hi Eric/Angelo, >   > We are seeing the assertion error  in linux kernel 2.4.29  “*kernel: KERNEL: > assertion (atomic_read(>users) == 0) failed at dev.c(1397)**”.* Based on > patch provided (_https://patchwork.kernel.org/patch/5368051/_ ) we merged

Re: net_tx_action race condition?

On 03/28/2018 12:30 AM, Saurabh Kr wrote: > Hi Eric/Angelo, >   > We are seeing the assertion error  in linux kernel 2.4.29  “*kernel: KERNEL: > assertion (atomic_read(>users) == 0) failed at dev.c(1397)**”.* Based on > patch provided (_https://patchwork.kernel.org/patch/5368051/_ ) we merged

[tip:x86/cleanups] x86/msr: Make rdmsrl_safe_on_cpu() scheduling safe as well

Commit-ID: 9b9a51354cae933f5640b5bb73bbcd32f989122f Gitweb: https://git.kernel.org/tip/9b9a51354cae933f5640b5bb73bbcd32f989122f Author: Eric Dumazet <eduma...@google.com> AuthorDate: Tue, 27 Mar 2018 20:22:33 -0700 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate:

[tip:x86/cleanups] x86/msr: Make rdmsrl_safe_on_cpu() scheduling safe as well

Commit-ID: 9b9a51354cae933f5640b5bb73bbcd32f989122f Gitweb: https://git.kernel.org/tip/9b9a51354cae933f5640b5bb73bbcd32f989122f Author: Eric Dumazet AuthorDate: Tue, 27 Mar 2018 20:22:33 -0700 Committer: Thomas Gleixner CommitDate: Wed, 28 Mar 2018 10:34:13 +0200 x86/msr: Make

[PATCH] x86, msr: fix rdmsrl_safe_on_cpu()

n_cpu() to schedule") Signed-off-by: Eric Dumazet <eduma...@google.com> Reported-by: kbuild test robot <fengguang...@intel.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: Borislav Petkov

[PATCH] x86, msr: fix rdmsrl_safe_on_cpu()

n_cpu() to schedule") Signed-off-by: Eric Dumazet Reported-by: kbuild test robot Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov --- arch/x86/lib/msr-smp.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/arch/x86/lib/msr-smp.

Re: 07cde313b2 ("x86/msr: Allow rdmsr_safe_on_cpu() to schedule"): BUG: kernel hang in boot stage

anups > commit 07cde313b2d21f728cec2836db7cdb55476f7a26 > Author: Eric Dumazet <eduma...@google.com> > AuthorDate: Fri Mar 23 14:58:17 2018 -0700 > Commit: Thomas Gleixner <t...@linutronix.de> > CommitDate: Tue Mar 27 12:01:47 2018 +0200 > x86/msr: Allow rdmsr_safe_on_cpu() to schedule

Re: 07cde313b2 ("x86/msr: Allow rdmsr_safe_on_cpu() to schedule"): BUG: kernel hang in boot stage

s of microseconds. > All usage sites are in preemptible context, convert rdmsr_safe_on_cpu() to > use a completion instead of busy polling. > Overall daemon cpu usage was reduced by 35 %, and latencies caused by > msr_read() disappeared. > Signed-of

[tip:x86/cleanups] x86/cpuid: Allow cpuid_read() to schedule

Commit-ID: 67bbd7a8d6bcdc44cc27105ae8c374e9176ceaf1 Gitweb: https://git.kernel.org/tip/67bbd7a8d6bcdc44cc27105ae8c374e9176ceaf1 Author: Eric Dumazet <eduma...@google.com> AuthorDate: Fri, 23 Mar 2018 14:58:18 -0700 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate:

[tip:x86/cleanups] x86/cpuid: Allow cpuid_read() to schedule

Commit-ID: 67bbd7a8d6bcdc44cc27105ae8c374e9176ceaf1 Gitweb: https://git.kernel.org/tip/67bbd7a8d6bcdc44cc27105ae8c374e9176ceaf1 Author: Eric Dumazet AuthorDate: Fri, 23 Mar 2018 14:58:18 -0700 Committer: Thomas Gleixner CommitDate: Tue, 27 Mar 2018 12:01:48 +0200 x86/cpuid: Allow

[tip:x86/cleanups] x86/msr: Allow rdmsr_safe_on_cpu() to schedule

Commit-ID: 07cde313b2d21f728cec2836db7cdb55476f7a26 Gitweb: https://git.kernel.org/tip/07cde313b2d21f728cec2836db7cdb55476f7a26 Author: Eric Dumazet <eduma...@google.com> AuthorDate: Fri, 23 Mar 2018 14:58:17 -0700 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate:

[tip:x86/cleanups] x86/msr: Allow rdmsr_safe_on_cpu() to schedule

Commit-ID: 07cde313b2d21f728cec2836db7cdb55476f7a26 Gitweb: https://git.kernel.org/tip/07cde313b2d21f728cec2836db7cdb55476f7a26 Author: Eric Dumazet AuthorDate: Fri, 23 Mar 2018 14:58:17 -0700 Committer: Thomas Gleixner CommitDate: Tue, 27 Mar 2018 12:01:47 +0200 x86/msr: Allow

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

On 03/24/2018 01:09 AM, Ingo Molnar wrote: > > * Eric Dumazet <eduma...@google.com> wrote: > >> I noticed high latencies caused by a daemon periodically reading >> various MSR on all cpus. KASAN kernels would see ~10ms latencies >> simply reading one MSR. Even

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

On 03/24/2018 01:09 AM, Ingo Molnar wrote: > > * Eric Dumazet wrote: > >> I noticed high latencies caused by a daemon periodically reading >> various MSR on all cpus. KASAN kernels would see ~10ms latencies >> simply reading one MSR. Even without KASAN, sending

Re: [PATCH v3 2/2] x86, cpuid: allow cpuid_read() to schedule

On 03/23/2018 03:17 PM, H. Peter Anvin wrote: > On 03/23/18 14:58, Eric Dumazet wrote: >> I noticed high latencies caused by a daemon periodically reading various >> MSR and cpuid on all cpus. KASAN kernels would see ~10ms latencies >> simply reading one cpuid. Even witho

Re: [PATCH v3 2/2] x86, cpuid: allow cpuid_read() to schedule

On 03/23/2018 03:17 PM, H. Peter Anvin wrote: > On 03/23/18 14:58, Eric Dumazet wrote: >> I noticed high latencies caused by a daemon periodically reading various >> MSR and cpuid on all cpus. KASAN kernels would see ~10ms latencies >> simply reading one cpuid. Even witho

[PATCH v3 2/2] x86, cpuid: allow cpuid_read() to schedule

consume hundreds of usec or more. Switching to smp_call_function_single_async() and a completion allows to reschedule and not burn cpu cycles. Signed-off-by: Eric Dumazet <eduma...@google.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: Thomas Gleixner <t...@linutronix.d

[PATCH v3 2/2] x86, cpuid: allow cpuid_read() to schedule

consume hundreds of usec or more. Switching to smp_call_function_single_async() and a completion allows to reschedule and not burn cpu cycles. Signed-off-by: Eric Dumazet Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Borislav Petkov Cc: Ingo Molnar Cc: Hugh Dickins --- arch/

[PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

hundreds of usec. Converts rdmsr_safe_on_cpu() to use a completion instead of busy polling. Overall daemon cpu usage was reduced by 35 %, and latencies caused by msr_read() disappeared. Signed-off-by: Eric Dumazet <eduma...@google.com> Cc: "H. Peter Anvin" <h...@zytor.com>

[PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

hundreds of usec. Converts rdmsr_safe_on_cpu() to use a completion instead of busy polling. Overall daemon cpu usage was reduced by 35 %, and latencies caused by msr_read() disappeared. Signed-off-by: Eric Dumazet Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav

Re: [PATCH v2 1/2] x86, msr: add rdmsr_safe_on_cpu_resched() and use it in msr_read()

On 03/23/2018 02:27 PM, Thomas Gleixner wrote: > > Looking at all call sites. None of them is performance critical and all of > them are in preemptible context. > > So we simply can switch the rdmsr_safe_on_cpu() implementation over to wait > mode completely. SGTM, thanks for looking, I will

Re: [PATCH v2 1/2] x86, msr: add rdmsr_safe_on_cpu_resched() and use it in msr_read()

On 03/23/2018 02:27 PM, Thomas Gleixner wrote: > > Looking at all call sites. None of them is performance critical and all of > them are in preemptible context. > > So we simply can switch the rdmsr_safe_on_cpu() implementation over to wait > mode completely. SGTM, thanks for looking, I will

Re: [PATCH] netlink: make sure nladdr has correct size in netlink_connect()

oogle.com> > Fixes: 1da177e4c3f41524 ("Linux-2.6.12-rc2") Reviewed-by: Eric Dumazet <eduma...@google.com> Thanks Alexander.

Re: [PATCH] netlink: make sure nladdr has correct size in netlink_connect()

: 1da177e4c3f41524 ("Linux-2.6.12-rc2") Reviewed-by: Eric Dumazet Thanks Alexander.

[PATCH v2 2/2] x86, cpuid: allow cpuid_read() to schedule

consume hundreds of usec or more. Switching to smp_call_function_single_async() and a completion allows to reschedule and not burn cpu cycles. Signed-off-by: Eric Dumazet <eduma...@google.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: Thomas Gleixner <t...@linutroni

[PATCH v2 2/2] x86, cpuid: allow cpuid_read() to schedule

consume hundreds of usec or more. Switching to smp_call_function_single_async() and a completion allows to reschedule and not burn cpu cycles. Signed-off-by: Eric Dumazet Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Hugh Dickins --- arch/x86/kernel/cp

[PATCH v2 1/2] x86, msr: add rdmsr_safe_on_cpu_resched() and use it in msr_read()

-by: Eric Dumazet <eduma...@google.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: Hugh Dickins <hu...@google.com> --- v2: fixed the missing part for !CONFIG_SMP arch/x86/include/asm/

[PATCH v2 1/2] x86, msr: add rdmsr_safe_on_cpu_resched() and use it in msr_read()

-by: Eric Dumazet Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Hugh Dickins --- v2: fixed the missing part for !CONFIG_SMP arch/x86/include/asm/msr.h | 6 ++ arch/x86/kernel/msr.c | 2 +- arch/x86/lib/msr-smp.c | 43 +++

Re: [PATCH 1/2] x86, msr: add rdmsr_safe_on_cpu_resched() and use it in msr_read()

rong git tree, please drop us a note to help improve the system] > url: https://github.com/0day-ci/linux/commits/Eric-Dumazet/x86-msr-add-rdmsr_safe_on_cpu_resched-and-use-it-in-msr_read/20180319-001007 > config: i386-randconfig-s1-201811 (attached as .config) > compiler: gcc-6 (Debian 6.4.0

Re: [PATCH 1/2] x86, msr: add rdmsr_safe_on_cpu_resched() and use it in msr_read()

drop us a note to help improve the system] > url: https://github.com/0day-ci/linux/commits/Eric-Dumazet/x86-msr-add-rdmsr_safe_on_cpu_resched-and-use-it-in-msr_read/20180319-001007 > config: i386-randconfig-s1-201811 (attached as .config) > compiler: gcc-6 (Debian 6.4.0-9) 6.

[PATCH 2/2] x86, cpuid: allow cpuid_read() to schedule

consume hundreds of usec or more. Switching to smp_call_function_single_async() and a completion allows to reschedule and not burn cpu cycles. Signed-off-by: Eric Dumazet <eduma...@google.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: Thomas Gleixner <t...@linutroni

[PATCH 1/2] x86, msr: add rdmsr_safe_on_cpu_resched() and use it in msr_read()

-by: Eric Dumazet <eduma...@google.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: Hugh Dickins <hu...@google.com> --- arch/x86/include/asm/msr.h | 1 + arch/x86/kernel/msr.c

[PATCH 2/2] x86, cpuid: allow cpuid_read() to schedule

consume hundreds of usec or more. Switching to smp_call_function_single_async() and a completion allows to reschedule and not burn cpu cycles. Signed-off-by: Eric Dumazet Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Hugh Dickins --- arch/x86/kernel/cp

[PATCH 1/2] x86, msr: add rdmsr_safe_on_cpu_resched() and use it in msr_read()

-by: Eric Dumazet Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Hugh Dickins --- arch/x86/include/asm/msr.h | 1 + arch/x86/kernel/msr.c | 2 +- arch/x86/lib/msr-smp.c | 43 ++ 3 files changed, 45 insertions(+), 1 deletio

Re: KASAN: use-after-free Read in pfifo_fast_enqueue

On 03/14/2018 05:16 PM, Eric Dumazet wrote: > > typical use after free... > > diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c > index > 190570f21b208d5a17943360a3a6f85e1c2a2187..663e016491773f40f81d9bbfeab3dd68e1c2fc5c > 100644 > --- a/net/sched/s

Re: KASAN: use-after-free Read in pfifo_fast_enqueue

On 03/14/2018 05:16 PM, Eric Dumazet wrote: > > typical use after free... > > diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c > index > 190570f21b208d5a17943360a3a6f85e1c2a2187..663e016491773f40f81d9bbfeab3dd68e1c2fc5c > 100644 > --- a/net/sched/s

Re: KASAN: use-after-free Read in pfifo_fast_enqueue

On 03/14/2018 04:30 PM, syzbot wrote: > syzbot has found reproducer for the following crash on net-next commit > a870a02cc963de35452bbed932560ed69725c4f2 (Tue Mar 13 20:58:39 2018 +) > pktgen: use dynamic allocation for debug print buffer > > So far this crash happened 7 times on mmots,

Re: KASAN: use-after-free Read in pfifo_fast_enqueue

On 03/14/2018 04:30 PM, syzbot wrote: > syzbot has found reproducer for the following crash on net-next commit > a870a02cc963de35452bbed932560ed69725c4f2 (Tue Mar 13 20:58:39 2018 +) > pktgen: use dynamic allocation for debug print buffer > > So far this crash happened 7 times on mmots,

Re: WARNING in __local_bh_enable_ip (2)

On 03/14/2018 01:11 PM, syzbot wrote: Hello, syzbot hit the following crash on net-next commit be9fc0971a5c27b791608cf9705a04fe96dbd395 (Tue Mar 13 11:44:53 2018 +) net: fix sysctl_fb_tunnels_only_for_init_net link error So far this crash happened 2 times on net-next. Unfortunately, I

Re: WARNING in __local_bh_enable_ip (2)

On 03/14/2018 01:11 PM, syzbot wrote: Hello, syzbot hit the following crash on net-next commit be9fc0971a5c27b791608cf9705a04fe96dbd395 (Tue Mar 13 11:44:53 2018 +) net: fix sysctl_fb_tunnels_only_for_init_net link error So far this crash happened 2 times on net-next. Unfortunately, I

Re: [PATCH] netlink: make sure nladdr has correct size in netlink_connect()

On Wed, Mar 14, 2018 at 7:16 AM, Alexander Potapenko <gli...@google.com> wrote: > > > > On Wed, Mar 14, 2018 at 3:11 PM Eric Dumazet <eduma...@google.com> wrote: >> >> On Wed, Mar 14, 2018 at 7:03 AM, Alexander Potapenko <gli...@google.com> >> wrote

Re: [PATCH] netlink: make sure nladdr has correct size in netlink_connect()

On Wed, Mar 14, 2018 at 7:16 AM, Alexander Potapenko wrote: > > > > On Wed, Mar 14, 2018 at 3:11 PM Eric Dumazet wrote: >> >> On Wed, Mar 14, 2018 at 7:03 AM, Alexander Potapenko >> wrote: >> > KMSAN reports use of uninitialized memory in the case when |a

Re: [PATCH] netlink: make sure nladdr has correct size in netlink_connect()

On Wed, Mar 14, 2018 at 7:03 AM, Alexander Potapenko wrote: > KMSAN reports use of uninitialized memory in the case when |alen| is > smaller than sizeof(struct netlink_sock), and therefore |nladdr| isn't > fully copied from the userspace. > > Signed-off-by: Alexander Potapenko

Re: [PATCH] netlink: make sure nladdr has correct size in netlink_connect()

On Wed, Mar 14, 2018 at 7:03 AM, Alexander Potapenko wrote: > KMSAN reports use of uninitialized memory in the case when |alen| is > smaller than sizeof(struct netlink_sock), and therefore |nladdr| isn't > fully copied from the userspace. > > Signed-off-by: Alexander Potapenko > Fixes:

Re: [PATCH v2 1/1] net: check before dereferencing netdev_ops during busy poll

->ndo_busy_poll; + else + busy_poll = NULL; do { rc = 0; We could instead setup a non NULL netdev_ops pointer on these 'dummy' devices to not add a check in fast path, but I presume we do not really care since this fix is for old kernels, and consid

Re: [PATCH v2 1/1] net: check before dereferencing netdev_ops during busy poll

ll; + else + busy_poll = NULL; do { rc = 0; We could instead setup a non NULL netdev_ops pointer on these 'dummy' devices to not add a check in fast path, but I presume we do not really care since this fix is for old kernels, and considering how long it took to discover this bug. Reviewed-by: Eric Dumazet

Re: WARNING in __proc_create

On 03/09/2018 03:32 PM, Cong Wang wrote: On Fri, Mar 9, 2018 at 3:21 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: On 03/09/2018 03:05 PM, Cong Wang wrote: BTW, the warning itself is all about empty names, so perhaps it's better to fix them separately. Huh ? You want more

Re: WARNING in __proc_create

On 03/09/2018 03:32 PM, Cong Wang wrote: On Fri, Mar 9, 2018 at 3:21 PM, Eric Dumazet wrote: On 03/09/2018 03:05 PM, Cong Wang wrote: BTW, the warning itself is all about empty names, so perhaps it's better to fix them separately. Huh ? You want more syzbot reports ? I do not. I

Re: WARNING in __proc_create

On 03/09/2018 03:05 PM, Cong Wang wrote: BTW, the warning itself is all about empty names, so perhaps it's better to fix them separately. Huh ? You want more syzbot reports ? I do not. I unblocked this report today [1], you can be sure that as soon as syzbot gets the correct tag

Re: WARNING in __proc_create

On 03/09/2018 03:05 PM, Cong Wang wrote: BTW, the warning itself is all about empty names, so perhaps it's better to fix them separately. Huh ? You want more syzbot reports ? I do not. I unblocked this report today [1], you can be sure that as soon as syzbot gets the correct tag

Re: WARNING in __proc_create

On 03/09/2018 02:56 PM, Eric Dumazet wrote: I sent a patch a while back, but Pablo/Florian wanted more than that simple fix. We also need to filter special characters like '/' Or maybe I am mixing with something else. Yes, Florian mentioned that we also had to reject "." and ".."

Re: WARNING in __proc_create

On 03/09/2018 02:56 PM, Eric Dumazet wrote: I sent a patch a while back, but Pablo/Florian wanted more than that simple fix. We also need to filter special characters like '/' Or maybe I am mixing with something else. Yes, Florian mentioned that we also had to reject "." and ".."

Re: WARNING in __proc_create

On 03/09/2018 02:48 PM, Cong Wang wrote: On Fri, Mar 9, 2018 at 1:59 PM, syzbot wrote: Hello, syzbot hit the following crash on net-next commit 617aebe6a97efa539cc4b8a52adccd89596e6be0 (Sun Feb 4 00:25:42 2018 +) Merge tag

Re: WARNING in __proc_create

On 03/09/2018 02:48 PM, Cong Wang wrote: On Fri, Mar 9, 2018 at 1:59 PM, syzbot wrote: Hello, syzbot hit the following crash on net-next commit 617aebe6a97efa539cc4b8a52adccd89596e6be0 (Sun Feb 4 00:25:42 2018 +) Merge tag 'usercopy-v4.16-rc1' of

Re: [PATCH] drivers: net: wireless: ath: ath9k: dfs: remove VLA usage

On 03/09/2018 05:23 AM, Andreas Christoforou wrote: The kernel would like to have all stack VLA usage removed. This is the correct patch. Signed-off-by: Andreas Christoforou This is a lazy changelog really. 'This is the correct patch' has no technical value.

Re: [PATCH] drivers: net: wireless: ath: ath9k: dfs: remove VLA usage

On 03/09/2018 05:23 AM, Andreas Christoforou wrote: The kernel would like to have all stack VLA usage removed. This is the correct patch. Signed-off-by: Andreas Christoforou This is a lazy changelog really. 'This is the correct patch' has no technical value. What is VLA ? Sure, _now_

Re: [PATCH] net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()

On 03/07/2018 11:33 PM, Herbert Xu wrote: On Wed, Mar 07, 2018 at 11:24:16AM -0800, Greg Hackmann wrote: f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added a __this_cpu_read() call inside ipcomp_alloc_tfms(). Since this call was introduced, the rules around per-cpu

Re: [PATCH] net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()

On 03/07/2018 11:33 PM, Herbert Xu wrote: On Wed, Mar 07, 2018 at 11:24:16AM -0800, Greg Hackmann wrote: f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added a __this_cpu_read() call inside ipcomp_alloc_tfms(). Since this call was introduced, the rules around per-cpu

Re: [PATCH] net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()

On Wed, 2018-03-07 at 11:24 -0800, Greg Hackmann wrote: > f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added > a > __this_cpu_read() call inside ipcomp_alloc_tfms().  Since this call > was > introduced, the rules around per-cpu accessors have been tightened > and >

Re: [PATCH] net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()

On Wed, 2018-03-07 at 11:24 -0800, Greg Hackmann wrote: > f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added > a > __this_cpu_read() call inside ipcomp_alloc_tfms().  Since this call > was > introduced, the rules around per-cpu accessors have been tightened > and >

Re: [PATCH] Fix partial warnings of checkpatch.pl for ipx_route.c

On Mon, 2018-03-05 at 20:19 +0100, Horatiu Vultur wrote: > Fix partial warnings of checkpatch.pl for ipx_route.c > > Signed-off-by: Horatiu Vultur > --- >  drivers/staging/ipx/ipx_route.c | 7 --- >  1 file changed, 4 insertions(+), 3 deletions(-) > Please take a look at

Re: [PATCH] Fix partial warnings of checkpatch.pl for ipx_route.c

On Mon, 2018-03-05 at 20:19 +0100, Horatiu Vultur wrote: > Fix partial warnings of checkpatch.pl for ipx_route.c > > Signed-off-by: Horatiu Vultur > --- >  drivers/staging/ipx/ipx_route.c | 7 --- >  1 file changed, 4 insertions(+), 3 deletions(-) > Please take a look at

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

On Mon, 2018-03-05 at 12:46 +0100, Oliver Neukum wrote: > On Mon, 2018-03-05 at 08:45 +0100, Marek Szyprowski wrote: > > Hi Oliver, > > > > On 2018-02-27 17:07, Oliver Neukum wrote: > > > Am Dienstag, den 27.02.2018, 07:13 -0800 schrieb Eric Dumazet: > > &

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

On Mon, 2018-03-05 at 12:46 +0100, Oliver Neukum wrote: > On Mon, 2018-03-05 at 08:45 +0100, Marek Szyprowski wrote: > > Hi Oliver, > > > > On 2018-02-27 17:07, Oliver Neukum wrote: > > > Am Dienstag, den 27.02.2018, 07:13 -0800 schrieb Eric Dumazet: > > &

Re: WARNING: kobject bug in netdev_queue_update_kobjects

On Mon, 2018-03-05 at 09:59 -0800, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 661e50bc853209e41a5c14a290ca4decc43cbfd1 (Sun Mar 4 22:54:11 2018 > +) > Linux 4.16-rc4 > > So far this crash happened 2 times on upstream. > C reproducer is attached. >

Re: WARNING: kobject bug in netdev_queue_update_kobjects

On Mon, 2018-03-05 at 09:59 -0800, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 661e50bc853209e41a5c14a290ca4decc43cbfd1 (Sun Mar 4 22:54:11 2018 > +) > Linux 4.16-rc4 > > So far this crash happened 2 times on upstream. > C reproducer is attached. >

Re: Use higher-order pages in vmalloc

On Fri, 2018-02-23 at 13:13 +0100, Michal Hocko wrote: > On Thu 22-02-18 19:01:35, Andy Lutomirski wrote: > > On Thu, Feb 22, 2018 at 1:36 PM, Michal Hocko wrote: > > > On Thu 22-02-18 04:22:54, Matthew Wilcox wrote: > > > > On Thu, Feb 22, 2018 at 07:59:43AM +0100, Michal

Re: Use higher-order pages in vmalloc

On Fri, 2018-02-23 at 13:13 +0100, Michal Hocko wrote: > On Thu 22-02-18 19:01:35, Andy Lutomirski wrote: > > On Thu, Feb 22, 2018 at 1:36 PM, Michal Hocko wrote: > > > On Thu 22-02-18 04:22:54, Matthew Wilcox wrote: > > > > On Thu, Feb 22, 2018 at 07:59:43AM +0100, Michal Hocko wrote: > > > > >

Re: [RFC PATCH v2] ptr_ring: linked list fallback

On Mon, 2018-02-26 at 03:17 +0200, Michael S. Tsirkin wrote: > So pointer rings work fine, but they have a problem: make them too small > and not enough entries fit. Make them too large and you start flushing > your cache and running out of memory. > > This is a new idea of mine: a ring backed

Re: [RFC PATCH v2] ptr_ring: linked list fallback

On Mon, 2018-02-26 at 03:17 +0200, Michael S. Tsirkin wrote: > So pointer rings work fine, but they have a problem: make them too small > and not enough entries fit. Make them too large and you start flushing > your cache and running out of memory. > > This is a new idea of mine: a ring backed

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

On Tue, 2018-02-27 at 07:09 -0800, Eric Dumazet wrote: > > Note that for this one, it seems we also could perform stats updates in > BH context, since skb is queued via defer_bh() > > But simplicity wins I guess. Thinking more about this, I am not sure we have any guarantee tha

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

On Tue, 2018-02-27 at 07:09 -0800, Eric Dumazet wrote: > > Note that for this one, it seems we also could perform stats updates in > BH context, since skb is queued via defer_bh() > > But simplicity wins I guess. Thinking more about this, I am not sure we have any guarantee tha

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

On Tue, 2018-02-27 at 15:42 +0100, Marek Szyprowski wrote: > Hi Eric, > > On 2018-02-27 15:07, Eric Dumazet wrote: > > On Tue, 2018-02-27 at 08:26 +0100, Marek Szyprowski wrote: > > > I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel > > >

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

On Tue, 2018-02-27 at 15:42 +0100, Marek Szyprowski wrote: > Hi Eric, > > On 2018-02-27 15:07, Eric Dumazet wrote: > > On Tue, 2018-02-27 at 08:26 +0100, Marek Szyprowski wrote: > > > I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel > > >

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

On Tue, 2018-02-27 at 08:26 +0100, Marek Szyprowski wrote: > Hi > > I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel > warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No > special activity is needed to reproduce this issue, it happens almost > on every

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

On Tue, 2018-02-27 at 08:26 +0100, Marek Szyprowski wrote: > Hi > > I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel > warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No > special activity is needed to reproduce this issue, it happens almost > on every

[PATCH] percpu: add a schedule point in pcpu_balance_workfn()

From: Eric Dumazet <eduma...@google.com> When a large BPF percpu map is destroyed, I have seen pcpu_balance_workfn() holding cpu for hundreds of milliseconds. On KASAN config and 112 hyperthreads, average time to destroy a chunk is ~4 ms. [ 2489.841376] destroy chunk 1 in 4148

[PATCH] percpu: add a schedule point in pcpu_balance_workfn()

From: Eric Dumazet When a large BPF percpu map is destroyed, I have seen pcpu_balance_workfn() holding cpu for hundreds of milliseconds. On KASAN config and 112 hyperthreads, average time to destroy a chunk is ~4 ms. [ 2489.841376] destroy chunk 1 in 4148689 ns ... [ 2490.093428] destroy chunk

Re: [PATCH] ipv6 sit: work around bogus gcc-8 -Wrestrict warning

On Thu, 2018-02-22 at 16:55 +0100, Arnd Bergmann wrote: ... > > This code is old, so Cc stable to make sure that we don't get the warning > for older kernels built with new gcc. > > Cc: sta...@vger.kernel.org This part makes little sense to me for two reasons. 1) David Miller handles stable

Re: [PATCH] ipv6 sit: work around bogus gcc-8 -Wrestrict warning

On Thu, 2018-02-22 at 16:55 +0100, Arnd Bergmann wrote: ... > > This code is old, so Cc stable to make sure that we don't get the warning > for older kernels built with new gcc. > > Cc: sta...@vger.kernel.org This part makes little sense to me for two reasons. 1) David Miller handles stable

Re: [PATCH net-next] tcp: remove the hardcode in the definition of TCPF Macro

On Tue, 2018-02-20 at 21:28 +0800, Yafang Shao wrote: > TCPF_ macro depends on the definition of TCP_ macro. > So it is better to define them with TCP_ marco. > > Signed-off-by: Yafang Shao <laoar.s...@gmail.com> > --- Seems reasonable, thanks ! Reviewed-by: Eric Dumazet <eduma...@google.com>

Re: [PATCH net-next] tcp: remove the hardcode in the definition of TCPF Macro

On Tue, 2018-02-20 at 21:28 +0800, Yafang Shao wrote: > TCPF_ macro depends on the definition of TCP_ macro. > So it is better to define them with TCP_ marco. > > Signed-off-by: Yafang Shao > --- Seems reasonable, thanks ! Reviewed-by: Eric Dumazet

Re: [PATCH] netlink: put module reference if dump start fails

On Wed, 2018-02-21 at 15:54 +0100, Jason A. Donenfeld wrote: > On Wed, Feb 21, 2018 at 6:47 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > > > This probably should be queued up for stable. > > > > When was the bug added ? This would help a lot stable teams ... &g

Re: [PATCH] netlink: put module reference if dump start fails

On Wed, 2018-02-21 at 15:54 +0100, Jason A. Donenfeld wrote: > On Wed, Feb 21, 2018 at 6:47 AM, Eric Dumazet wrote: > > > This probably should be queued up for stable. > > > > When was the bug added ? This would help a lot stable teams ... > > This needs to be

Re: [PATCH] netlink: put module reference if dump start fails

On Wed, 2018-02-21 at 04:41 +0100, Jason A. Donenfeld wrote: > Before, if cb->start() failed, the module reference would never be put, > because cb->cb_running is intentionally false at this point. Users are > generally annoyed by this because they can no longer unload modules that > leak

Re: [PATCH] netlink: put module reference if dump start fails

On Wed, 2018-02-21 at 04:41 +0100, Jason A. Donenfeld wrote: > Before, if cb->start() failed, the module reference would never be put, > because cb->cb_running is intentionally false at this point. Users are > generally annoyed by this because they can no longer unload modules that > leak

Re: [PATCH 4.4 60/74] ipv6: fix udpv6 sendmsg crash caused by too small MTU

On Mon, Feb 19, 2018 at 11:52 AM, Ben Hutchings wrote: > On Mon, 2018-02-19 at 20:46 +0100, Ben Hutchings wrote: >> On Mon, 2018-01-29 at 13:57 +0100, Greg Kroah-Hartman wrote: >> > 4.4-stable review patch. If anyone has any objections, please let me know. >> > >>

Re: [PATCH 4.4 60/74] ipv6: fix udpv6 sendmsg crash caused by too small MTU

On Mon, Feb 19, 2018 at 11:52 AM, Ben Hutchings wrote: > On Mon, 2018-02-19 at 20:46 +0100, Ben Hutchings wrote: >> On Mon, 2018-01-29 at 13:57 +0100, Greg Kroah-Hartman wrote: >> > 4.4-stable review patch. If anyone has any objections, please let me know. >> > >> > -- >> > >> >

Re: [PATCH] tun: fix mismatch in mutex lock-unlock in tun_get_user()

On Fri, Feb 16, 2018 at 2:11 PM, Alexey Khoroshilov wrote: > There is a single error path where tfile->napi_mutex is left unlocked. > It can lead to a deadlock. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov

Re: [PATCH] tun: fix mismatch in mutex lock-unlock in tun_get_user()

On Fri, Feb 16, 2018 at 2:11 PM, Alexey Khoroshilov wrote: > There is a single error path where tfile->napi_mutex is left unlocked. > It can lead to a deadlock. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov > --- > drivers/net/tun.c | 4

Re: TCP and BBR: reproducibly low cwnd and bandwidth

On Fri, Feb 16, 2018 at 7:15 AM, Oleksandr Natalenko wrote: > Hi, David, Eric, Neal et al. > > On čtvrtek 15. února 2018 21:42:26 CET Oleksandr Natalenko wrote: >> I've faced an issue with a limited TCP bandwidth between my laptop and a >> server in my 1 Gbps LAN while

Re: TCP and BBR: reproducibly low cwnd and bandwidth

On Fri, Feb 16, 2018 at 7:15 AM, Oleksandr Natalenko wrote: > Hi, David, Eric, Neal et al. > > On čtvrtek 15. února 2018 21:42:26 CET Oleksandr Natalenko wrote: >> I've faced an issue with a limited TCP bandwidth between my laptop and a >> server in my 1 Gbps LAN while using BBR as a congestion

Re: v4.16-rc1 misaligned atomics in skb__clone / __napi_alloc_skb

On Thu, 2018-02-15 at 09:24 -0800, Eric Dumazet wrote: > > I will send something more suited to original intent of these commits : > > 90e33d45940793def6f773b2d528e9f3c84ffdc7 tun: enable napi_gro_frags() > for TUN/TAP driver > 943170998b200190f99d3fe7e771437e2c51f319 tun: e

Re: v4.16-rc1 misaligned atomics in skb__clone / __napi_alloc_skb

On Thu, 2018-02-15 at 09:24 -0800, Eric Dumazet wrote: > > I will send something more suited to original intent of these commits : > > 90e33d45940793def6f773b2d528e9f3c84ffdc7 tun: enable napi_gro_frags() > for TUN/TAP driver > 943170998b200190f99d3fe7e771437e2c51f319 tun: e

Re: v4.16-rc1 misaligned atomics in skb__clone / __napi_alloc_skb

On Thu, Feb 15, 2018 at 9:20 AM, Eric Dumazet <eduma...@google.com> wrote: > > Yes, it seems tun.c breaks the assumptions. > > If it really wants to provide arbitrary fragments and alignments, it > should use a separate Sorry, I have sent the message to soon. tun.c should

Re: v4.16-rc1 misaligned atomics in skb__clone / __napi_alloc_skb

On Thu, Feb 15, 2018 at 9:20 AM, Eric Dumazet wrote: > > Yes, it seems tun.c breaks the assumptions. > > If it really wants to provide arbitrary fragments and alignments, it > should use a separate Sorry, I have sent the message to soon. tun.c should use a private 'struct

Re: v4.16-rc1 misaligned atomics in skb__clone / __napi_alloc_skb

On Thu, Feb 15, 2018 at 9:04 AM, Mark Rutland wrote: > Hi, > > While fuzzing arm64 v4.16-rc1 with Syzkaller, I've been hitting a > misaligned atomic in __skb_clone: > > atomic_inc(&(skb_shinfo(skb)->dataref)); > > .. where dataref doesn't have the required natural

<    3   4   5   6   7   8   9   10   11   12   >