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 alignment, and the >

Re: lost connection to test machine (4)

On Tue, 2018-02-13 at 11:34 -0600, Dennis Zhou wrote: > Hi Eric, > > On Tue, Feb 13, 2018 at 05:35:26AM -0800, Eric Dumazet wrote: > > > > Also I would consider using this fix as I had warnings of cpus being > > stuck there for more than 50 ms : > > > >

Re: lost connection to test machine (4)

On Tue, 2018-02-13 at 11:34 -0600, Dennis Zhou wrote: > Hi Eric, > > On Tue, Feb 13, 2018 at 05:35:26AM -0800, Eric Dumazet wrote: > > > > Also I would consider using this fix as I had warnings of cpus being > > stuck there for more than 50 ms : > > > >

Re: lost connection to test machine (4)

On Mon, 2018-02-12 at 12:05 -0800, Tejun Heo wrote: > On Mon, Feb 12, 2018 at 09:03:25AM -0800, Tejun Heo wrote: > > Hello, Daniel. > > > > On Mon, Feb 12, 2018 at 06:00:13PM +0100, Daniel Borkmann wrote: > > > [ +Dennis, +Tejun ] > > > > > > Looks like we're stuck in percpu allocator with

Re: lost connection to test machine (4)

On Mon, 2018-02-12 at 12:05 -0800, Tejun Heo wrote: > On Mon, Feb 12, 2018 at 09:03:25AM -0800, Tejun Heo wrote: > > Hello, Daniel. > > > > On Mon, Feb 12, 2018 at 06:00:13PM +0100, Daniel Borkmann wrote: > > > [ +Dennis, +Tejun ] > > > > > > Looks like we're stuck in percpu allocator with

Re: [PATCH net] Revert "defer call to mem_cgroup_sk_alloc()"

On Fri, 2018-02-02 at 19:04 +, Roman Gushchin wrote: > On Fri, Feb 02, 2018 at 10:39:04AM -0800, Eric Dumazet wrote: > > On Fri, 2018-02-02 at 18:06 +, Roman Gushchin wrote: > > > > > > Idk, how even we can hit it? And if so, what scary will happen? > &g

Re: [PATCH net] Revert "defer call to mem_cgroup_sk_alloc()"

On Fri, 2018-02-02 at 19:04 +, Roman Gushchin wrote: > On Fri, Feb 02, 2018 at 10:39:04AM -0800, Eric Dumazet wrote: > > On Fri, 2018-02-02 at 18:06 +, Roman Gushchin wrote: > > > > > > Idk, how even we can hit it? And if so, what scary will happen? > &g

Re: [PATCH] iommu/vt-d: add NUMA awareness to intel_alloc_coherent()

On Fri, Feb 2, 2018 at 10:53 AM, Christoph Hellwig wrote: > I've got patches pending to replace all that code with > dma_direct_alloc, which will do the right thing. They were > submitted for 4.16, and I will resend them after -rc1. I see, thanks Christoph !

Re: [PATCH] iommu/vt-d: add NUMA awareness to intel_alloc_coherent()

On Fri, Feb 2, 2018 at 10:53 AM, Christoph Hellwig wrote: > I've got patches pending to replace all that code with > dma_direct_alloc, which will do the right thing. They were > submitted for 4.16, and I will resend them after -rc1. I see, thanks Christoph !

Re: [PATCH net] Revert "defer call to mem_cgroup_sk_alloc()"

On Fri, 2018-02-02 at 18:06 +, Roman Gushchin wrote: > > Idk, how even we can hit it? And if so, what scary will happen? > > If you prefer to have it there, I definitely can return it, > but I see no profit so far. I was simply curious this was not mentioned in the changelog. A revert is

Re: [PATCH net] Revert "defer call to mem_cgroup_sk_alloc()"

On Fri, 2018-02-02 at 18:06 +, Roman Gushchin wrote: > > Idk, how even we can hit it? And if so, what scary will happen? > > If you prefer to have it there, I definitely can return it, > but I see no profit so far. I was simply curious this was not mentioned in the changelog. A revert is

Re: [PATCH net] Revert "defer call to mem_cgroup_sk_alloc()"

") for the cgroup pointer. > > So, let's revert it and call mem_cgroup_sk_alloc() just before > cgroup_sk_alloc(). This is safe, as we hold a reference to the socket > we're cloning, and it holds a reference to the memcg. > > Signed-off-by: Roman Gushchin <g...@

