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

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

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 allow users fine-control > > on > > systems with multiple NICs with different GSO buffer sizes, and > > where > > the virtual devices like bridge and veth,

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

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 allow users fine-control > > on > > systems with multiple NICs with different GSO buffer sizes, and > > where > > the virtual devices like bridge and veth,

Re: [PATCH net v2] net: thunderx: Fix TCP/UDP checksum offload for IPv6 pkts

<sgout...@cavium.com> > Signed-off-by: Aleksey Makarov <aleksey.maka...@auriga.com> > --- >  drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 1 - >  1 file changed, 1 deletion(-) > > v2: > - Don't enable checksum offloading both for IPv4 and IPv6 (Eric >

Re: [PATCH net v2] net: thunderx: Fix TCP/UDP checksum offload for IPv6 pkts

leksey Makarov > --- >  drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 1 - >  1 file changed, 1 deletion(-) > > v2: > - Don't enable checksum offloading both for IPv4 and IPv6 (Eric > Dumazet) > > v1: >   https://lkml.kernel.org/r/20171122123727.23580-1-a

Re: [PATCH net] net: thunderx: Fix TCP/UDP checksum offload for IPv6 pkts

On Wed, 2017-11-22 at 15:37 +0300, Aleksey Makarov wrote: > From: Sunil Goutham > > This fixes a previous patch which missed some changes > and due to which L3 checksum offload was getting enabled > for IPv6 pkts. And HW is dropping these pkts as it assumes > the pkt is IPv4

Re: [PATCH net] net: thunderx: Fix TCP/UDP checksum offload for IPv6 pkts

On Wed, 2017-11-22 at 15:37 +0300, Aleksey Makarov wrote: > From: Sunil Goutham > > This fixes a previous patch which missed some changes > and due to which L3 checksum offload was getting enabled > for IPv6 pkts. And HW is dropping these pkts as it assumes > the pkt is IPv4 when IP csum offload

Re: [PATCH][net-next] tcp: remove the now redundant non-null check on tskb

On Tue, 2017-11-14 at 18:41 +, Colin King wrote: > From: Colin Ian King > > The non-null check on tskb is redundant as it is in an else > section of a check on tskb where tskb is always null. Remove > the redundant if statement and the label coalesce. > > Detected

Re: [PATCH][net-next] tcp: remove the now redundant non-null check on tskb

On Tue, 2017-11-14 at 18:41 +, Colin King wrote: > From: Colin Ian King > > The non-null check on tskb is redundant as it is in an else > section of a check on tskb where tskb is always null. Remove > the redundant if statement and the label coalesce. > > Detected by CoverityScan,

Re: [PATCH] net: Convert net_mutex into rw_semaphore and down read it on net->init/->exit

