Re: [PATCH] Input: mousedev - add a schedule point in mousedev_write()

On 10/04/2018 03:54 PM, Dmitry Torokhov wrote: > OK, I see. I'll apply the patch then. Thanks ! > > I think evdev.c needs similar treatment as it will keep looping while > there is data... Yeah, presumably other drivers need care as well :/

Re: [PATCH] Input: mousedev - add a schedule point in mousedev_write()

On 10/04/2018 03:54 PM, Dmitry Torokhov wrote: > OK, I see. I'll apply the patch then. Thanks ! > > I think evdev.c needs similar treatment as it will keep looping while > there is data... Yeah, presumably other drivers need care as well :/

Re: [PATCH] Input: mousedev - add a schedule point in mousedev_write()

On Thu, Oct 4, 2018 at 12:38 PM Dmitry Torokhov wrote: > > On October 4, 2018 12:28:56 PM PDT, Eric Dumazet wrote: > >On Thu, Oct 4, 2018 at 11:59 AM Dmitry Torokhov > > wrote: > >> > >> Hi Eric, > >> > >> On Thu, Oct 04, 2018 at 08:47:

Re: [PATCH] Input: mousedev - add a schedule point in mousedev_write()

On Thu, Oct 4, 2018 at 12:38 PM Dmitry Torokhov wrote: > > On October 4, 2018 12:28:56 PM PDT, Eric Dumazet wrote: > >On Thu, Oct 4, 2018 at 11:59 AM Dmitry Torokhov > > wrote: > >> > >> Hi Eric, > >> > >> On Thu, Oct 04, 2018 at 08:47:

Re: [PATCH] Input: mousedev - add a schedule point in mousedev_write()

On Thu, Oct 4, 2018 at 11:59 AM Dmitry Torokhov wrote: > > Hi Eric, > > On Thu, Oct 04, 2018 at 08:47:49AM -0700, Eric Dumazet wrote: > > syzbot was able to trigger rcu stalls by calling write() > > with large number of bytes. > > > > Add a cond_resched() in

Re: [PATCH] Input: mousedev - add a schedule point in mousedev_write()

On Thu, Oct 4, 2018 at 11:59 AM Dmitry Torokhov wrote: > > Hi Eric, > > On Thu, Oct 04, 2018 at 08:47:49AM -0700, Eric Dumazet wrote: > > syzbot was able to trigger rcu stalls by calling write() > > with large number of bytes. > > > > Add a cond_resched() in

[PATCH] Input: mousedev - add a schedule point in mousedev_write()

syzbot was able to trigger rcu stalls by calling write() with large number of bytes. Add a cond_resched() in the loop to avoid this. Link: https://lkml.org/lkml/2018/8/23/1106 Signed-off-by: Eric Dumazet Reported-by: syzbot+9436b02171ac0894d...@syzkaller.appspotmail.com Cc: Dmitry Torokhov Cc

[PATCH] Input: mousedev - add a schedule point in mousedev_write()

syzbot was able to trigger rcu stalls by calling write() with large number of bytes. Add a cond_resched() in the loop to avoid this. Link: https://lkml.org/lkml/2018/8/23/1106 Signed-off-by: Eric Dumazet Reported-by: syzbot+9436b02171ac0894d...@syzkaller.appspotmail.com Cc: Dmitry Torokhov Cc

Re: KMSAN: uninit-value in __dev_mc_add

On Thu, Sep 27, 2018 at 2:30 PM Vladis Dronov wrote: > > Hello, > > This report is actually for the same bug which was reported in: > > https://syzkaller.appspot.com/bug?id=088efeac32fdde781038a777a63e436c0d4d7036 > > The note there that the bug was fixed by "Commits: net: fix uninit-value in >

Re: KMSAN: uninit-value in __dev_mc_add

On Thu, Sep 27, 2018 at 2:30 PM Vladis Dronov wrote: > > Hello, > > This report is actually for the same bug which was reported in: > > https://syzkaller.appspot.com/bug?id=088efeac32fdde781038a777a63e436c0d4d7036 > > The note there that the bug was fixed by "Commits: net: fix uninit-value in >

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