Re: [PATCH net] Revert "defer call to mem_cgroup_sk_alloc()"

") for the cgroup pointer. > > So, let's revert it and call mem_cgroup_sk_alloc() just before > cgroup_sk_alloc(). This is safe, as we hold a reference to the socket > we're cloning, and it holds a reference to the memcg. > > Signed-off-by: Roman Gushchin > Cc: E

Re: WARNING in reuseport_add_sock

On Thu, 2018-02-01 at 15:30 -0800, Eric Biggers wrote: > On Fri, Jan 12, 2018 at 03:58:01PM -0800, syzbot wrote: > > Hello, > > > > syzkaller hit the following crash on > > 30a7acd573899fd8b8ac39236eff6468b195ac7d > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > >

Re: WARNING in reuseport_add_sock

On Thu, 2018-02-01 at 15:30 -0800, Eric Biggers wrote: > On Fri, Jan 12, 2018 at 03:58:01PM -0800, syzbot wrote: > > Hello, > > > > syzkaller hit the following crash on > > 30a7acd573899fd8b8ac39236eff6468b195ac7d > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > >

Re: [PATCH net] net: memcontrol: charge allocated memory after mem_cgroup_sk_alloc()

1:17:56PM -0800, Eric Dumazet wrote: >> On Thu, Feb 1, 2018 at 12:22 PM, Roman Gushchin <g...@fb.com> wrote: >> > On Thu, Feb 01, 2018 at 10:16:55AM -0500, David Miller wrote: >> >> From: Roman Gushchin <g...@fb.com> >> >> Date: Wed, 31 Jan

Re: [PATCH net] net: memcontrol: charge allocated memory after mem_cgroup_sk_alloc()

So I really start thinking that reverting 9f1c2674b328 >> >> > ("net: memcontrol: defer call to mem_cgroup_sk_alloc()") >> >> > and fixing the original issue differently might be easier >> >> > and a proper way to go. Does it makes sense? >&g

Re: [PATCH net] net: memcontrol: charge allocated memory after mem_cgroup_sk_alloc()

erting 9f1c2674b328 >> > ("net: memcontrol: defer call to mem_cgroup_sk_alloc()") >> > and fixing the original issue differently might be easier >> > and a proper way to go. Does it makes sense? >> >> You'll need to work that out with Eric Dumazet

Re: [PATCH net] net: memcontrol: charge allocated memory after mem_cgroup_sk_alloc()

> > ("net: memcontrol: defer call to mem_cgroup_sk_alloc()") >> > and fixing the original issue differently might be easier >> > and a proper way to go. Does it makes sense? >> >> You'll need to work that out with Eric Dumazet who added the >> change in question

[PATCH v2] iommu/vt-d: add NUMA awareness to intel_alloc_coherent()

From: Eric Dumazet <eduma...@google.com> Some devices (like mlx4) try hard to allocate memory on selected NUMA node, but it turns out intel_alloc_coherent() is not NUMA aware yet. Note that dma_generic_alloc_coherent() in arch/x86/kernel/pci-dma.c gets this right. Signed-off-by: Eric D

[PATCH v2] iommu/vt-d: add NUMA awareness to intel_alloc_coherent()

From: Eric Dumazet Some devices (like mlx4) try hard to allocate memory on selected NUMA node, but it turns out intel_alloc_coherent() is not NUMA aware yet. Note that dma_generic_alloc_coherent() in arch/x86/kernel/pci-dma.c gets this right. Signed-off-by: Eric Dumazet Cc: Benjamin Serebrin

Re: [PATCH] iommu/vt-d: add NUMA awareness to intel_alloc_coherent()

On Wed, 2018-01-31 at 14:45 -0800, Eric Dumazet wrote: > From: Eric Dumazet <eduma...@google.com> > > Some devices (like mlx4) try hard to allocate memory on selected > NUMA node, but it turns out intel_alloc_coherent() is not NUMA > aware yet. > > Note that dma_gener

Re: [PATCH] iommu/vt-d: add NUMA awareness to intel_alloc_coherent()

On Wed, 2018-01-31 at 14:45 -0800, Eric Dumazet wrote: > From: Eric Dumazet > > Some devices (like mlx4) try hard to allocate memory on selected > NUMA node, but it turns out intel_alloc_coherent() is not NUMA > aware yet. > > Note that dma_generic_alloc_coherent() in arch

[PATCH] iommu/vt-d: add NUMA awareness to intel_alloc_coherent()