On Tue, 2017-11-14 at 10:11 -0800, Stephen Hemminger wrote: > On Tue, 14 Nov 2017 16:53:33 +0300 > Kirill Tkhai wrote: > > > + /* > > +* RCU-protected list, modifiable by pernet-init and -exit methods. > > +* When net namespace is alive (net::count > 0), all the

Re: [PATCH] net: Convert net_mutex into rw_semaphore and down read it on net->init/->exit

On Tue, 2017-11-14 at 10:11 -0800, Stephen Hemminger wrote: > On Tue, 14 Nov 2017 16:53:33 +0300 > Kirill Tkhai wrote: > > > + /* > > +* RCU-protected list, modifiable by pernet-init and -exit methods. > > +* When net namespace is alive (net::count > 0), all the changes > > +* are

Re: [PATCH] net: Convert net_mutex into rw_semaphore and down read it on net->init/->exit

On Tue, 2017-11-14 at 09:44 -0800, Andrei Vagin wrote: > On Tue, Nov 14, 2017 at 04:53:33PM +0300, Kirill Tkhai wrote: > > Curently mutex is used to protect pernet operations list. It makes > > cleanup_net() to execute ->exit methods of the same operations set, > > which was used on the time of

Re: [PATCH] net: Convert net_mutex into rw_semaphore and down read it on net->init/->exit

On Tue, 2017-11-14 at 09:44 -0800, Andrei Vagin wrote: > On Tue, Nov 14, 2017 at 04:53:33PM +0300, Kirill Tkhai wrote: > > Curently mutex is used to protect pernet operations list. It makes > > cleanup_net() to execute ->exit methods of the same operations set, > > which was used on the time of

Re: [PATCH] net: Convert net_mutex into rw_semaphore and down read it on net->init/->exit

On Tue, 2017-11-14 at 16:53 +0300, Kirill Tkhai wrote: > Curently mutex is used to protect pernet operations list. It makes > cleanup_net() to execute ->exit methods of the same operations set, > which was used on the time of ->init, even after net namespace is > unlinked from net_namespace_list.

Re: [PATCH] net: Convert net_mutex into rw_semaphore and down read it on net->init/->exit

On Tue, 2017-11-14 at 16:53 +0300, Kirill Tkhai wrote: > Curently mutex is used to protect pernet operations list. It makes > cleanup_net() to execute ->exit methods of the same operations set, > which was used on the time of ->init, even after net namespace is > unlinked from net_namespace_list.

Re: [PATCH net-next 2/2] tcp: handle TCP_TIME_WAIT/TCP_NEW_SYN_RECV in tcp_set_state tracepoint

On Thu, 2017-11-09 at 23:11 +0800, Yafang Shao wrote: > I'm also very sad that I'm still using IPv4 in 2017 : ( > > Okay then another issue, > shoule we reduce the complexity in the function tcp4_seq_show() ? This is irrelevant really. I do not see how tcp4_seq_show() could avoid testing

Re: [PATCH net-next 2/2] tcp: handle TCP_TIME_WAIT/TCP_NEW_SYN_RECV in tcp_set_state tracepoint

On Thu, 2017-11-09 at 23:11 +0800, Yafang Shao wrote: > I'm also very sad that I'm still using IPv4 in 2017 : ( > > Okay then another issue, > shoule we reduce the complexity in the function tcp4_seq_show() ? This is irrelevant really. I do not see how tcp4_seq_show() could avoid testing

Re: [PATCH net-next 2/2] tcp: handle TCP_TIME_WAIT/TCP_NEW_SYN_RECV in tcp_set_state tracepoint

On Thu, 2017-11-09 at 06:52 -0800, Eric Dumazet wrote: > Wow. > > > Since all three variants of sockets (full sockets, request sockets, > timewait sockets) are all hashed into ehash table these days, they all > have the fields at the same offset > &

Re: [PATCH net-next 2/2] tcp: handle TCP_TIME_WAIT/TCP_NEW_SYN_RECV in tcp_set_state tracepoint

On Thu, 2017-11-09 at 06:52 -0800, Eric Dumazet wrote: > Wow. > > > Since all three variants of sockets (full sockets, request sockets, > timewait sockets) are all hashed into ehash table these days, they all > have the fields at the same offset > &

Re: [PATCH net-next 2/2] tcp: handle TCP_TIME_WAIT/TCP_NEW_SYN_RECV in tcp_set_state tracepoint

On Thu, 2017-11-09 at 14:26 +, Yafang Shao wrote: > When TCP connetion in TCP_TIME_WAIT or TCP_NEW_SYN_RECV state, it can't > get the sport/dport/saddr/daddr from inet_sock. > > trace_tcp_set_state may be called when the oldstate in these two states. > > Signed-off-by: Yafang Shao

Re: [PATCH net-next 2/2] tcp: handle TCP_TIME_WAIT/TCP_NEW_SYN_RECV in tcp_set_state tracepoint

On Thu, 2017-11-09 at 14:26 +, Yafang Shao wrote: > When TCP connetion in TCP_TIME_WAIT or TCP_NEW_SYN_RECV state, it can't > get the sport/dport/saddr/daddr from inet_sock. > > trace_tcp_set_state may be called when the oldstate in these two states. > > Signed-off-by: Yafang Shao > --- >

Re: IPv6 issue in next-20171102 - lockdep and BUG handling RA packet.

On Mon, Nov 6, 2017 at 4:29 PM, David Ahern wrote: > On 11/7/17 5:56 AM, valdis.kletni...@vt.edu wrote: >> I've hit this 6 times now, across 3 boots: >> >> Nov 3 11:04:54 turing-police kernel: [ 547.814748] BUG: sleeping function >> called from invalid context at

Re: IPv6 issue in next-20171102 - lockdep and BUG handling RA packet.

On Mon, Nov 6, 2017 at 4:29 PM, David Ahern wrote: > On 11/7/17 5:56 AM, valdis.kletni...@vt.edu wrote: >> I've hit this 6 times now, across 3 boots: >> >> Nov 3 11:04:54 turing-police kernel: [ 547.814748] BUG: sleeping function >> called from invalid context at mm/slab.h:422 >> >> Nov 3

Re: IPv6 issue in next-20171102 - lockdep and BUG handling RA packet.

On Mon, Nov 6, 2017 at 2:04 PM, Eric Dumazet <eduma...@google.com> wrote: > I have a patch, will send in a couple of minutes. Thanks. https://patchwork.ozlabs.org/patch/834983/ ipv6: addrconf: fix a lockdep splat

Re: IPv6 issue in next-20171102 - lockdep and BUG handling RA packet.

On Mon, Nov 6, 2017 at 2:04 PM, Eric Dumazet wrote: > I have a patch, will send in a couple of minutes. Thanks. https://patchwork.ozlabs.org/patch/834983/ ipv6: addrconf: fix a lockdep splat

Re: IPv6 issue in next-20171102 - lockdep and BUG handling RA packet.

On Mon, Nov 6, 2017 at 2:01 PM, Ido Schimmel wrote: > On Mon, Nov 06, 2017 at 03:56:54PM -0500, valdis.kletni...@vt.edu wrote: >> I've hit this 6 times now, across 3 boots: >> >> Nov 3 11:04:54 turing-police kernel: [ 547.814748] BUG: sleeping function >> called from invalid

Re: IPv6 issue in next-20171102 - lockdep and BUG handling RA packet.

On Mon, Nov 6, 2017 at 2:01 PM, Ido Schimmel wrote: > On Mon, Nov 06, 2017 at 03:56:54PM -0500, valdis.kletni...@vt.edu wrote: >> I've hit this 6 times now, across 3 boots: >> >> Nov 3 11:04:54 turing-police kernel: [ 547.814748] BUG: sleeping function >> called from invalid context at

Re: WARNING: at net/core/stream.c:204

On Thu, 2017-11-02 at 08:36 -0400, Shankara Pailoor wrote: > Hi, > > We encountered the following warning when fuzzing with Syzkaller on > Linux 4.14-rc4. Syzkaller was able to isolate the sequence of calls > which caused the bug but couldn't create a C program that could > regularly trigger it.

Re: WARNING: at net/core/stream.c:204

On Thu, 2017-11-02 at 08:36 -0400, Shankara Pailoor wrote: > Hi, > > We encountered the following warning when fuzzing with Syzkaller on > Linux 4.14-rc4. Syzkaller was able to isolate the sequence of calls > which caused the bug but couldn't create a C program that could > regularly trigger it.

Re: [PATCH] tcp_nv: fix division by zero in tcpnv_acked()

On Wed, 2017-11-01 at 16:32 +0300, Konstantin Khlebnikov wrote: > Average RTT could become zero. This happened in real life at least twice. > This patch treats zero as 1us. > > Signed-off-by: Konstantin Khlebnikov > --- > net/ipv4/tcp_nv.c |2 +- > 1 file changed,

Re: [PATCH] tcp_nv: fix division by zero in tcpnv_acked()

On Wed, 2017-11-01 at 16:32 +0300, Konstantin Khlebnikov wrote: > Average RTT could become zero. This happened in real life at least twice. > This patch treats zero as 1us. > > Signed-off-by: Konstantin Khlebnikov > --- > net/ipv4/tcp_nv.c |2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH] net: recvmsg: Unconditionally zero struct sockaddr_storage

On Tue, 2017-10-31 at 09:14 -0700, Kees Cook wrote: > Some protocols do not correctly wipe the contents of the on-stack > struct sockaddr_storage sent down into recvmsg() (e.g. SCTP), and leak > kernel stack contents to userspace. This wipes it unconditionally before > per-protocol handlers run. >

Re: [PATCH] net: recvmsg: Unconditionally zero struct sockaddr_storage

On Tue, 2017-10-31 at 09:14 -0700, Kees Cook wrote: > Some protocols do not correctly wipe the contents of the on-stack > struct sockaddr_storage sent down into recvmsg() (e.g. SCTP), and leak > kernel stack contents to userspace. This wipes it unconditionally before > per-protocol handlers run. >

Re: [PATCH net-next 3/4] hv_netvsc: reset net_device_ctx->nvdev with rcu_assign_pointer()

On Tue, 2017-10-31 at 14:42 +0100, Vitaly Kuznetsov wrote: > RCU_INIT_POINTER() is not suitable here as it doesn't give us ordering > guarantees (see the comment in rcupdate.h). This is also not a hotpath. > > Signed-off-by: Vitaly Kuznetsov > --- >

Re: [PATCH net-next 3/4] hv_netvsc: reset net_device_ctx->nvdev with rcu_assign_pointer()

On Tue, 2017-10-31 at 14:42 +0100, Vitaly Kuznetsov wrote: > RCU_INIT_POINTER() is not suitable here as it doesn't give us ordering > guarantees (see the comment in rcupdate.h). This is also not a hotpath. > > Signed-off-by: Vitaly Kuznetsov > --- > drivers/net/hyperv/netvsc.c | 2 +- > 1 file

Re: linux-next: Signed-off-by missing for commit in the net-next tree

On Tue, 2017-10-31 at 09:14 +0300, Kirill Smelkov wrote: > Francois, > > On Tue, Oct 31, 2017 at 04:40:19PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > Commit > > > > 509708310cf9 ("r8169: Add support for interrupt coalesce tuning (ethtool > > -C)") > > > > is missing a Signed-off-by

Re: linux-next: Signed-off-by missing for commit in the net-next tree

On Tue, 2017-10-31 at 09:14 +0300, Kirill Smelkov wrote: > Francois, > > On Tue, Oct 31, 2017 at 04:40:19PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > Commit > > > > 509708310cf9 ("r8169: Add support for interrupt coalesce tuning (ethtool > > -C)") > > > > is missing a Signed-off-by

Re: KASAN: use-after-free Write in detach_if_pending

On Mon, 2017-10-30 at 20:52 +0300, Dmitry Vyukov wrote: > syz fix: patch title > > then that's doable. If we agree on this format, then I am ready to > implement this. Yes please. David Miller and Linus never rebase their trees, for good reasons.

Re: KASAN: use-after-free Write in detach_if_pending

On Mon, 2017-10-30 at 20:52 +0300, Dmitry Vyukov wrote: > syz fix: patch title > > then that's doable. If we agree on this format, then I am ready to > implement this. Yes please. David Miller and Linus never rebase their trees, for good reasons.

Re: KASAN: use-after-free Write in detach_if_pending

On Mon, 2017-10-30 at 18:40 +0100, Dmitry Vyukov wrote: > On Mon, Oct 30, 2017 at 6:30 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > > On Mon, 2017-10-30 at 18:06 +0100, Dmitry Vyukov wrote: > > > >> Yes, but hashes in random trees also don't tell much. A tree c

Re: KASAN: use-after-free Write in detach_if_pending

On Mon, 2017-10-30 at 18:40 +0100, Dmitry Vyukov wrote: > On Mon, Oct 30, 2017 at 6:30 PM, Eric Dumazet wrote: > > On Mon, 2017-10-30 at 18:06 +0100, Dmitry Vyukov wrote: > > > >> Yes, but hashes in random trees also don't tell much. A tree can be > >> rebased

Re: KASAN: use-after-free Write in detach_if_pending

On Mon, 2017-10-30 at 18:06 +0100, Dmitry Vyukov wrote: > Yes, but hashes in random trees also don't tell much. A tree can be > rebased so the hash will be lost. It can be a tree unknown to the > system. Even if we find the commit by hash, in order to match it > against other trees we will have

Re: KASAN: use-after-free Write in detach_if_pending

On Mon, 2017-10-30 at 18:06 +0100, Dmitry Vyukov wrote: > Yes, but hashes in random trees also don't tell much. A tree can be > rebased so the hash will be lost. It can be a tree unknown to the > system. Even if we find the commit by hash, in order to match it > against other trees we will have

Re: KASAN: use-after-free Write in detach_if_pending

On Mon, 2017-10-30 at 16:48 +0100, Dmitry Vyukov wrote: > > > > net-next tree : > > > > $ git log --oneline e7989f973ae1b90ec7c0b671c81.. -- drivers/net/tun.c > > f8ddadc4db6c7b7029b6d0e0d9af24f74ad27ca2 Merge > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net > >

Re: KASAN: use-after-free Write in detach_if_pending

On Mon, 2017-10-30 at 16:48 +0100, Dmitry Vyukov wrote: > > > > net-next tree : > > > > $ git log --oneline e7989f973ae1b90ec7c0b671c81.. -- drivers/net/tun.c > > f8ddadc4db6c7b7029b6d0e0d9af24f74ad27ca2 Merge > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net > >

Re: KASAN: use-after-free Write in detach_if_pending

On Sun, 2017-10-29 at 13:45 +0100, Thomas Gleixner wrote: > On Fri, 27 Oct 2017, syzbot wrote: > > Cc'ed network folks. > > > syzkaller hit the following crash on > > e7989f973ae1b90ec7c0b671c81f7f553affccbe > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > >

Re: KASAN: use-after-free Write in detach_if_pending

On Sun, 2017-10-29 at 13:45 +0100, Thomas Gleixner wrote: > On Fri, 27 Oct 2017, syzbot wrote: > > Cc'ed network folks. > > > syzkaller hit the following crash on > > e7989f973ae1b90ec7c0b671c81f7f553affccbe > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > >

Re: WARNING in refcount_sub_and_test

On Fri, 2017-10-27 at 08:09 +0200, Dmitry Vyukov wrote: > Yes, I've noticed this one. It seems to happen on a first incoming > network connection (ssh/scp). I have not seen it before.

Re: WARNING in refcount_sub_and_test

On Fri, 2017-10-27 at 08:09 +0200, Dmitry Vyukov wrote: > Yes, I've noticed this one. It seems to happen on a first incoming > network connection (ssh/scp). I have not seen it before.

Re: [PATCH net] tuntap: properly align skb->head before building skb

ed for accessing on some architecture. Fix this by aligning > alloc_frag->offset before the frag refilling. > > Fixes: 0bbd7dad34f8 ("tun: make tun_build_skb() thread safe") > Cc: Eric Dumazet <eduma...@google.com> > Cc: Willem de Bruijn <willemdebruijn.ker.

Re: [PATCH net] tuntap: properly align skb->head before building skb

architecture. Fix this by aligning > alloc_frag->offset before the frag refilling. > > Fixes: 0bbd7dad34f8 ("tun: make tun_build_skb() thread safe") > Cc: Eric Dumazet > Cc: Willem de Bruijn > Cc: Wei Wei > Cc: Dmitry Vyukov > Cc: Mark Rutland > Reported-by:

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

On Wed, Oct 25, 2017 at 11:49 AM, Willem de Bruijn wrote: > From skb->dev and netdev_priv, the tun device has flags 0x1002 == > IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for > IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened >

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

On Wed, Oct 25, 2017 at 11:49 AM, Willem de Bruijn wrote: > From skb->dev and netdev_priv, the tun device has flags 0x1002 == > IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for > IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened > in tun_build_skb from

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

add%al,(%rax) > ... > > Code starting with the faulting instruction > === > 0: 01 7c 5f 88 add%edi,-0x78(%rdi,%rbx,2) >4: 00 00 add%al,(%rax) > ... > —[ end trac

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

) > ... > > Code starting with the faulting instruction > === > 0: 01 7c 5f 88 add%edi,-0x78(%rdi,%rbx,2) >4: 00 00 add%al,(%rax) > ... > —[ end trace 261e7ac1458ccc0a ]-

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

On Thu, Oct 19, 2017 at 7:16 PM, Wei Wei wrote: > Hi all, > > I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one > [1]. > But the call trace isn’t the same. The atomic_inc() might handle a corrupted > skb_buff. > > The logs and config have been

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

On Thu, Oct 19, 2017 at 7:16 PM, Wei Wei wrote: > Hi all, > > I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one > [1]. > But the call trace isn’t the same. The atomic_inc() might handle a corrupted > skb_buff. > > The logs and config have been uploaded to my github repo

Re: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

On Wed, 2017-10-18 at 18:57 +0100, Ard Biesheuvel wrote: > On 18 October 2017 at 17:29, Eric Dumazet <eric.duma...@gmail.com> wrote: > > On Wed, 2017-10-18 at 16:45 +0100, Ard Biesheuvel wrote: > >> Even though calling dql_completed() with a count that exceeds the > &

Re: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

On Wed, 2017-10-18 at 18:57 +0100, Ard Biesheuvel wrote: > On 18 October 2017 at 17:29, Eric Dumazet wrote: > > On Wed, 2017-10-18 at 16:45 +0100, Ard Biesheuvel wrote: > >> Even though calling dql_completed() with a count that exceeds the > >> queued count is a s

Re: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

On Wed, 2017-10-18 at 16:45 +0100, Ard Biesheuvel wrote: > Even though calling dql_completed() with a count that exceeds the > queued count is a serious error, it still does not justify bringing > down the entire kernel with a BUG_ON(). So relax it to a WARN_ON() > instead. > > Signed-off-by: Ard

Re: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

On Wed, 2017-10-18 at 16:45 +0100, Ard Biesheuvel wrote: > Even though calling dql_completed() with a count that exceeds the > queued count is a serious error, it still does not justify bringing > down the entire kernel with a BUG_ON(). So relax it to a WARN_ON() > instead. > > Signed-off-by: Ard

Re: [PATCH] net: export netdev_txq_to_tc to allow sch_mqprio to compile as module

_queue) is also EXPORT_SYMBOL() (and not _GPL) or in a > sysfs-callback. > > Cc: Alexander Duyck <alexander.h.du...@intel.com> > Cc: Jesus Sanchez-Palencia <jesus.sanchez-palen...@intel.com> > Cc: David S. Miller <da...@davemloft.net> > Signed-off-by: Henrik Austad <haus...@cisco.com> Reviewed-by: Eric Dumazet <eduma...@google.com>

Re: [PATCH] net: export netdev_txq_to_tc to allow sch_mqprio to compile as module

SYMBOL() (and not _GPL) or in a > sysfs-callback. > > Cc: Alexander Duyck > Cc: Jesus Sanchez-Palencia > Cc: David S. Miller > Signed-off-by: Henrik Austad Reviewed-by: Eric Dumazet

Re: [lkp-robot] [ipv6] 2b760fcf5c: WARNING:suspicious_RCU_usage

On Thu, Oct 12, 2017 at 10:09 PM, Wei Wang wrote: > > This warning should be fixed by later commit 66f5d6ce53e6 ("ipv6: > replace rwlock with rcu and spinlock in fib6_table"). > But by this commit, rcu is not yet used in ip6_pol_route(). (Sorry > that I missed this earlier.)

Re: [lkp-robot] [ipv6] 2b760fcf5c: WARNING:suspicious_RCU_usage

On Thu, Oct 12, 2017 at 10:09 PM, Wei Wang wrote: > > This warning should be fixed by later commit 66f5d6ce53e6 ("ipv6: > replace rwlock with rcu and spinlock in fib6_table"). > But by this commit, rcu is not yet used in ip6_pol_route(). (Sorry > that I missed this earlier.) Not sure what to do

Re: next: arm64: LTP sendto01 test causes system crash in ilp32 mode

On Wed, 2017-10-11 at 22:43 +0300, Yury Norov wrote: > The fix works for me, thanks. > > Tested-by: Yury Norov Thanks Yury !

Re: next: arm64: LTP sendto01 test causes system crash in ilp32 mode

On Wed, 2017-10-11 at 22:43 +0300, Yury Norov wrote: > The fix works for me, thanks. > > Tested-by: Yury Norov Thanks Yury !

Re: next: arm64: LTP sendto01 test causes system crash in ilp32 mode

On Wed, 2017-10-11 at 11:41 -0700, Eric Dumazet wrote: > On Wed, 2017-10-11 at 21:35 +0300, Yury Norov wrote: > > Hi all, > > > > It seems like next-20171009 with ilp32 patches crashes on LTP sendto01 test > > in sys_sendto() path, like this: > > Thanks for the

Re: next: arm64: LTP sendto01 test causes system crash in ilp32 mode

On Wed, 2017-10-11 at 11:41 -0700, Eric Dumazet wrote: > On Wed, 2017-10-11 at 21:35 +0300, Yury Norov wrote: > > Hi all, > > > > It seems like next-20171009 with ilp32 patches crashes on LTP sendto01 test > > in sys_sendto() path, like this: > > Thanks for the

Re: next: arm64: LTP sendto01 test causes system crash in ilp32 mode

On Wed, 2017-10-11 at 21:35 +0300, Yury Norov wrote: > Hi all, > > It seems like next-20171009 with ilp32 patches crashes on LTP sendto01 test > in sys_sendto() path, like this: Thanks for the report. Probably caused by one of my recent patches, so I am taking a look.

Re: next: arm64: LTP sendto01 test causes system crash in ilp32 mode

On Wed, 2017-10-11 at 21:35 +0300, Yury Norov wrote: > Hi all, > > It seems like next-20171009 with ilp32 patches crashes on LTP sendto01 test > in sys_sendto() path, like this: Thanks for the report. Probably caused by one of my recent patches, so I am taking a look.

Re: [PATCH net-next 2/2] net sched act_vlan: VLAN action rewrite to use RCU lock/unlock and update

On Wed, 2017-10-11 at 06:10 -0700, Eric Dumazet wrote: > On Tue, 2017-10-10 at 22:33 -0400, Manish Kurup wrote: > > Using a spinlock in the VLAN action causes performance issues when the VLAN > > action is used on multiple cores. Rewrote the VLAN action to use RCU read > &

Re: [PATCH net-next 2/2] net sched act_vlan: VLAN action rewrite to use RCU lock/unlock and update

On Wed, 2017-10-11 at 06:10 -0700, Eric Dumazet wrote: > On Tue, 2017-10-10 at 22:33 -0400, Manish Kurup wrote: > > Using a spinlock in the VLAN action causes performance issues when the VLAN > > action is used on multiple cores. Rewrote the VLAN action to use RCU read > &

Re: [PATCH net-next 2/2] net sched act_vlan: VLAN action rewrite to use RCU lock/unlock and update

On Tue, 2017-10-10 at 22:33 -0400, Manish Kurup wrote: > Using a spinlock in the VLAN action causes performance issues when the VLAN > action is used on multiple cores. Rewrote the VLAN action to use RCU read > locking for reads and updates instead. > > Signed-off-by: Manish Kurup

Re: [PATCH net-next 2/2] net sched act_vlan: VLAN action rewrite to use RCU lock/unlock and update

On Tue, 2017-10-10 at 22:33 -0400, Manish Kurup wrote: > Using a spinlock in the VLAN action causes performance issues when the VLAN > action is used on multiple cores. Rewrote the VLAN action to use RCU read > locking for reads and updates instead. > > Signed-off-by: Manish Kurup > --- >

Re: [PATCH][net-next] ipv6: fix dereference of rt6_ex before null check error

has been null checked. > > Detected by CoverityScan, CID#1457749 ("Dereference before null check") > > Fixes: 81eb8447daae ("ipv6: take care of rt6_stats") > Signed-off-by: Colin Ian King <colin.k...@canonical.com> > --- Reviewed-by: Eric Dumazet <eduma...@google.com>

Re: [PATCH][net-next] ipv6: fix dereference of rt6_ex before null check error

ected by CoverityScan, CID#1457749 ("Dereference before null check") > > Fixes: 81eb8447daae ("ipv6: take care of rt6_stats") > Signed-off-by: Colin Ian King > --- Reviewed-by: Eric Dumazet

Re: [lkp-robot] [ipv6] a94b9367e0: BUG:using_smp_processor_id()in_preemptible

On Tue, Oct 10, 2017 at 5:13 AM, kernel test robot wrote: > > FYI, we noticed the following commit (built with gcc-4.9): > > commit: a94b9367e044ba672c9f4105eb1516ff6ff4948a ("ipv6: grab rt->rt6i_ref > before allocating pcpu rt") >

Re: [lkp-robot] [ipv6] a94b9367e0: BUG:using_smp_processor_id()in_preemptible

On Tue, Oct 10, 2017 at 5:13 AM, kernel test robot wrote: > > FYI, we noticed the following commit (built with gcc-4.9): > > commit: a94b9367e044ba672c9f4105eb1516ff6ff4948a ("ipv6: grab rt->rt6i_ref > before allocating pcpu rt") > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git

Re: [PATCH 4/4] tcp: avoid noref dst leak on input path

On Fri, Oct 6, 2017 at 8:21 AM, Paolo Abeni <pab...@redhat.com> wrote: > Hi, > > On Fri, 2017-10-06 at 07:37 -0700, Eric Dumazet wrote: >> On Fri, 2017-10-06 at 14:57 +0200, Paolo Abeni wrote: >> > Enabling CONFIG_RCU_NOREF_DEBUG gives the following splat wh

Re: [PATCH 4/4] tcp: avoid noref dst leak on input path

On Fri, Oct 6, 2017 at 8:21 AM, Paolo Abeni wrote: > Hi, > > On Fri, 2017-10-06 at 07:37 -0700, Eric Dumazet wrote: >> On Fri, 2017-10-06 at 14:57 +0200, Paolo Abeni wrote: >> > Enabling CONFIG_RCU_NOREF_DEBUG gives the following splat when >

Re: [PATCH 4/4] tcp: avoid noref dst leak on input path

On Fri, 2017-10-06 at 14:57 +0200, Paolo Abeni wrote: > Enabling CONFIG_RCU_NOREF_DEBUG gives the following splat when > processing tcp packets: > >to-be-untracked noref entity 942cb71ea300 not found in cache >[ cut here ] >WARNING:

Re: [PATCH 4/4] tcp: avoid noref dst leak on input path

On Fri, 2017-10-06 at 14:57 +0200, Paolo Abeni wrote: > Enabling CONFIG_RCU_NOREF_DEBUG gives the following splat when > processing tcp packets: > >to-be-untracked noref entity 942cb71ea300 not found in cache >[ cut here ] >WARNING:

Re: [PATCH 2/2] vfs: grab the lock instead of blocking in __fd_install during resizing

On Wed, Oct 4, 2017 at 7:58 AM, Matthew Wilcox <wi...@infradead.org> wrote: > On Wed, Oct 04, 2017 at 07:00:40AM -0700, Eric Dumazet wrote: >> On Wed, Oct 4, 2017 at 6:55 AM, Matthew Wilcox <wi...@infradead.org> wrote: >> > Any chance you could review the patches from

Re: [PATCH 2/2] vfs: grab the lock instead of blocking in __fd_install during resizing

On Wed, Oct 4, 2017 at 7:58 AM, Matthew Wilcox wrote: > On Wed, Oct 04, 2017 at 07:00:40AM -0700, Eric Dumazet wrote: >> On Wed, Oct 4, 2017 at 6:55 AM, Matthew Wilcox wrote: >> > Any chance you could review the patches from Sandhya that make this entire >> > codepat

Re: [PATCH 2/2] vfs: grab the lock instead of blocking in __fd_install during resizing

On Wed, Oct 4, 2017 at 6:55 AM, Matthew Wilcox <wi...@infradead.org> wrote: > On Tue, Oct 03, 2017 at 07:41:11AM -0700, Eric Dumazet wrote: >> On Tue, Oct 3, 2017 at 3:58 AM, Mateusz Guzik <mgu...@redhat.com> wrote: >> > Explicit locking in the fallback case provides

Re: [PATCH 2/2] vfs: grab the lock instead of blocking in __fd_install during resizing

On Wed, Oct 4, 2017 at 6:55 AM, Matthew Wilcox wrote: > On Tue, Oct 03, 2017 at 07:41:11AM -0700, Eric Dumazet wrote: >> On Tue, Oct 3, 2017 at 3:58 AM, Mateusz Guzik wrote: >> > Explicit locking in the fallback case provides a safe state of the >> > table. Gettin

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

On Tue, Oct 3, 2017 at 9:06 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Tue, Oct 3, 2017 at 5:38 PM, 'Eric Dumazet' via syzkaller > <syzkal...@googlegroups.com> wrote: >> On Tue, Oct 3, 2017 at 8:19 AM, Dmitry Vyukov <dvyu...@google.com> wrote: >>>

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

On Tue, Oct 3, 2017 at 9:06 AM, Dmitry Vyukov wrote: > On Tue, Oct 3, 2017 at 5:38 PM, 'Eric Dumazet' via syzkaller > wrote: >> On Tue, Oct 3, 2017 at 8:19 AM, Dmitry Vyukov wrote: >>> On Mon, Oct 2, 2017 at 4:42 PM, 'Eric Dumazet' via syzkaller >>> wrote: >&

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

On Tue, Oct 3, 2017 at 8:19 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Mon, Oct 2, 2017 at 4:42 PM, 'Eric Dumazet' via syzkaller > <syzkal...@googlegroups.com> wrote: >> On Mon, Oct 2, 2017 at 7:21 AM, Mark Rutland <mark.rutl...@arm.com> wrote: >>>

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

On Tue, Oct 3, 2017 at 8:19 AM, Dmitry Vyukov wrote: > On Mon, Oct 2, 2017 at 4:42 PM, 'Eric Dumazet' via syzkaller > wrote: >> On Mon, Oct 2, 2017 at 7:21 AM, Mark Rutland wrote: >>> Hi Eric, >>> >>> On Mon, Oct 02, 2017 at 06:36:32AM -0700, Eric Dumazet

Re: [PATCH 2/2] vfs: grab the lock instead of blocking in __fd_install during resizing

++ > 2 files changed, 7 insertions(+), 8 deletions(-) Nice change ! Reviewed-by: Eric Dumazet <eduma...@google.com>

Re: [PATCH 2/2] vfs: grab the lock instead of blocking in __fd_install during resizing

s a side effect of slightly nicer assembly for the common case > as might_sleep can now be removed. > > Signed-off-by: Mateusz Guzik > --- > Documentation/filesystems/porting | 4 > fs/file.c | 11 +++ > 2 files changed, 7 insertions(+), 8 deletions(

Re: [PATCH 1/2] vfs: stop clearing close on exec when closing a fd

On Tue, Oct 3, 2017 at 3:58 AM, Mateusz Guzik <mgu...@redhat.com> wrote: > Codepaths allocating a fd always make sure the bit is set/unset > depending on flags, thus clearing on close is redundant. > > Signed-off-by: Mateusz Guzik <mgu...@redhat.com> > --- Revie

Re: [PATCH 1/2] vfs: stop clearing close on exec when closing a fd

On Tue, Oct 3, 2017 at 3:58 AM, Mateusz Guzik wrote: > Codepaths allocating a fd always make sure the bit is set/unset > depending on flags, thus clearing on close is redundant. > > Signed-off-by: Mateusz Guzik > --- Reviewed-by: Eric Dumazet

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

On Mon, Oct 2, 2017 at 10:21 AM, Mark Rutland <mark.rutl...@arm.com> wrote: > On Mon, Oct 02, 2017 at 07:48:28AM -0700, Eric Dumazet wrote: >> Please try the following fool proof patch. >> >> This is what I had in my local tree back in August but could not >>

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

On Mon, Oct 2, 2017 at 10:21 AM, Mark Rutland wrote: > On Mon, Oct 02, 2017 at 07:48:28AM -0700, Eric Dumazet wrote: >> Please try the following fool proof patch. >> >> This is what I had in my local tree back in August but could not >> conclude on the syzkaller bug I

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

On Mon, 2017-10-02 at 15:21 +0100, Mark Rutland wrote: > Hi Eric, > > On Mon, Oct 02, 2017 at 06:36:32AM -0700, Eric Dumazet wrote: > > On Mon, Oct 2, 2017 at 3:49 AM, Mark Rutland <mark.rutl...@arm.com> wrote: > > > I hit the below splat at net/core/skbuff.

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

On Mon, 2017-10-02 at 15:21 +0100, Mark Rutland wrote: > Hi Eric, > > On Mon, Oct 02, 2017 at 06:36:32AM -0700, Eric Dumazet wrote: > > On Mon, Oct 2, 2017 at 3:49 AM, Mark Rutland wrote: > > > I hit the below splat at net/core/skbuff.c:2626 while fuzzing v4.14-rc2 >

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

On Mon, Oct 2, 2017 at 7:21 AM, Mark Rutland <mark.rutl...@arm.com> wrote: > Hi Eric, > > On Mon, Oct 02, 2017 at 06:36:32AM -0700, Eric Dumazet wrote: >> On Mon, Oct 2, 2017 at 3:49 AM, Mark Rutland <mark.rutl...@arm.com> wrote: >> > I hit the below splat at

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