On 09/27/2018 06:02 AM, Dmitry Vyukov wrote: > I am not suggesting to commit this. This is just a hack for debugging. > It in fact lead to some warnings, but still allowed me to reproduce > the bug reliably. > Had you got more meaningful stack traces ? (Showing which context was actually

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

On 09/27/2018 06:02 AM, Dmitry Vyukov wrote: > I am not suggesting to commit this. This is just a hack for debugging. > It in fact lead to some warnings, but still allowed me to reproduce > the bug reliably. > Had you got more meaningful stack traces ? (Showing which context was actually

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

On 09/27/2018 01:10 AM, Dmitry Vyukov wrote: > > Would a stack trace for call_rcu be helpful here? I have this idea for > a long time, but never get around to implementing it: > https://bugzilla.kernel.org/show_bug.cgi?id=198437 > > Also FWIW I recently used the following hack for another

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

On 09/27/2018 01:10 AM, Dmitry Vyukov wrote: > > Would a stack trace for call_rcu be helpful here? I have this idea for > a long time, but never get around to implementing it: > https://bugzilla.kernel.org/show_bug.cgi?id=198437 > > Also FWIW I recently used the following hack for another

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

On 09/26/2018 02:44 PM, Cong Wang wrote: > On Wed, Sep 26, 2018 at 8:44 AM syzbot > wrote: >> >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit:4b1bd6976945 net: phy: marvell: Fix build. >> git tree: net-next >> console output:

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

On 09/26/2018 02:44 PM, Cong Wang wrote: > On Wed, Sep 26, 2018 at 8:44 AM syzbot > wrote: >> >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit:4b1bd6976945 net: phy: marvell: Fix build. >> git tree: net-next >> console output:

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Wed, Aug 1, 2018 at 9:47 AM Dmitry Vyukov wrote: > > Proving with numbers is required for a claimed performance improvement > at the cost of code degradation/increase. For a win-win change there > is really nothing to prove. You have to _prove_ it is a win-win. It is not sufficient to claim

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Wed, Aug 1, 2018 at 9:47 AM Dmitry Vyukov wrote: > > Proving with numbers is required for a claimed performance improvement > at the cost of code degradation/increase. For a win-win change there > is really nothing to prove. You have to _prove_ it is a win-win. It is not sufficient to claim

Re: [PATCH] net/rds/Kconfig: RDS should depend on IPV6

On 07/25/2018 03:20 PM, Anders Roxell wrote: > Build error, implicit declaration of function __inet6_ehashfn shows up > When RDS is enabled but not IPV6. > net/rds/connection.c: In function ‘rds_conn_bucket’: > net/rds/connection.c:67:9: error: implicit declaration of function >

Re: [PATCH] net/rds/Kconfig: RDS should depend on IPV6

On 07/25/2018 03:20 PM, Anders Roxell wrote: > Build error, implicit declaration of function __inet6_ehashfn shows up > When RDS is enabled but not IPV6. > net/rds/connection.c: In function ‘rds_conn_bucket’: > net/rds/connection.c:67:9: error: implicit declaration of function >

Re: [PATCH net-next] tcp: add SNMP counter for the number of packets pruned from ofo queue

On 07/25/2018 06:40 AM, Yafang Shao wrote: > > Because we want to know why packets were dropped. > If that could be show in netstat, we could easily find that it is > dropped due to ofo prune. We have a counter already for these events : LINUX_MIB_OFOPRUNED You want to add another counter

Re: [PATCH net-next] tcp: add SNMP counter for the number of packets pruned from ofo queue

On 07/25/2018 06:40 AM, Yafang Shao wrote: > > Because we want to know why packets were dropped. > If that could be show in netstat, we could easily find that it is > dropped due to ofo prune. We have a counter already for these events : LINUX_MIB_OFOPRUNED You want to add another counter

Re: [PATCH net-next] tcp: add SNMP counter for the number of packets pruned from ofo queue

On 07/25/2018 06:06 AM, Yafang Shao wrote: > LINUX_MIB_OFOPRUNED is used to count how many times ofo queue is pruned, > but sometimes we want to know how many packets are pruned from this queue, > that could help us to track the dropped packets. > > As LINUX_MIB_OFOPRUNED is a useful event for

Re: [PATCH net-next] tcp: add SNMP counter for the number of packets pruned from ofo queue

On 07/25/2018 06:06 AM, Yafang Shao wrote: > LINUX_MIB_OFOPRUNED is used to count how many times ofo queue is pruned, > but sometimes we want to know how many packets are pruned from this queue, > that could help us to track the dropped packets. > > As LINUX_MIB_OFOPRUNED is a useful event for

[tip:timers/core] ktime: Provide typesafe ktime_to_ns()

Commit-ID: a8802d97e73346bc81609df9dfba7d3306f40d87 Gitweb: https://git.kernel.org/tip/a8802d97e73346bc81609df9dfba7d3306f40d87 Author: Eric Dumazet AuthorDate: Wed, 11 Jul 2018 11:16:41 -0700 Committer: Thomas Gleixner CommitDate: Thu, 12 Jul 2018 21:35:28 +0200 ktime: Provide

[tip:timers/core] ktime: Provide typesafe ktime_to_ns()

Commit-ID: a8802d97e73346bc81609df9dfba7d3306f40d87 Gitweb: https://git.kernel.org/tip/a8802d97e73346bc81609df9dfba7d3306f40d87 Author: Eric Dumazet AuthorDate: Wed, 11 Jul 2018 11:16:41 -0700 Committer: Thomas Gleixner CommitDate: Thu, 12 Jul 2018 21:35:28 +0200 ktime: Provide

[PATCH] ktime: provide typesafe ktime_to_ns()

Using ktime_to_ns() is nice to help backports to stable kernels. Having a typesafe function instead of a macro avoid stupid typos and waste of time tracking these typos. Signed-off-by: Eric Dumazet Reported-by: Willem de Bruijn Cc: John Stultz Cc: Peter Zijlstra Cc: Linus Torvalds

[PATCH] ktime: provide typesafe ktime_to_ns()

Using ktime_to_ns() is nice to help backports to stable kernels. Having a typesafe function instead of a macro avoid stupid typos and waste of time tracking these typos. Signed-off-by: Eric Dumazet Reported-by: Willem de Bruijn Cc: John Stultz Cc: Peter Zijlstra Cc: Linus Torvalds

Re: [PATCH net-next 2/2] tcp: refactor tcp_queue_rcv

Hi Yafang On Wed, Jul 11, 2018 at 6:17 AM Yafang Shao wrote: > > There're are some code similar to tcp_queue_rcv() in tcp_ofo_queue(), > so refactor tcp_queue_rcv() to make it be used in tcp_ofo_queue(). > > After this change, skb->sk is set when skb is moved from ofo queue into > receive queue

Re: [PATCH net-next 2/2] tcp: refactor tcp_queue_rcv

Hi Yafang On Wed, Jul 11, 2018 at 6:17 AM Yafang Shao wrote: > > There're are some code similar to tcp_queue_rcv() in tcp_ofo_queue(), > so refactor tcp_queue_rcv() to make it be used in tcp_ofo_queue(). > > After this change, skb->sk is set when skb is moved from ofo queue into > receive queue

Re: [net-next,v3] tcp: Improve setsockopt() TCP_USER_TIMEOUT accuracy

On 07/10/2018 05:38 AM, Eric Dumazet wrote: > Note that if we always do jiffies_to_msecs(icsk->icsk_user_timeout) in TCP, > we also could change the convention and store msecs in this field instead of > jiffies. > > That would eliminate the msecs_to_jiffies() and jiffie

Re: [net-next,v3] tcp: Improve setsockopt() TCP_USER_TIMEOUT accuracy

On 07/10/2018 05:38 AM, Eric Dumazet wrote: > Note that if we always do jiffies_to_msecs(icsk->icsk_user_timeout) in TCP, > we also could change the convention and store msecs in this field instead of > jiffies. > > That would eliminate the msecs_to_jiffies() and jiffie

Re: [PATCH] tcp: Added check of destination specific CC before sending syn/ack

On 07/09/2018 04:25 AM, joakim.mis...@gmail.com wrote: > From: Joakim Misund > > Issue: > Currently TCP stack does not check for a destination specific CC before > responding to a syn with a syn/ack. > The system wide default CC is used. If the default CC does not need ECN, but > the

Re: [PATCH] tcp: Added check of destination specific CC before sending syn/ack

On 07/09/2018 04:25 AM, joakim.mis...@gmail.com wrote: > From: Joakim Misund > > Issue: > Currently TCP stack does not check for a destination specific CC before > responding to a syn with a syn/ack. > The system wide default CC is used. If the default CC does not need ECN, but > the

[tip:irq/core] genirq: Speedup show_interrupts()

Commit-ID: 74bdf7815dfb3805a37b0bba615814063a227bf5 Gitweb: https://git.kernel.org/tip/74bdf7815dfb3805a37b0bba615814063a227bf5 Author: Eric Dumazet AuthorDate: Wed, 20 Jun 2018 08:03:32 -0700 Committer: Thomas Gleixner CommitDate: Fri, 22 Jun 2018 14:22:58 +0200 genirq: Speedup

[tip:irq/core] genirq: Speedup show_interrupts()

Commit-ID: 74bdf7815dfb3805a37b0bba615814063a227bf5 Gitweb: https://git.kernel.org/tip/74bdf7815dfb3805a37b0bba615814063a227bf5 Author: Eric Dumazet AuthorDate: Wed, 20 Jun 2018 08:03:32 -0700 Committer: Thomas Gleixner CommitDate: Fri, 22 Jun 2018 14:22:58 +0200 genirq: Speedup

[PATCH] genirq: speedup show_interrupts()

t_irqs_cpu() and abuse irq_to_desc() while holding rcu read lock, since desc and desc->kstat_irqs wont disappear or change. Signed-off-by: Eric Dumazet --- kernel/irq/proc.c | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/kernel/irq/proc.c b/kernel/irq

[PATCH] genirq: speedup show_interrupts()

t_irqs_cpu() and abuse irq_to_desc() while holding rcu read lock, since desc and desc->kstat_irqs wont disappear or change. Signed-off-by: Eric Dumazet --- kernel/irq/proc.c | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/kernel/irq/proc.c b/kernel/irq

Re: [PATCH] Revert "net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends"

On 06/19/2018 05:13 PM, Michael Ellerman wrote: > Just so I'm clear, this turned out to be a driver/hw problem rather than > the arch csum implementation? Yes, that was a driver bug. I will send an official patch to fix this. You guys will have faster RX, since CHECKSUM_COMPLETE will

Re: [PATCH] Revert "net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends"

On 06/19/2018 05:13 PM, Michael Ellerman wrote: > Just so I'm clear, this turned out to be a driver/hw problem rather than > the arch csum implementation? Yes, that was a driver bug. I will send an official patch to fix this. You guys will have faster RX, since CHECKSUM_COMPLETE will

[tip:irq/core] genirq: Use rcu in kstat_irqs_usr()

Commit-ID: 4a5f4d2f891bcff7285b5f7490ed5a7a5d516049 Gitweb: https://git.kernel.org/tip/4a5f4d2f891bcff7285b5f7490ed5a7a5d516049 Author: Eric Dumazet AuthorDate: Mon, 18 Jun 2018 05:56:12 -0700 Committer: Thomas Gleixner CommitDate: Tue, 19 Jun 2018 09:19:40 +0200 genirq: Use rcu

[tip:irq/core] genirq: Use rcu in kstat_irqs_usr()

Commit-ID: 4a5f4d2f891bcff7285b5f7490ed5a7a5d516049 Gitweb: https://git.kernel.org/tip/4a5f4d2f891bcff7285b5f7490ed5a7a5d516049 Author: Eric Dumazet AuthorDate: Mon, 18 Jun 2018 05:56:12 -0700 Committer: Thomas Gleixner CommitDate: Tue, 19 Jun 2018 09:19:40 +0200 genirq: Use rcu

Re: [PATCH] Revert "net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends"

On 06/18/2018 04:29 PM, Eric Dumazet wrote: > > > On 06/18/2018 11:45 AM, Mathieu Malaterre wrote: > >> >> Here is what I get on my side >> >> [ 53.628847] sungem: sungem wrong csum : 4e04/f97, len 64 bytes >> [ 53.667063] sungem: su

Re: [PATCH] Revert "net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends"

On 06/18/2018 04:29 PM, Eric Dumazet wrote: > > > On 06/18/2018 11:45 AM, Mathieu Malaterre wrote: > >> >> Here is what I get on my side >> >> [ 53.628847] sungem: sungem wrong csum : 4e04/f97, len 64 bytes >> [ 53.667063] sungem: su

[PATCH] genirq: use rcu in kstat_irqs_usr()

pts() case will be handled in a separate patch. Signed-off-by: Eric Dumazet Reported-by: Jeremy Dorfman Cc: Thomas Gleixner Cc: Willem de Bruijn --- kernel/irq/irqdesc.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqde

[PATCH] genirq: use rcu in kstat_irqs_usr()

pts() case will be handled in a separate patch. Signed-off-by: Eric Dumazet Reported-by: Jeremy Dorfman Cc: Thomas Gleixner Cc: Willem de Bruijn --- kernel/irq/irqdesc.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqde

Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks

On 05/29/2018 11:44 PM, Eric Dumazet wrote: > > And I will add this simple fix, this really should address your initial > concern much better. > > @@ -99,6 +100,8 @@ static int mlx4_alloc_icm_pages(struct scatterlist *mem, > int order, > { >

Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks

On 05/29/2018 11:44 PM, Eric Dumazet wrote: > > And I will add this simple fix, this really should address your initial > concern much better. > > @@ -99,6 +100,8 @@ static int mlx4_alloc_icm_pages(struct scatterlist *mem, > int order, > { >

Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks

On 05/29/2018 11:34 PM, Eric Dumazet wrote: > I will test : > > diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c > b/drivers/net/ethernet/mellanox/mlx4/icm.c > index > 685337d58276fc91baeeb64387c52985e1bc6dda..4d2a71381acb739585d662175e86caef72338097 > 10064

Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks

On 05/29/2018 11:34 PM, Eric Dumazet wrote: > I will test : > > diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c > b/drivers/net/ethernet/mellanox/mlx4/icm.c > index > 685337d58276fc91baeeb64387c52985e1bc6dda..4d2a71381acb739585d662175e86caef72338097 > 10064

Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks

On 05/25/2018 10:23 AM, David Miller wrote: > From: Qing Huang > Date: Wed, 23 May 2018 16:22:46 -0700 > >> When a system is under memory presure (high usage with fragments), >> the original 256KB ICM chunk allocations will likely trigger kernel >> memory management to enter slow path doing

Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks

On 05/25/2018 10:23 AM, David Miller wrote: > From: Qing Huang > Date: Wed, 23 May 2018 16:22:46 -0700 > >> When a system is under memory presure (high usage with fragments), >> the original 256KB ICM chunk allocations will likely trigger kernel >> memory management to enter slow path doing

Re: [PATCH v2 net-next] tcp: use data length instead of skb->len in tcp_probe

On 05/29/2018 07:36 AM, Yafang Shao wrote: > On Tue, May 29, 2018 at 10:15 PM, David Miller wrote: >> From: Yafang Shao >> Date: Fri, 25 May 2018 18:14:05 +0800 >> >>> skb->len is meaningless to user. >>> data length could be more helpful, with which we can easily filter out >>> the packet

Re: [PATCH v2 net-next] tcp: use data length instead of skb->len in tcp_probe

On 05/29/2018 07:36 AM, Yafang Shao wrote: > On Tue, May 29, 2018 at 10:15 PM, David Miller wrote: >> From: Yafang Shao >> Date: Fri, 25 May 2018 18:14:05 +0800 >> >>> skb->len is meaningless to user. >>> data length could be more helpful, with which we can easily filter out >>> the packet

Re: [PATCH v3 net-next 2/2] tcp: minor optimization around tcp_hdr() usage in tcp receive path

On 05/28/2018 05:41 PM, Yafang Shao wrote: > OK. > > And what about introducing a new helper tcp_hdr_fast() ? > > /* use it when tcp header has not been pulled yet */ > static inline struct tcphdr *tcp_hdr_fast(const struct sk_buff *skb) > > { > > return (const struct tcphdr

Re: [PATCH v3 net-next 2/2] tcp: minor optimization around tcp_hdr() usage in tcp receive path

On 05/28/2018 05:41 PM, Yafang Shao wrote: > OK. > > And what about introducing a new helper tcp_hdr_fast() ? > > /* use it when tcp header has not been pulled yet */ > static inline struct tcphdr *tcp_hdr_fast(const struct sk_buff *skb) > > { > > return (const struct tcphdr

Re: [PATCH v3 net-next 2/2] tcp: minor optimization around tcp_hdr() usage in tcp receive path

On Mon, May 28, 2018 at 8:36 AM Yafang Shao <laoar.s...@gmail.com> wrote: > This is additional to the commit ea1627c20c34 ("tcp: minor optimizations around tcp_hdr() usage"). > At this point, skb->data is same with tcp_hdr() as tcp header has not > been pulled yet

Re: [PATCH v3 net-next 2/2] tcp: minor optimization around tcp_hdr() usage in tcp receive path

On Mon, May 28, 2018 at 8:36 AM Yafang Shao wrote: > This is additional to the commit ea1627c20c34 ("tcp: minor optimizations around tcp_hdr() usage"). > At this point, skb->data is same with tcp_hdr() as tcp header has not > been pulled yet. > Cc: Eric Dumazet >

Re: INFO: rcu detected stall in corrupted

On 05/21/2018 11:09 AM, David Miller wrote: > From: syzbot > Date: Mon, 21 May 2018 11:05:02 -0700 > >> find_match+0x244/0x13a0 net/ipv6/route.c:691 >> find_rr_leaf net/ipv6/route.c:729 [inline] >> rt6_select net/ipv6/route.c:779

Re: INFO: rcu detected stall in corrupted

On 05/21/2018 11:09 AM, David Miller wrote: > From: syzbot > Date: Mon, 21 May 2018 11:05:02 -0700 > >> find_match+0x244/0x13a0 net/ipv6/route.c:691 >> find_rr_leaf net/ipv6/route.c:729 [inline] >> rt6_select net/ipv6/route.c:779 [inline] > > Hmmm, endless loop in find_rr_leaf or similar?

Re: [PATCH] bpf: check NULL for sk_to_full_sk()

On 05/21/2018 12:55 AM, YueHaibing wrote: > like commit df39a9f106d5 ("bpf: check NULL for sk_to_full_sk() return value"), > we should check sk_to_full_sk return value against NULL. > > Signed-off-by: YueHaibing > --- > include/linux/bpf-cgroup.h | 2 +- > 1 file

Re: [PATCH] bpf: check NULL for sk_to_full_sk()

On 05/21/2018 12:55 AM, YueHaibing wrote: > like commit df39a9f106d5 ("bpf: check NULL for sk_to_full_sk() return value"), > we should check sk_to_full_sk return value against NULL. > > Signed-off-by: YueHaibing > --- > include/linux/bpf-cgroup.h | 2 +- > 1 file changed, 1 insertion(+), 1

Re: INFO: rcu detected stall in is_bpf_text_address

SCTP experts, please take a look. On 05/19/2018 08:55 AM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:    73fcb1a370c7 Merge branch 'akpm' (patches from Andrew) > git tree:   upstream > console output:

Re: INFO: rcu detected stall in is_bpf_text_address

SCTP experts, please take a look. On 05/19/2018 08:55 AM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:    73fcb1a370c7 Merge branch 'akpm' (patches from Andrew) > git tree:   upstream > console output:

Re: WARNING in ip_recv_error

On 05/18/2018 05:08 AM, DaeRyong Jeong wrote: > We report the crash: WARNING in ip_recv_error > (I resend the email since I mistakenly missed the subject in my previous > email. I'm sorry.) > > > This crash has been found in v4.17-rc1 using RaceFuzzer (a modified > version of Syzkaller), which

Re: WARNING in ip_recv_error

On 05/18/2018 05:08 AM, DaeRyong Jeong wrote: > We report the crash: WARNING in ip_recv_error > (I resend the email since I mistakenly missed the subject in my previous > email. I'm sorry.) > > > This crash has been found in v4.17-rc1 using RaceFuzzer (a modified > version of Syzkaller), which

Re: [PATCH v3] mlx4_core: allocate ICM memory in page size chunks

On 05/17/2018 01:53 PM, Qing Huang wrote: > When a system is under memory presure (high usage with fragments), > the original 256KB ICM chunk allocations will likely trigger kernel > memory management to enter slow path doing memory compact/migration > ops in order to complete high order memory

Re: [PATCH v3] mlx4_core: allocate ICM memory in page size chunks

On 05/17/2018 01:53 PM, Qing Huang wrote: > When a system is under memory presure (high usage with fragments), > the original 256KB ICM chunk allocations will likely trigger kernel > memory management to enter slow path doing memory compact/migration > ops in order to complete high order memory

Re: [PATCH V2] mlx4_core: allocate ICM memory in page size chunks

On 05/15/2018 11:53 AM, Qing Huang wrote: > >> This is control path so it is less latency-sensitive. >> Let's not produce unnecessary degradation here, please call kvzalloc so we >> maintain a similar behavior when contiguous memory is available, and a >> fallback for resiliency. > > No sure

Re: [PATCH V2] mlx4_core: allocate ICM memory in page size chunks

On 05/15/2018 11:53 AM, Qing Huang wrote: > >> This is control path so it is less latency-sensitive. >> Let's not produce unnecessary degradation here, please call kvzalloc so we >> maintain a similar behavior when contiguous memory is available, and a >> fallback for resiliency. > > No sure

Re: [PATCH v2] {net, IB}/mlx5: Use 'kvfree()' for memory allocated by 'kvzalloc()'

On 05/13/2018 12:00 AM, Christophe JAILLET wrote: > When 'kvzalloc()' is used to allocate memory, 'kvfree()' must be used to > free it. > > Signed-off-by: Christophe JAILLET > --- > v1 -> v2: More places to update have been added to the patch Please add

Re: [PATCH v2] {net, IB}/mlx5: Use 'kvfree()' for memory allocated by 'kvzalloc()'

On 05/13/2018 12:00 AM, Christophe JAILLET wrote: > When 'kvzalloc()' is used to allocate memory, 'kvfree()' must be used to > free it. > > Signed-off-by: Christophe JAILLET > --- > v1 -> v2: More places to update have been added to the patch Please add relevant Fixes: tag(s)

Re: INFO: rcu detected stall in kfree_skbmem

On 05/11/2018 11:41 AM, Marcelo Ricardo Leitner wrote: > But calling ip6_xmit with rcu_read_lock is expected. tcp stack also > does it. > Thus I think this is more of an issue with IPv6 stack. If a host has > an extensive ip6tables ruleset, it probably generates this more > easily. > >>>

Re: INFO: rcu detected stall in kfree_skbmem

On 05/11/2018 11:41 AM, Marcelo Ricardo Leitner wrote: > But calling ip6_xmit with rcu_read_lock is expected. tcp stack also > does it. > Thus I think this is more of an issue with IPv6 stack. If a host has > an extensive ip6tables ruleset, it probably generates this more > easily. > >>>

Re: [PATCH 14/32] net/tcp: convert to ->poll_mask

On 05/11/2018 04:07 AM, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > --- > include/net/tcp.h | 4 ++-- > net/ipv4/af_inet.c | 3 ++- > net/ipv4/tcp.c | 31 ++- > net/ipv6/af_inet6.c | 3 ++- > 4 files changed, 20

Re: [PATCH 14/32] net/tcp: convert to ->poll_mask

On 05/11/2018 04:07 AM, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > --- > include/net/tcp.h | 4 ++-- > net/ipv4/af_inet.c | 3 ++- > net/ipv4/tcp.c | 31 ++- > net/ipv6/af_inet6.c | 3 ++- > 4 files changed, 20 insertions(+), 21

Re: [PATCH net-next v2] tcp: Add mark for TIMEWAIT sockets

On 05/09/2018 11:53 PM, Jon Maxwell wrote: > This version has some suggestions by Eric Dumazet: > > - Use a local variable for the mark in IPv6 instead of ctl_sk to avoid SMP > races. > - Use the more elegant "IP4_REPLY_MARK(net, skb->mark) ?: sk->sk_mark" &

Re: [PATCH net-next v2] tcp: Add mark for TIMEWAIT sockets

On 05/09/2018 11:53 PM, Jon Maxwell wrote: > This version has some suggestions by Eric Dumazet: > > - Use a local variable for the mark in IPv6 instead of ctl_sk to avoid SMP > races. > - Use the more elegant "IP4_REPLY_MARK(net, skb->mark) ?: sk->sk_mark" &

Re: [PATCH net-next v1] tcp: Add mark for TIMEWAIT sockets

On 05/09/2018 10:21 PM, Jon Maxwell wrote: ... > if (th->rst) > @@ -723,11 +724,17 @@ static void tcp_v4_send_reset(const struct sock *sk, > struct sk_buff *skb) > arg.tos = ip_hdr(skb)->tos; > arg.uid = sock_net_uid(net, sk && sk_fullsock(sk) ? sk : NULL); >

Re: [PATCH net-next v1] tcp: Add mark for TIMEWAIT sockets

On 05/09/2018 10:21 PM, Jon Maxwell wrote: ... > if (th->rst) > @@ -723,11 +724,17 @@ static void tcp_v4_send_reset(const struct sock *sk, > struct sk_buff *skb) > arg.tos = ip_hdr(skb)->tos; > arg.uid = sock_net_uid(net, sk && sk_fullsock(sk) ? sk : NULL); >

Re: [PATCH net-next] tcp: Add mark for TIMEWAIT sockets

On 05/09/2018 07:07 PM, Jon Maxwell wrote: > Aidan McGurn from Openwave Mobility systems reported the following bug: > > "Marked routing is broken on customer deployment. Its effects are large > increase in Uplink retransmissions caused by the client never receiving > the final ACK to their

Re: [PATCH net-next] tcp: Add mark for TIMEWAIT sockets

On 05/09/2018 07:07 PM, Jon Maxwell wrote: > Aidan McGurn from Openwave Mobility systems reported the following bug: > > "Marked routing is broken on customer deployment. Its effects are large > increase in Uplink retransmissions caused by the client never receiving > the final ACK to their

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

On 05/09/2018 12:21 PM, Willem de Bruijn wrote: > Indeed. The skb shared info struct is zeroed by dev_validate_header > as a result of dev->hard_header_len exceeding skb->end - skb->data. > > Not exactly sure yet how this can happen. The hard header length space > is accounted for during

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

On 05/09/2018 12:21 PM, Willem de Bruijn wrote: > Indeed. The skb shared info struct is zeroed by dev_validate_header > as a result of dev->hard_header_len exceeding skb->end - skb->data. > > Not exactly sure yet how this can happen. The hard header length space > is accounted for during

Re: BUG: spinlock bad magic in tun_do_read

On 05/07/2018 10:54 PM, Cong Wang wrote: > On Mon, May 7, 2018 at 10:27 PM, syzbot > wrote: >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit:75bc37fefc44 Linux 4.17-rc4 >> git tree: upstream >> console

Re: BUG: spinlock bad magic in tun_do_read

On 05/07/2018 10:54 PM, Cong Wang wrote: > On Mon, May 7, 2018 at 10:27 PM, syzbot > wrote: >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit:75bc37fefc44 Linux 4.17-rc4 >> git tree: upstream >> console output:

Re: [PATCH] net: 8390: Fix possible data races in __ei_get_stats

On 05/07/2018 07:16 PM, Jia-Ju Bai wrote: > Yes, ">stats" will not change, because it is a fixed address. > But the field data in "dev->stats" is changed (rx_frame_errors, rx_crc_errors > and rx_missed_errors). > So if the driver returns ">stats" without lock protection (like on line > 858),

Re: [PATCH] net: 8390: Fix possible data races in __ei_get_stats

On 05/07/2018 07:16 PM, Jia-Ju Bai wrote: > Yes, ">stats" will not change, because it is a fixed address. > But the field data in "dev->stats" is changed (rx_frame_errors, rx_crc_errors > and rx_missed_errors). > So if the driver returns ">stats" without lock protection (like on line > 858),

Re: [PATCH] net: 8390: Fix possible data races in __ei_get_stats

On 05/07/2018 05:51 PM, Jia-Ju Bai wrote: > > > On 2018/5/7 22:15, Eric Dumazet wrote: >> >> On 05/07/2018 07:08 AM, Jia-Ju Bai wrote: >>> The write operations to "dev->stats" are protected by >>> the spinlock on line 862-864, but the

Re: [PATCH] net: 8390: Fix possible data races in __ei_get_stats

On 05/07/2018 05:51 PM, Jia-Ju Bai wrote: > > > On 2018/5/7 22:15, Eric Dumazet wrote: >> >> On 05/07/2018 07:08 AM, Jia-Ju Bai wrote: >>> The write operations to "dev->stats" are protected by >>> the spinlock on line 862-864, but the

Re: [PATCH] net: 8390: Fix possible data races in __ei_get_stats

On 05/07/2018 07:08 AM, Jia-Ju Bai wrote: > The write operations to "dev->stats" are protected by > the spinlock on line 862-864, but the read operations to > this data on line 858 and 867 are not protected by the spinlock. > Thus, there may exist data races for "dev->stats". > > To fix the

Re: [PATCH] net: 8390: Fix possible data races in __ei_get_stats

On 05/07/2018 07:08 AM, Jia-Ju Bai wrote: > The write operations to "dev->stats" are protected by > the spinlock on line 862-864, but the read operations to > this data on line 858 and 867 are not protected by the spinlock. > Thus, there may exist data races for "dev->stats". > > To fix the

Re: WARNING in kernfs_add_one

On 05/05/2018 09:40 AM, Greg KH wrote: > On Sat, May 05, 2018 at 08:47:02AM -0700, syzbot wrote: >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit:8fb11a9a8d51 net/ipv6: rename rt6_next to fib6_next >> git tree: net-next >> console output:

Re: WARNING in kernfs_add_one

On 05/05/2018 09:40 AM, Greg KH wrote: > On Sat, May 05, 2018 at 08:47:02AM -0700, syzbot wrote: >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit:8fb11a9a8d51 net/ipv6: rename rt6_next to fib6_next >> git tree: net-next >> console output:

Re: [PATCH] net: disable UDP punt on sockets in RCV_SHUTDWON

On 05/04/2018 02:08 PM, Chintan Shah wrote: > A UDP application which opens multiple sockets with same local > address/port combination (using SO_REUSEPORT/SO_REUSEADDR socket options); > and issues connect to a remote socket (using one of these local socket). > Now if the same socket, which

Re: [PATCH] net: disable UDP punt on sockets in RCV_SHUTDWON

On 05/04/2018 02:08 PM, Chintan Shah wrote: > A UDP application which opens multiple sockets with same local > address/port combination (using SO_REUSEPORT/SO_REUSEADDR socket options); > and issues connect to a remote socket (using one of these local socket). > Now if the same socket, which

[PATCH v4 net-next 2/2] selftests: net: tcp_mmap must use TCP_ZEROCOPY_RECEIVE

number of bytes that should be read using conventional read()/recv()/recvmsg() system calls, to skip a sequence of bytes that can not be mapped, because not properly page aligned. Signed-off-by: Eric Dumazet <eduma...@google.com> Cc: Andy Lutomirski <l...@kernel.org> Acked-by: Soheil Ha

[PATCH v4 net-next 2/2] selftests: net: tcp_mmap must use TCP_ZEROCOPY_RECEIVE

number of bytes that should be read using conventional read()/recv()/recvmsg() system calls, to skip a sequence of bytes that can not be mapped, because not properly page aligned. Signed-off-by: Eric Dumazet Cc: Andy Lutomirski Acked-by: Soheil Hassas Yeganeh --- tools/testing/selftests/net

[PATCH v4 net-next 0/2] tcp: mmap: rework zerocopy receive

p_hint in case user request was completed. Eric Dumazet (2): tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive selftests: net: tcp_mmap must use TCP_ZEROCOPY_RECEIVE include/uapi/linux/tcp.h | 8 + net/ipv4/af_inet.c | 2 + net/ipv4

[PATCH v4 net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive

use of mmap() and setsockopt(... TCP_ZEROCOPY_RECEIVE ...) Note that memcg might require additional changes. Fixes: 93ab6cc69162 ("tcp: implement mmap() for zero copy receive") Signed-off-by: Eric Dumazet <eduma...@google.com> Reported-by: syzbot <syzkal...@googlegroups.com>

<    1   2   3   4   5   6   7   8   9   10   >