From: Eric Dumazet <eduma...@google.com> Some devices (like mlx4) try hard to allocate memory on selected NUMA node, but it turns out intel_alloc_coherent() is not NUMA aware yet. Note that dma_generic_alloc_coherent() in arch/x86/kernel/pci-dma.c gets this right. Signed-off-by: Eric D

[PATCH] iommu/vt-d: add NUMA awareness to intel_alloc_coherent()

From: Eric Dumazet Some devices (like mlx4) try hard to allocate memory on selected NUMA node, but it turns out intel_alloc_coherent() is not NUMA aware yet. Note that dma_generic_alloc_coherent() in arch/x86/kernel/pci-dma.c gets this right. Signed-off-by: Eric Dumazet Cc: Benjamin Serebrin

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

On Thu, 2018-01-25 at 11:27 +0800, jianchao.wang wrote: > Hi Tariq > > On 01/22/2018 10:12 AM, jianchao.wang wrote: > > > > On 19/01/2018 5:49 PM, Eric Dumazet wrote: > > > > > On Fri, 2018-01-19 at 23:16 +0800, jianchao.wang wrote: > > > >

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

On Thu, 2018-01-25 at 11:27 +0800, jianchao.wang wrote: > Hi Tariq > > On 01/22/2018 10:12 AM, jianchao.wang wrote: > > > > On 19/01/2018 5:49 PM, Eric Dumazet wrote: > > > > > On Fri, 2018-01-19 at 23:16 +0800, jianchao.wang wrote: > > > >

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

On Sun, 2018-01-21 at 18:24 +0200, Tariq Toukan wrote: > > On 21/01/2018 11:31 AM, Tariq Toukan wrote: > > > > > > On 19/01/2018 5:49 PM, Eric Dumazet wrote: > > > On Fri, 2018-01-19 at 23:16 +0800, jianchao.wang wrote: > > > > Hi Tariq > >

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

On Sun, 2018-01-21 at 18:24 +0200, Tariq Toukan wrote: > > On 21/01/2018 11:31 AM, Tariq Toukan wrote: > > > > > > On 19/01/2018 5:49 PM, Eric Dumazet wrote: > > > On Fri, 2018-01-19 at 23:16 +0800, jianchao.wang wrote: > > > > Hi Tariq > >

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

wrote: > > > Thanks Jianchao for your patch. > > > > > > And Thank you guys for your reviews, much appreciated. > > > I was off-work on Friday and Saturday. > > > > > > On 14/01/2018 4:40 AM, jianchao.wang wrote: > > > > Dear all &

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

wrote: > > > Thanks Jianchao for your patch. > > > > > > And Thank you guys for your reviews, much appreciated. > > > I was off-work on Friday and Saturday. > > > > > > On 14/01/2018 4:40 AM, jianchao.wang wrote: > > > > Dear all &

Re: KASAN: slab-out-of-bounds Read in __dev_queue_xmit

On Thu, 2018-01-18 at 15:58 -0800, syzbot wrote: > Hello, > > syzbot hit the following crash on linux-next commit > 0e08c463db387a2adcb0243b15ab868a73f87807 > > So far this crash happened 6 times on linux-next, mmots, upstream. > C reproducer is attached. > syzkaller reproducer is attached. >

Re: KASAN: slab-out-of-bounds Read in __dev_queue_xmit

On Thu, 2018-01-18 at 15:58 -0800, syzbot wrote: > Hello, > > syzbot hit the following crash on linux-next commit > 0e08c463db387a2adcb0243b15ab868a73f87807 > > So far this crash happened 6 times on linux-next, mmots, upstream. > C reproducer is attached. > syzkaller reproducer is attached. >

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Wed, Jan 17, 2018 at 2:00 PM, Thomas Gleixner wrote: > On Wed, 17 Jan 2018, Linus Torvalds wrote: > >> On Wed, Jan 17, 2018 at 1:54 PM, Thomas Gleixner wrote: >> > raise_softirq() -> raise_softirq_irqoff() >> > >> > set_softirq_bit(); >> > >> >

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Wed, Jan 17, 2018 at 2:00 PM, Thomas Gleixner wrote: > On Wed, 17 Jan 2018, Linus Torvalds wrote: > >> On Wed, Jan 17, 2018 at 1:54 PM, Thomas Gleixner wrote: >> > raise_softirq() -> raise_softirq_irqoff() >> > >> > set_softirq_bit(); >> > >> > if (!in_interrupt()) >> >

Re: [PATCH v3 8/9] x86: use __uaccess_begin_nospec and ASM_IFENCE in get_user paths

On Wed, Jan 17, 2018 at 11:26 AM, Linus Torvalds wrote: > On Wed, Jan 17, 2018 at 6:17 AM, Alan Cox wrote: >> >> Can we kill off the remaining users of set_fs() ? > > I would love to, but it's not going to happen short-term. If ever. > > Some

Re: [PATCH v3 8/9] x86: use __uaccess_begin_nospec and ASM_IFENCE in get_user paths

On Wed, Jan 17, 2018 at 11:26 AM, Linus Torvalds wrote: > On Wed, Jan 17, 2018 at 6:17 AM, Alan Cox wrote: >> >> Can we kill off the remaining users of set_fs() ? > > I would love to, but it's not going to happen short-term. If ever. > > Some could be removed today: the code in

Re: dvb usb issues since kernel 4.9

On Fri, 2018-01-12 at 19:13 -0200, Mauro Carvalho Chehab wrote: > > > The .config file used to build the Kernel is at: > https://pastebin.com/wpZghann > Hi Mauro Any chance you can try CONFIG_HZ_1000=y, CONFIG_HZ=1000 ? Thanks.

Re: dvb usb issues since kernel 4.9

On Fri, 2018-01-12 at 19:13 -0200, Mauro Carvalho Chehab wrote: > > > The .config file used to build the Kernel is at: > https://pastebin.com/wpZghann > Hi Mauro Any chance you can try CONFIG_HZ_1000=y, CONFIG_HZ=1000 ? Thanks.

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

On Fri, 2018-01-12 at 13:01 -0800, Saeed Mahameed wrote: > which is better to grasp ?: > > update_doorbell() { > dma_wmb(); > ring->db = prod; > } This one is IMO the most secure one (least surprise) Considering the time it took to discover this bug, I would really play safe. But

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

On Fri, 2018-01-12 at 13:01 -0800, Saeed Mahameed wrote: > which is better to grasp ?: > > update_doorbell() { > dma_wmb(); > ring->db = prod; > } This one is IMO the most secure one (least surprise) Considering the time it took to discover this bug, I would really play safe. But

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

On Fri, 2018-01-12 at 11:53 -0800, Saeed Mahameed wrote: > > On 01/12/2018 08:46 AM, Eric Dumazet wrote: > > On Fri, 2018-01-12 at 09:32 -0700, Jason Gunthorpe wrote: > > > On Fri, Jan 12, 2018 at 11:42:22AM +0800, Jianchao Wang wrote: > > > > Customer reported me

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

On Fri, 2018-01-12 at 11:53 -0800, Saeed Mahameed wrote: > > On 01/12/2018 08:46 AM, Eric Dumazet wrote: > > On Fri, 2018-01-12 at 09:32 -0700, Jason Gunthorpe wrote: > > > On Fri, Jan 12, 2018 at 11:42:22AM +0800, Jianchao Wang wrote: > > > > Customer reported me

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

On Fri, 2018-01-12 at 09:32 -0700, Jason Gunthorpe wrote: > On Fri, Jan 12, 2018 at 11:42:22AM +0800, Jianchao Wang wrote: > > Customer reported memory corruption issue on previous mlx4_en driver > > version where the order-3 pages and multiple page reference counting > > were still used. > > > >

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

On Fri, 2018-01-12 at 09:32 -0700, Jason Gunthorpe wrote: > On Fri, Jan 12, 2018 at 11:42:22AM +0800, Jianchao Wang wrote: > > Customer reported memory corruption issue on previous mlx4_en driver > > version where the order-3 pages and multiple page reference counting > > were still used. > > > >

Re: [RFC PATCH 1/2] softirq: Account time and iteration stats per vector

occurences per vector. > > For now we still defer to ksoftirqd when the per vector limits are reached > > Suggested-by: Linus Torvalds <torva...@linux-foundation.org> > Signed-off-by: Frederic Weisbecker <frede...@kernel.org> > Cc: Dmitry Safonov <d...@arista.com> &

Re: [RFC PATCH 1/2] softirq: Account time and iteration stats per vector

> For now we still defer to ksoftirqd when the per vector limits are reached > > Suggested-by: Linus Torvalds > Signed-off-by: Frederic Weisbecker > Cc: Dmitry Safonov > Cc: Eric Dumazet > Cc: Linus Torvalds > Cc: Peter Zijlstra > Cc: Andrew Morton > Cc: David Mill

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 12:46 PM, Dmitry Safonov wrote: > On Thu, 2018-01-11 at 12:40 -0800, Linus Torvalds wrote: >> On Thu, Jan 11, 2018 at 12:34 PM, Dmitry Safonov >> wrote: >> > >> > I could try to write a PoC for that.. >> > What should be the trigger to

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 12:46 PM, Dmitry Safonov wrote: > On Thu, 2018-01-11 at 12:40 -0800, Linus Torvalds wrote: >> On Thu, Jan 11, 2018 at 12:34 PM, Dmitry Safonov >> wrote: >> > >> > I could try to write a PoC for that.. >> > What should be the trigger to fall into workqueue? >> > How to

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 12:34 PM, Dmitry Safonov <d...@arista.com> wrote: > On Thu, 2018-01-11 at 12:22 -0800, Linus Torvalds wrote: >> On Thu, Jan 11, 2018 at 12:16 PM, Eric Dumazet <eduma...@google.com> >> wrote: >> > >> > Note that when I im

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 12:34 PM, Dmitry Safonov wrote: > On Thu, 2018-01-11 at 12:22 -0800, Linus Torvalds wrote: >> On Thu, Jan 11, 2018 at 12:16 PM, Eric Dumazet >> wrote: >> > >> > Note that when I implemented TCP Small queues, I did experiments >

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 12:03 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Thu, Jan 11, 2018 at 11:48 AM, Eric Dumazet <eduma...@google.com> wrote: >> That was the purpose on the last patch : As soon as ksoftirqd is scheduled >> (by some kind of jitter

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 12:03 PM, Linus Torvalds wrote: > On Thu, Jan 11, 2018 at 11:48 AM, Eric Dumazet wrote: >> That was the purpose on the last patch : As soon as ksoftirqd is scheduled >> (by some kind of jitter in the 99,000 pps workload, or antagonist wakeup), >> we

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 11:43 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Thu, Jan 11, 2018 at 11:15 AM, Eric Dumazet <eduma...@google.com> wrote: >> >> How are we supposed to know this particular workload is problematic >> for innocent user

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 11:43 AM, Linus Torvalds wrote: > On Thu, Jan 11, 2018 at 11:15 AM, Eric Dumazet wrote: >> >> How are we supposed to know this particular workload is problematic >> for innocent user threads on the same cpu ? > > Put that question another way

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 10:48 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Thu, Jan 11, 2018 at 8:32 AM, Peter Zijlstra <pet...@infradead.org> wrote: >> On Thu, Jan 11, 2018 at 08:20:18AM -0800, Eric Dumazet wrote: >>> diff --git a/kernel/softirq.

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 10:48 AM, Linus Torvalds wrote: > On Thu, Jan 11, 2018 at 8:32 AM, Peter Zijlstra wrote: >> On Thu, Jan 11, 2018 at 08:20:18AM -0800, Eric Dumazet wrote: >>> diff --git a/kernel/softirq.c b/kernel/softirq.c >>> index >>> 2f5e

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 6:31 AM, Dmitry Safonov wrote: > On Thu, 2018-01-11 at 05:44 +0100, Frederic Weisbecker wrote: >> On Wed, Jan 10, 2018 at 08:19:49PM -0800, Linus Torvalds wrote: >> > On Wed, Jan 10, 2018 at 7:22 PM, Frederic Weisbecker >> > wrote: >>

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 6:31 AM, Dmitry Safonov wrote: > On Thu, 2018-01-11 at 05:44 +0100, Frederic Weisbecker wrote: >> On Wed, Jan 10, 2018 at 08:19:49PM -0800, Linus Torvalds wrote: >> > On Wed, Jan 10, 2018 at 7:22 PM, Frederic Weisbecker >> > wrote: >> > > >> > > Makes sense, but I think

Re: Re: dvb usb issues since kernel 4.9

On Tue, Jan 9, 2018 at 10:58 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet <eduma...@google.com> wrote: >> >> Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate >> handling', but TCP

Re: Re: dvb usb issues since kernel 4.9

On Tue, Jan 9, 2018 at 10:58 AM, Linus Torvalds wrote: > On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet wrote: >> >> Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate >> handling', but TCP Small queues heavily use TASKLET, >> so as far as I am co

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Tue, Jan 9, 2018 at 5:36 AM, Dmitry Safonov wrote: > Warning: Not merge-ready > > I. Current workflow of ksoftirqd. > Softirqs are processed in the context of ksoftirqd iff they are > being raised very frequently. How it works: > do_softirq() and invoke_softirq() deffer

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Tue, Jan 9, 2018 at 5:36 AM, Dmitry Safonov wrote: > Warning: Not merge-ready > > I. Current workflow of ksoftirqd. > Softirqs are processed in the context of ksoftirqd iff they are > being raised very frequently. How it works: > do_softirq() and invoke_softirq() deffer pending softirq

Re: Re: dvb usb issues since kernel 4.9

On Tue, Jan 9, 2018 at 9:48 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet <eduma...@google.com> wrote: >> >> So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has >> show

Re: Re: dvb usb issues since kernel 4.9

On Tue, Jan 9, 2018 at 9:48 AM, Linus Torvalds wrote: > On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet wrote: >> >> So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has >> shown up multiple times in various 'regressions' >> simply because it

Re: Re: dvb usb issues since kernel 4.9

On Tue, Jan 9, 2018 at 8:51 AM, Josef Griebichler wrote: > Hi Linus, > > your patch works very good for me and others (please see > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=77006#post77006). > No errors in recordings

Re: Re: dvb usb issues since kernel 4.9

On Tue, Jan 9, 2018 at 8:51 AM, Josef Griebichler wrote: > Hi Linus, > > your patch works very good for me and others (please see > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=77006#post77006). > No errors in recordings any more. > The patch was

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

On Wed, 2018-01-03 at 21:13 -0800, Eric Dumazet wrote: > Note: all commands must start from beginning of the line in the email body. > > I guess skb_probe_transport_header() should be hardened to reject malicious > packets given by user space, instead of being gentle. Although b

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

On Wed, 2018-01-03 at 21:13 -0800, Eric Dumazet wrote: > Note: all commands must start from beginning of the line in the email body. > > I guess skb_probe_transport_header() should be hardened to reject malicious > packets given by user space, instead of being gentle. Although b

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

On Wed, Jan 3, 2018 at 8:58 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 37759fa6d0fa9e4d6036d19ac12f555bfc0aeafd > git://git.cmpxchg.org/linux-mmots.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is

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

On Wed, Jan 3, 2018 at 8:58 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 37759fa6d0fa9e4d6036d19ac12f555bfc0aeafd > git://git.cmpxchg.org/linux-mmots.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > C reproducer is

Re: bonding: Delete an error message for a failed memory allocation in bond_update_slave_arr()

On Wed, 2018-01-03 at 11:28 -0800, Mahesh Bandewar (महेश बंडेवार) wrote: > On Wed, Jan 3, 2018 at 12:45 AM, SF Markus Elfring > wrote: > > > > Omit an extra message for a memory allocation failure in this function. > > > > > > > > This issue was detected by using

Re: bonding: Delete an error message for a failed memory allocation in bond_update_slave_arr()

On Wed, 2018-01-03 at 11:28 -0800, Mahesh Bandewar (महेश बंडेवार) wrote: > On Wed, Jan 3, 2018 at 12:45 AM, SF Markus Elfring > wrote: > > > > Omit an extra message for a memory allocation failure in this function. > > > > > > > > This issue was detected by using the Coccinelle software. > > > >

Re: [PATCH] kobject: fix suppressing modalias in uevents delivered over netlink

On Tue, Dec 19, 2017 at 12:48 AM, Greg Kroah-Hartman wrote: > On Wed, Dec 13, 2017 at 03:21:22PM -0800, Dmitry Torokhov wrote: >> The commit 4a336a23d619 ("kobject: copy env blob in one go") optimized >> constructing uevent data for delivery over netlink by using the

Re: [PATCH] kobject: fix suppressing modalias in uevents delivered over netlink

On Tue, Dec 19, 2017 at 12:48 AM, Greg Kroah-Hartman wrote: > On Wed, Dec 13, 2017 at 03:21:22PM -0800, Dmitry Torokhov wrote: >> The commit 4a336a23d619 ("kobject: copy env blob in one go") optimized >> constructing uevent data for delivery over netlink by using the raw >> environment buffer,

Re: [PATCH] ipv6: ip6mr: Recalc UDP checksum before forwarding

On Wed, 2017-12-13 at 22:20 +1100, Brendan McGrath wrote: > Currently, when forwarding from a Virtual Interface to a Physical > Interface, ip_summed is set to a value of CHECKSUM_UNNECESSARY and > the UDP checksum has not been calculated. > This seems a bug then ? CHECKSUM_UNNECESSARY means

Re: [PATCH] ipv6: ip6mr: Recalc UDP checksum before forwarding

On Wed, 2017-12-13 at 22:20 +1100, Brendan McGrath wrote: > Currently, when forwarding from a Virtual Interface to a Physical > Interface, ip_summed is set to a value of CHECKSUM_UNNECESSARY and > the UDP checksum has not been calculated. > This seems a bug then ? CHECKSUM_UNNECESSARY means

Re: kernel BUG at net/core/skbuff.c:LINE! (2)

On Sun, 2017-12-10 at 12:38 +0800, Xin Long wrote: > On Sun, Dec 10, 2017 at 3:36 AM, Cong Wang > wrote: > > On Fri, Dec 8, 2017 at 12:45 AM, Xin Long > > wrote: > > > This isn't a sctp problem, but mld's, seems when lo's mtu became > > > 0, > > >

Re: kernel BUG at net/core/skbuff.c:LINE! (2)

On Sun, 2017-12-10 at 12:38 +0800, Xin Long wrote: > On Sun, Dec 10, 2017 at 3:36 AM, Cong Wang > wrote: > > On Fri, Dec 8, 2017 at 12:45 AM, Xin Long > > wrote: > > > This isn't a sctp problem, but mld's, seems when lo's mtu became > > > 0, > > > it allocs a skb without enough space in

Re: kernel BUG at net/core/skbuff.c:LINE! (2)

On Sun, 2017-12-10 at 12:36 +0800, Xin Long wrote: > The new patch works to me, just two questions: > 1. should it use "idev->cnf.mtu6" here for mld ? No idea why some parts of IPv6 would use a different view of device mtu. Maybe others can comment. > > 2.  'if (int < unsigned int)' is still

Re: kernel BUG at net/core/skbuff.c:LINE! (2)

On Sun, 2017-12-10 at 12:36 +0800, Xin Long wrote: > The new patch works to me, just two questions: > 1. should it use "idev->cnf.mtu6" here for mld ? No idea why some parts of IPv6 would use a different view of device mtu. Maybe others can comment. > > 2.  'if (int < unsigned int)' is still

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Sat, 2017-12-09 at 13:03 -0800, Matt Turner wrote: > On Fri, Dec 8, 2017 at 1:16 PM, Eric Dumazet <eric.duma...@gmail.com> > wrote: > > On Fri, 2017-12-08 at 12:26 -0800, Matt Turner wrote: > > > > > > Thanks for the quick reply! > > &

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Sat, 2017-12-09 at 13:03 -0800, Matt Turner wrote: > On Fri, Dec 8, 2017 at 1:16 PM, Eric Dumazet > wrote: > > On Fri, 2017-12-08 at 12:26 -0800, Matt Turner wrote: > > > > > > Thanks for the quick reply! > > > > > > I tried the patch on top o

Re: kernel BUG at net/core/skbuff.c:LINE! (2)

On Sat, 2017-12-09 at 19:23 +0800, Xin Long wrote: > On Fri, Dec 8, 2017 at 4:45 PM, Xin Long > wrote: > > On Fri, Dec 8, 2017 at 4:16 PM, syzbot > > > .com> > > wrote: > > > syzkaller has found reproducer

Re: kernel BUG at net/core/skbuff.c:LINE! (2)

On Sat, 2017-12-09 at 19:23 +0800, Xin Long wrote: > On Fri, Dec 8, 2017 at 4:45 PM, Xin Long > wrote: > > On Fri, Dec 8, 2017 at 4:16 PM, syzbot > > > .com> > > wrote: > > > syzkaller has found reproducer for the following crash on > > > 82bcf1def3b5f1251177ad47c44f7e17af039b4b > > >

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Fri, 2017-12-08 at 12:26 -0800, Matt Turner wrote: > > Thanks for the quick reply! > > I tried the patch on top of master, but unfortunately the corruption > still occurs. You might try replacing in sbdma_add_rcvbuffer() sb_new = netdev_alloc_skb(dev, size); by  sb_new = alloc_skb(size,

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Fri, 2017-12-08 at 12:26 -0800, Matt Turner wrote: > > Thanks for the quick reply! > > I tried the patch on top of master, but unfortunately the corruption > still occurs. You might try replacing in sbdma_add_rcvbuffer() sb_new = netdev_alloc_skb(dev, size); by  sb_new = alloc_skb(size,

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Fri, 2017-12-08 at 05:42 -0800, Eric Dumazet wrote: > On Thu, Dec 7, 2017 at 11:54 PM, Matt Turner <matts...@gmail.com> > wrote: > > On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner <matts...@gmail.com> > > wrote: > > > On Sun, Mar 12, 2017 at 6:43 PM, Matt

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Fri, 2017-12-08 at 05:42 -0800, Eric Dumazet wrote: > On Thu, Dec 7, 2017 at 11:54 PM, Matt Turner > wrote: > > On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner > > wrote: > > > On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner > > > wrote: > > > > On

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Thu, Dec 7, 2017 at 11:54 PM, Matt Turner wrote: > On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner wrote: >> On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner wrote: >>> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS >>>

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Thu, Dec 7, 2017 at 11:54 PM, Matt Turner wrote: > On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner wrote: >> On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner wrote: >>> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS >>> corruption on the first file read. >>> >>> To demonstrate, I

Re: [PATCH net-next V2] tuntap: fix possible deadlock when fail to register netdev

ize. > > Fixes: 96f84061620c ("tun: add eBPF based queue selection method") > Reported-by: Eric Dumazet <eric.duma...@gmail.com> > Cc: Eric Dumazet <eric.duma...@gmail.com> > Cc: Willem de Bruijn <will...@google.com> > Signed-off-by: Jason Wang <jasow...@r

Re: [PATCH net-next V2] tuntap: fix possible deadlock when fail to register netdev

ize. > > Fixes: 96f84061620c ("tun: add eBPF based queue selection method") > Reported-by: Eric Dumazet > Cc: Eric Dumazet > Cc: Willem de Bruijn > Signed-off-by: Jason Wang > --- Reviewed-by: Eric Dumazet Thanks.

Re: [PATCH net-next] tuntap: fix possible deadlock when fail to register netdev

ize. > > Fixes: 96f84061620c ("tun: add eBPF based queue selection method") > Reported-by: Eric Dumazet <eric.duma...@gmail.com> > Cc: Eric Dumazet <eric.duma...@gmail.com> > Cc: Willem de Bruijn <will...@google.com> > Signed-off-by: Jason Wang <jasow...@redh

Re: [PATCH net-next] tuntap: fix possible deadlock when fail to register netdev

ize. > > Fixes: 96f84061620c ("tun: add eBPF based queue selection method") > Reported-by: Eric Dumazet > Cc: Eric Dumazet > Cc: Willem de Bruijn > Signed-off-by: Jason Wang > --- >  drivers/net/tun.c | 7 --- >  1 file changed, 4 insertions(+), 3 deletions(-) >

Re: [PATCH net-next V3] tun: add eBPF based queue selection method

On Mon, 2017-12-04 at 17:31 +0800, Jason Wang wrote: > This patch introduces an eBPF based queue selection method. With > this, > the policy could be offloaded to userspace completely through a new > ioctl TUNSETSTEERINGEBPF. Sorry for the delay, I see this patch was merged already. ... >  

Re: [PATCH net-next V3] tun: add eBPF based queue selection method

On Mon, 2017-12-04 at 17:31 +0800, Jason Wang wrote: > This patch introduces an eBPF based queue selection method. With > this, > the policy could be offloaded to userspace completely through a new > ioctl TUNSETSTEERINGEBPF. Sorry for the delay, I see this patch was merged already. ... >  

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

On Wed, 2017-11-29 at 11:37 -0800, Cong Wang wrote: > (Cc'ing fs people...) > > On Wed, Nov 29, 2017 at 12:33 AM, syzbot > om> > wrote: > > Hello, > > > > syzkaller hit the following crash on > >

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

On Wed, 2017-11-29 at 11:37 -0800, Cong Wang wrote: > (Cc'ing fs people...) > > On Wed, Nov 29, 2017 at 12:33 AM, syzbot > om> > wrote: > > Hello, > > > > syzkaller hit the following crash on > > 1d3b78bbc6e983fabb3fbf91b76339bf66e4a12c > >

Re: [PATCH] net-sysfs: export gso_max_size attribute

On Fri, 2017-11-24 at 11:43 -0700, David Ahern wrote: > On 11/24/17 11:32 AM, Eric Dumazet wrote: > > On Fri, 2017-11-24 at 10:14 -0700, David Ahern wrote: > > > On 11/22/17 5:30 PM, Solio Sarabia wrote: > > > > The netdevice gso_max_size is exposed to all

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