* Re: [PATCH net-next] net:sched: add gkprio scheduler
From: Michel Machado @ 2018-05-09 17:37 UTC (permalink / raw)
To: Jamal Hadi Salim, Cong Wang
Cc: Nishanth Devarajan, Jiri Pirko, David Miller,
Linux Kernel Network Developers, Cody Doucette
In-Reply-To: <bee1e54d-e2eb-1393-1a4e-d54e731f7bfc@mojatatu.com>
On 05/09/2018 10:43 AM, Jamal Hadi Salim wrote:
> On 08/05/18 10:27 PM, Cong Wang wrote:
>> On Tue, May 8, 2018 at 6:29 AM, Jamal Hadi Salim <jhs@mojatatu.com>
>> wrote:
>>> Have you considered using skb->prio instead of peeking into the packet
>>> header.
>>> Also have you looked at the dsmark qdisc?
>>>
>>
>> dsmark modifies ds fields, while this one just maps ds fields into
>> different queues.
>>
>
> Yeah, I was thinking more of re-using it for the purpose of mapping to
> queues - but would require a lot more work.
>
> once skbprio is set by something[1] then this qdisc could be used by
> other subsystems (8021q, sockets etc); so i would argue for removal
> of the embedded classification and instead maybe writing a simple
> extension to skbmod to mark skbprio based on ds.
I like the suggestion of extending skbmod to mark skbprio based on ds.
Given that DSprio would no longer depend on the DS field, would you have
a name suggestion for this new queue discipline since the name "prio" is
currently in use?
What should be the range of priorities that this new queue discipline
would accept? skb->prioriry is of type __u32, but supporting 2^32
priorities would require too large of an array to index packets by
priority; the DS field is only 6 bits long. Do you have a use case in
mind to guide us here?
> I find the cleverness in changing the highest/low prios confusing.
> It looks error-prone (I guess that is why there is a BUG check)
> To the authors: Is there a document/paper on the theory of this thing
> as to why no explicit queues are "faster"?
The priority orientation in GKprio is due to two factors: failing safe
and elegance. If zero were the highest priority, any operational mistake
that leads not-classified packets through GKprio would potentially
disrupt the system. We are humans, we'll make mistakes. The elegance
aspect comes from the fact that the assigned priority is not massaged to
fit the DS field. We find it helpful while inspecting packets on the wire.
The reason for us to avoid explicit queues in GKprio, which could change
the behavior within a given priority, is to closely abide to the
expected behavior assumed to prove Theorem 4.1 in the paper "Portcullis:
Protecting Connection Setup from Denial-of-Capability Attacks":
https://dl.acm.org/citation.cfm?id=1282413
> 1) I agree that using multiple queues as in prio qdisc would make it
> more manageable; does not necessarily need to be classful if you
> use implicit skbprio classification. i.e on equeue use a priority
> map to select a queue; on dequeue always dequeu from highest prio
> until it has no more packets to send.
In my reply to Cong, I point out that there is a technical limitation
in the interface of queue disciplines that forbids GKprio to have
explicit sub-queues:
https://www.mail-archive.com/netdev@vger.kernel.org/msg234201.html
> 2) Dropping already enqueued packets will not work well for
> local feedback (__NET_XMIT_BYPASS return code is about the
> packet that has been dropped from earlier enqueueing because
> it is lower priority - it does not signify anything with
> current skb to which actually just got enqueud).
> Perhaps (off top of my head) is to always enqueue packets on
> high priority when their limit is exceeded as long as lower prio has
> some space. Means youd have to increment low prio accounting if their
> space is used.
I don't understand the point you are making here. Could you develop it
further?
[ ]'s
Michel Machado
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] socket statistics for ss
From: Stephen Hemminger @ 2018-05-09 17:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, gerrit, kuznet, yoshfuji, netdev, dccp, Stephen Hemminger
In-Reply-To: <be94fb64-1dd5-e512-50d6-16a1b7d4d092@gmail.com>
On Wed, 9 May 2018 10:18:23 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On 05/09/2018 08:22 AM, Stephen Hemminger wrote:
>
> > I am not sure if these patches are worth applying.
> > The 'ss -s' command has had missing values since 2.4 kernel.
> > And the first complaints came in only this year.
> >
> > Another alternative would be just to remove these fields from ss -s
> > output and move on.
> >
>
> Anyway your patches are not netns ready, so lets remove these fields from ss.
>
> Or you have to spend _much_ more time on writing and testing the kernel part.
>
> Thanks.
The patches only expose the existing TCP socket accounting infrastructure.
Several other pieces that sockstat has are not netns aware.
That is a completely different problem.
^ permalink raw reply
* RE: [PATCH net] tipc: fix one byte leak in tipc_sk_set_orig_addr()
From: Jon Maloy @ 2018-05-09 17:19 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller; +Cc: netdev, Eric Dumazet, Ying Xue
In-Reply-To: <20180509165022.199827-1-edumazet@google.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Thank you Eric.
> -----Original Message-----
> From: Eric Dumazet [mailto:edumazet@google.com]
> Sent: Wednesday, May 09, 2018 09:50
> To: David S . Miller <davem@davemloft.net>
> Cc: netdev <netdev@vger.kernel.org>; Eric Dumazet
> <edumazet@google.com>; Eric Dumazet <eric.dumazet@gmail.com>; Jon
> Maloy <jon.maloy@ericsson.com>; Ying Xue <ying.xue@windriver.com>
> Subject: [PATCH net] tipc: fix one byte leak in tipc_sk_set_orig_addr()
>
> sysbot/KMSAN reported an uninit-value in recvmsg() that I tracked down to
> tipc_sk_set_orig_addr(), missing
> srcaddr->member.scope initialization.
>
> This patches moves srcaddr->sock.scope init to follow fields order and ease
> future verifications.
>
> BUG: KMSAN: uninit-value in copy_to_user include/linux/uaccess.h:184
> [inline]
> BUG: KMSAN: uninit-value in move_addr_to_user+0x32e/0x530
> net/socket.c:226
> CPU: 0 PID: 4549 Comm: syz-executor287 Not tainted 4.17.0-rc3+ #88
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011 Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x185/0x1d0 lib/dump_stack.c:113
> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
> kmsan_internal_check_memory+0x135/0x1e0 mm/kmsan/kmsan.c:1157
> kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199 copy_to_user
> include/linux/uaccess.h:184 [inline]
> move_addr_to_user+0x32e/0x530 net/socket.c:226
> ___sys_recvmsg+0x4e2/0x810 net/socket.c:2285 __sys_recvmsg
> net/socket.c:2328 [inline] __do_sys_recvmsg net/socket.c:2338 [inline]
> __se_sys_recvmsg net/socket.c:2335 [inline]
> __x64_sys_recvmsg+0x325/0x460 net/socket.c:2335
> do_syscall_64+0x154/0x220 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x4455e9
> RSP: 002b:00007fe3bd36ddb8 EFLAGS: 00000246 ORIG_RAX:
> 000000000000002f
> RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 00000000004455e9
> RDX: 0000000000002002 RSI: 0000000020000400 RDI: 0000000000000003
> RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fff98ce4b6f R14: 00007fe3bd36e9c0 R15: 0000000000000003
>
> Local variable description: ----addr@___sys_recvmsg Variable was created
> at:
> ___sys_recvmsg+0xd5/0x810 net/socket.c:2246 __sys_recvmsg
> net/socket.c:2328 [inline] __do_sys_recvmsg net/socket.c:2338 [inline]
> __se_sys_recvmsg net/socket.c:2335 [inline]
> __x64_sys_recvmsg+0x325/0x460 net/socket.c:2335
>
> Byte 19 of 32 is uninitialized
>
> Fixes: 31c82a2d9d51 ("tipc: add second source address to
> recvmsg()/recvfrom()")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Cc: Jon Maloy <jon.maloy@ericsson.com>
> Cc: Ying Xue <ying.xue@windriver.com>
> ---
> net/tipc/socket.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/tipc/socket.c b/net/tipc/socket.c index
> 252a52ae0893261fc6f146ad81111c59f375fdce..6be21575503aa532014e7aa141
> 5b2bf294757308 100644
> --- a/net/tipc/socket.c
> +++ b/net/tipc/socket.c
> @@ -1516,10 +1516,10 @@ static void tipc_sk_set_orig_addr(struct msghdr
> *m, struct sk_buff *skb)
>
> srcaddr->sock.family = AF_TIPC;
> srcaddr->sock.addrtype = TIPC_ADDR_ID;
> + srcaddr->sock.scope = 0;
> srcaddr->sock.addr.id.ref = msg_origport(hdr);
> srcaddr->sock.addr.id.node = msg_orignode(hdr);
> srcaddr->sock.addr.name.domain = 0;
> - srcaddr->sock.scope = 0;
> m->msg_namelen = sizeof(struct sockaddr_tipc);
>
> if (!msg_in_group(hdr))
> @@ -1528,6 +1528,7 @@ static void tipc_sk_set_orig_addr(struct msghdr
> *m, struct sk_buff *skb)
> /* Group message users may also want to know sending member's id
> */
> srcaddr->member.family = AF_TIPC;
> srcaddr->member.addrtype = TIPC_ADDR_NAME;
> + srcaddr->member.scope = 0;
> srcaddr->member.addr.name.name.type = msg_nametype(hdr);
> srcaddr->member.addr.name.name.instance = TIPC_SKB_CB(skb)-
> >orig_member;
> srcaddr->member.addr.name.domain = 0;
> --
> 2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] socket statistics for ss
From: Eric Dumazet @ 2018-05-09 17:18 UTC (permalink / raw)
To: Stephen Hemminger, davem, gerrit, kuznet, yoshfuji
Cc: netdev, dccp, Stephen Hemminger
In-Reply-To: <20180509082209.38fa4f43@xeon-e3>
On 05/09/2018 08:22 AM, Stephen Hemminger wrote:
> I am not sure if these patches are worth applying.
> The 'ss -s' command has had missing values since 2.4 kernel.
> And the first complaints came in only this year.
>
> Another alternative would be just to remove these fields from ss -s
> output and move on.
>
Anyway your patches are not netns ready, so lets remove these fields from ss.
Or you have to spend _much_ more time on writing and testing the kernel part.
Thanks.
^ permalink raw reply
* Re: [PATCH net] net/ipv6: fix lock imbalance in ip6_route_del()
From: Eric Dumazet @ 2018-05-09 17:10 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller; +Cc: netdev, Eric Dumazet, David Ahern
In-Reply-To: <20180509170546.247826-1-edumazet@google.com>
On 05/09/2018 10:05 AM, Eric Dumazet wrote:
> WARNING: lock held when returning to user space!
> 4.17.0-rc3+ #37 Not tainted
>
>
> Fixes: 23fb93a4d3f1 ("net/ipv6: Cleanup exception and cache route handling")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: David Ahern <dsahern@gmail.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> ---
This targets net-next tree, not tree, sorry for the typo.
^ permalink raw reply
* Re: [PATCH net] net/ipv6: fix lock imbalance in ip6_route_del()
From: David Ahern @ 2018-05-09 17:09 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <20180509170546.247826-1-edumazet@google.com>
On 5/9/18 11:05 AM, Eric Dumazet wrote:
> WARNING: lock held when returning to user space!
> 4.17.0-rc3+ #37 Not tainted
>
> syz-executor1/27662 is leaving the kernel with locks still held!
> 1 lock held by syz-executor1/27662:
> #0: 00000000f661aee7 (rcu_read_lock){....}, at: ip6_route_del+0xea/0x13f0 net/ipv6/route.c:3206
> BUG: scheduling while atomic: syz-executor1/27662/0x00000002
> INFO: lockdep is turned off.
> Modules linked in:
> Kernel panic - not syncing: scheduling while atomic
>
> CPU: 1 PID: 27662 Comm: syz-executor1 Not tainted 4.17.0-rc3+ #37
...
>
> Fixes: 23fb93a4d3f1 ("net/ipv6: Cleanup exception and cache route handling")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: David Ahern <dsahern@gmail.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> ---
> net/ipv6/route.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: David Ahern <dsahern@gmail.com>
Thanks for the fix, Eric.
^ permalink raw reply
* [PATCH net] net/ipv6: fix lock imbalance in ip6_route_del()
From: Eric Dumazet @ 2018-05-09 17:05 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet, David Ahern
WARNING: lock held when returning to user space!
4.17.0-rc3+ #37 Not tainted
syz-executor1/27662 is leaving the kernel with locks still held!
1 lock held by syz-executor1/27662:
#0: 00000000f661aee7 (rcu_read_lock){....}, at: ip6_route_del+0xea/0x13f0 net/ipv6/route.c:3206
BUG: scheduling while atomic: syz-executor1/27662/0x00000002
INFO: lockdep is turned off.
Modules linked in:
Kernel panic - not syncing: scheduling while atomic
CPU: 1 PID: 27662 Comm: syz-executor1 Not tainted 4.17.0-rc3+ #37
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
panic+0x22f/0x4de kernel/panic.c:184
__schedule_bug.cold.85+0xdf/0xdf kernel/sched/core.c:3290
schedule_debug kernel/sched/core.c:3307 [inline]
__schedule+0x139e/0x1e30 kernel/sched/core.c:3412
schedule+0xef/0x430 kernel/sched/core.c:3549
exit_to_usermode_loop+0x220/0x310 arch/x86/entry/common.c:152
prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455979
RSP: 002b:00007fbf4051dc68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: 0000000000000000 RBX: 00007fbf4051e6d4 RCX: 0000000000455979
RDX: 00000000200001c0 RSI: 000000000000890c RDI: 0000000000000013
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000003c8 R14: 00000000006f9b60 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
Fixes: 23fb93a4d3f1 ("net/ipv6: Cleanup exception and cache route handling")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Ahern <dsahern@gmail.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
---
net/ipv6/route.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index daa3662da0ee809422db12f0ff58c7975b0b8be7..af0416701fb21c71f8b0f2dec9f0ada479cb9152 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3224,8 +3224,10 @@ static int ip6_route_del(struct fib6_config *cfg,
&cfg->fc_src);
if (rt_cache) {
rc = ip6_del_cached_rt(rt_cache, cfg);
- if (rc != -ESRCH)
+ if (rc != -ESRCH) {
+ rcu_read_unlock();
return rc;
+ }
}
continue;
}
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* Re: simplify procfs code for seq_file instances V2
From: Alexey Dobriyan @ 2018-05-09 16:53 UTC (permalink / raw)
To: Al Viro
Cc: linux-rtc, Alessandro Zummo, Alexandre Belloni, devel,
linux-kernel, linux-scsi, linux-ide, Greg Kroah-Hartman,
jfs-discussion, linux-afs, linux-acpi, netdev, netfilter-devel,
Jiri Slaby, Andrew Morton, linux-ext4, Christoph Hellwig,
megaraidlinux.pdl, drbd-dev
In-Reply-To: <20180506174531.GK30522@ZenIV.linux.org.uk>
On Sun, May 06, 2018 at 06:45:31PM +0100, Al Viro wrote:
> On Sun, May 06, 2018 at 08:19:49PM +0300, Alexey Dobriyan wrote:
> > @@ -62,9 +62,9 @@ struct proc_dir_entry {
> > umode_t mode;
> > u8 namelen;
> > #ifdef CONFIG_64BIT
> > -#define SIZEOF_PDE_INLINE_NAME (192-139)
> > +#define SIZEOF_PDE_INLINE_NAME (192-155)
> > #else
> > -#define SIZEOF_PDE_INLINE_NAME (128-87)
> > +#define SIZEOF_PDE_INLINE_NAME (128-95)
>
> > #endif
> > char inline_name[SIZEOF_PDE_INLINE_NAME];
> > } __randomize_layout;
>
> *UGH*
I agree. Maintaining these numbers is a pain point.
Who knew people were going to start adding fields right away.
> Both to the original state and that kind of "adjustments".
> Incidentally, with __bugger_layout in there these expressions
> are simply wrong.
Struct randomization is exempt from maintaining sizeof as they are already
screwing cachelines and everything. But if patch works with lockdep and
randomization -- even better.
> If nothing else, I would suggest turning the last one into
> char inline_name[];
> in hope that layout won't get... randomized that much and
> used
>
> #ifdef CONFIG_64BIT
> #define PDE_SIZE 192
> #else
> #define PDE_SIZE 128
> #endif
>
> union __proc_dir_entry {
> char pad[PDE_SIZE];
> struct proc_dir_entry real;
> };
>
> #define SIZEOF_PDE_INLINE_NAME (PDE_SIZE - offsetof(struct proc_dir_entry, inline_name))
>
> for constants, adjusted sizeof and sizeof_field when creating
> proc_dir_entry_cache and turned proc_root into
>
> union __proc_dir_entry __proc_root = { .real = {
> .low_ino = PROC_ROOT_INO,
> .namelen = 5,
> .mode = S_IFDIR | S_IRUGO | S_IXUGO,
> .nlink = 2,
> .refcnt = REFCOUNT_INIT(1),
> .proc_iops = &proc_root_inode_operations,
> .proc_fops = &proc_root_operations,
> .parent = &__proc_root.real,
> .subdir = RB_ROOT,
> .name = __proc_root.real.inline_name,
> .inline_name = "/proc",
> }};
>
> #define proc_root __proc_root.real
> (or actually used __proc_root.real in all of a 6 places where it remains).
>
> > - size_t state_size = PDE(inode)->state_size;
> > + unsigned int state_size = PDE(inode)->state_size;
>
> <shakes head>
> You and your "size_t is evil" crusade...
[nods]
unsigned long flags; /* error bits */
unsigned long i_state;
unsigned long s_blocksize;
unsigned long s_flags;
unsigned long s_iflags; /* internal SB_I_* flags */
^ permalink raw reply
* [PATCH net] tipc: fix one byte leak in tipc_sk_set_orig_addr()
From: Eric Dumazet @ 2018-05-09 16:50 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet, Jon Maloy, Ying Xue
sysbot/KMSAN reported an uninit-value in recvmsg() that
I tracked down to tipc_sk_set_orig_addr(), missing
srcaddr->member.scope initialization.
This patches moves srcaddr->sock.scope init to follow
fields order and ease future verifications.
BUG: KMSAN: uninit-value in copy_to_user include/linux/uaccess.h:184 [inline]
BUG: KMSAN: uninit-value in move_addr_to_user+0x32e/0x530 net/socket.c:226
CPU: 0 PID: 4549 Comm: syz-executor287 Not tainted 4.17.0-rc3+ #88
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
kmsan_internal_check_memory+0x135/0x1e0 mm/kmsan/kmsan.c:1157
kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199
copy_to_user include/linux/uaccess.h:184 [inline]
move_addr_to_user+0x32e/0x530 net/socket.c:226
___sys_recvmsg+0x4e2/0x810 net/socket.c:2285
__sys_recvmsg net/socket.c:2328 [inline]
__do_sys_recvmsg net/socket.c:2338 [inline]
__se_sys_recvmsg net/socket.c:2335 [inline]
__x64_sys_recvmsg+0x325/0x460 net/socket.c:2335
do_syscall_64+0x154/0x220 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4455e9
RSP: 002b:00007fe3bd36ddb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 00000000004455e9
RDX: 0000000000002002 RSI: 0000000020000400 RDI: 0000000000000003
RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fff98ce4b6f R14: 00007fe3bd36e9c0 R15: 0000000000000003
Local variable description: ----addr@___sys_recvmsg
Variable was created at:
___sys_recvmsg+0xd5/0x810 net/socket.c:2246
__sys_recvmsg net/socket.c:2328 [inline]
__do_sys_recvmsg net/socket.c:2338 [inline]
__se_sys_recvmsg net/socket.c:2335 [inline]
__x64_sys_recvmsg+0x325/0x460 net/socket.c:2335
Byte 19 of 32 is uninitialized
Fixes: 31c82a2d9d51 ("tipc: add second source address to recvmsg()/recvfrom()")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Jon Maloy <jon.maloy@ericsson.com>
Cc: Ying Xue <ying.xue@windriver.com>
---
net/tipc/socket.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 252a52ae0893261fc6f146ad81111c59f375fdce..6be21575503aa532014e7aa1415b2bf294757308 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -1516,10 +1516,10 @@ static void tipc_sk_set_orig_addr(struct msghdr *m, struct sk_buff *skb)
srcaddr->sock.family = AF_TIPC;
srcaddr->sock.addrtype = TIPC_ADDR_ID;
+ srcaddr->sock.scope = 0;
srcaddr->sock.addr.id.ref = msg_origport(hdr);
srcaddr->sock.addr.id.node = msg_orignode(hdr);
srcaddr->sock.addr.name.domain = 0;
- srcaddr->sock.scope = 0;
m->msg_namelen = sizeof(struct sockaddr_tipc);
if (!msg_in_group(hdr))
@@ -1528,6 +1528,7 @@ static void tipc_sk_set_orig_addr(struct msghdr *m, struct sk_buff *skb)
/* Group message users may also want to know sending member's id */
srcaddr->member.family = AF_TIPC;
srcaddr->member.addrtype = TIPC_ADDR_NAME;
+ srcaddr->member.scope = 0;
srcaddr->member.addr.name.name.type = msg_nametype(hdr);
srcaddr->member.addr.name.name.instance = TIPC_SKB_CB(skb)->orig_member;
srcaddr->member.addr.name.domain = 0;
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH net] tc-testing: fix tdc tests for 'bpf' action
From: Davide Caratti @ 2018-05-09 16:45 UTC (permalink / raw)
To: Roman Mashak, Lucas Bates, David Miller; +Cc: netdev
- correct a typo in the value of 'matchPattern' of test 282d, potentially
causing false negative
- allow errors when 'teardown' executes '$TC action flush action bpf' in
test 282d, to fix false positive when it is run with act_bpf unloaded
- correct the value of 'matchPattern' in test e939, causing false positive
in case the BPF JIT is enabled
Fixes: 440ea4ae1828 ("tc-testing: add selftests for 'bpf' action")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
tools/testing/selftests/tc-testing/tc-tests/actions/bpf.json | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/tc-testing/tc-tests/actions/bpf.json b/tools/testing/selftests/tc-testing/tc-tests/actions/bpf.json
index 5b012f4981d4..6f289a49e5ec 100644
--- a/tools/testing/selftests/tc-testing/tc-tests/actions/bpf.json
+++ b/tools/testing/selftests/tc-testing/tc-tests/actions/bpf.json
@@ -66,7 +66,7 @@
"cmdUnderTest": "$TC action add action bpf object-file _b.o index 667",
"expExitCode": "0",
"verifyCmd": "$TC action get action bpf index 667",
- "matchPattern": "action order [0-9]*: bpf _b.o:\\[action\\] id [0-9]* tag 3b185187f1855c4c default-action pipe.*index 667 ref",
+ "matchPattern": "action order [0-9]*: bpf _b.o:\\[action\\] id [0-9]* tag 3b185187f1855c4c( jited)? default-action pipe.*index 667 ref",
"matchCount": "1",
"teardown": [
"$TC action flush action bpf",
@@ -92,10 +92,15 @@
"cmdUnderTest": "$TC action add action bpf object-file _c.o index 667",
"expExitCode": "255",
"verifyCmd": "$TC action get action bpf index 667",
- "matchPattern": "action order [0-9]*: bpf _b.o:\\[action\\] id [0-9].*index 667 ref",
+ "matchPattern": "action order [0-9]*: bpf _c.o:\\[action\\] id [0-9].*index 667 ref",
"matchCount": "0",
"teardown": [
- "$TC action flush action bpf",
+ [
+ "$TC action flush action bpf",
+ 0,
+ 1,
+ 255
+ ],
"rm -f _c.o"
]
},
--
2.14.3
^ permalink raw reply related
* Re: KASAN: use-after-free Read in __dev_queue_xmit
From: Willem de Bruijn @ 2018-05-09 16:38 UTC (permalink / raw)
To: Eric Biggers
Cc: Eric Dumazet, Eric Dumazet, syzbot, alexander.deucher,
Andrey Konovalov, Anoob Soman, chris, David Miller,
Reshetova, Elena, Greg Kroah-Hartman, Kees Cook, LKML,
Mike Maloney, mchehab, netdev, Rosen, Rami, Sowmini Varadhan,
syzkaller-bugs, Willem de Bruijn
In-Reply-To: <CAF=yD-Je0ej2XDcfyEKano4R-og5oGjPvP36X4dSmpYshzBuKA@mail.gmail.com>
>> But a crash with the same signature is still occurring, so it should eventually
>> get reported again. C reproducer is here, it works on Linus' tree (commit
>> 036db8bd963): https://syzkaller.appspot.com/text?tag=ReproC&x=105b1ae7800000
>
> This appears to be a separate issue.
>
> This reproducer requires a setsockopt SOL_SOCKET/SO_TIMESTAMPING
> to trigger the use-after-free. And the freed path also points at a timestamping
> skb:
>
> [ 31.963619] Freed by task 2672:
> [ 31.964006] __kasan_slab_free+0x125/0x170
> [ 31.964509] kfree+0x8b/0x1a0
> [ 31.964875] skb_free_head+0x6f/0xa0
> [ 31.965314] skb_release_data+0x420/0x5a0
> [ 31.965802] skb_release_all+0x46/0x60
> [ 31.966260] kfree_skb+0x91/0x1c0
> [ 31.966669] __skb_complete_tx_timestamp+0x2e9/0x3d0
> [ 31.967273] __skb_tstamp_tx+0x3b3/0x620
> [ 31.967774] __dev_queue_xmit+0xed5/0x1a20
> [ 31.968300] packet_sendmsg+0x36fd/0x5400
> [ 31.968821] sock_sendmsg+0xc0/0x100
> [ 31.969284] ___sys_sendmsg+0x367/0x880
> [ 31.969777] __sys_sendmmsg+0x178/0x410
> [ 31.970267] __x64_sys_sendmmsg+0x99/0x100
> [ 31.970789] do_syscall_64+0x9a/0x2c0
> [ 31.971260] entry_SYSCALL_64_after_hwframe+0x44/0xa9
This is a rare path taken when the timestamp skb cannot be queued
onto the socket (likely because of insufficient rcvbuf).
Somehow, freeing the timestamp skb triggers this use-after-free in
the original skb from which the timestamp was cloned. As if there
is a bug in the shared info dataref.
The report does occur on reading a shinfo field (gso_size).
^ permalink raw reply
* [PATCH net-next 4/4] net: hns3: refactor the loopback related function
From: Salil Mehta @ 2018-05-09 16:24 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Yunsheng Lin
In-Reply-To: <20180509162441.18068-1-salil.mehta@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
This patch refactors the loopback related function in order
to support the serdes loopback.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 21 +++----
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 68 +++++++++++-----------
2 files changed, 42 insertions(+), 47 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index eb3c34f..c16bb6c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -74,7 +74,7 @@ struct hns3_link_mode_mapping {
u32 ethtool_link_mode;
};
-static int hns3_lp_setup(struct net_device *ndev, enum hnae3_loop loop)
+static int hns3_lp_setup(struct net_device *ndev, enum hnae3_loop loop, bool en)
{
struct hnae3_handle *h = hns3_get_handle(ndev);
int ret;
@@ -85,11 +85,7 @@ static int hns3_lp_setup(struct net_device *ndev, enum hnae3_loop loop)
switch (loop) {
case HNAE3_MAC_INTER_LOOP_MAC:
- ret = h->ae_algo->ops->set_loopback(h, loop, true);
- break;
- case HNAE3_MAC_LOOP_NONE:
- ret = h->ae_algo->ops->set_loopback(h,
- HNAE3_MAC_INTER_LOOP_MAC, false);
+ ret = h->ae_algo->ops->set_loopback(h, loop, en);
break;
default:
ret = -ENOTSUPP;
@@ -99,10 +95,7 @@ static int hns3_lp_setup(struct net_device *ndev, enum hnae3_loop loop)
if (ret)
return ret;
- if (loop == HNAE3_MAC_LOOP_NONE)
- h->ae_algo->ops->set_promisc_mode(h, ndev->flags & IFF_PROMISC);
- else
- h->ae_algo->ops->set_promisc_mode(h, 1);
+ h->ae_algo->ops->set_promisc_mode(h, en);
return ret;
}
@@ -122,13 +115,13 @@ static int hns3_lp_up(struct net_device *ndev, enum hnae3_loop loop_mode)
return ret;
}
- ret = hns3_lp_setup(ndev, loop_mode);
+ ret = hns3_lp_setup(ndev, loop_mode, true);
usleep_range(10000, 20000);
return ret;
}
-static int hns3_lp_down(struct net_device *ndev)
+static int hns3_lp_down(struct net_device *ndev, enum hnae3_loop loop_mode)
{
struct hnae3_handle *h = hns3_get_handle(ndev);
int ret;
@@ -136,7 +129,7 @@ static int hns3_lp_down(struct net_device *ndev)
if (!h->ae_algo->ops->stop)
return -EOPNOTSUPP;
- ret = hns3_lp_setup(ndev, HNAE3_MAC_LOOP_NONE);
+ ret = hns3_lp_setup(ndev, loop_mode, false);
if (ret) {
netdev_err(ndev, "lb_setup return error: %d\n", ret);
return ret;
@@ -332,7 +325,7 @@ static void hns3_self_test(struct net_device *ndev,
data[test_index] = hns3_lp_up(ndev, loop_type);
if (!data[test_index]) {
data[test_index] = hns3_lp_run_test(ndev, loop_type);
- hns3_lp_down(ndev);
+ hns3_lp_down(ndev, loop_type);
}
if (data[test_index])
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 084b904..316ec842 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3682,48 +3682,50 @@ static void hclge_cfg_mac_mode(struct hclge_dev *hdev, bool enable)
"mac enable fail, ret =%d.\n", ret);
}
-static int hclge_set_loopback(struct hnae3_handle *handle,
- enum hnae3_loop loop_mode, bool en)
+static int hclge_set_mac_loopback(struct hclge_dev *hdev, bool en)
{
- struct hclge_vport *vport = hclge_get_vport(handle);
struct hclge_config_mac_mode_cmd *req;
- struct hclge_dev *hdev = vport->back;
struct hclge_desc desc;
u32 loop_en;
int ret;
- switch (loop_mode) {
- case HNAE3_MAC_INTER_LOOP_MAC:
- req = (struct hclge_config_mac_mode_cmd *)&desc.data[0];
- /* 1 Read out the MAC mode config at first */
- hclge_cmd_setup_basic_desc(&desc,
- HCLGE_OPC_CONFIG_MAC_MODE,
- true);
- ret = hclge_cmd_send(&hdev->hw, &desc, 1);
- if (ret) {
- dev_err(&hdev->pdev->dev,
- "mac loopback get fail, ret =%d.\n",
- ret);
- return ret;
- }
+ req = (struct hclge_config_mac_mode_cmd *)&desc.data[0];
+ /* 1 Read out the MAC mode config at first */
+ hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_CONFIG_MAC_MODE, true);
+ ret = hclge_cmd_send(&hdev->hw, &desc, 1);
+ if (ret) {
+ dev_err(&hdev->pdev->dev,
+ "mac loopback get fail, ret =%d.\n", ret);
+ return ret;
+ }
- /* 2 Then setup the loopback flag */
- loop_en = le32_to_cpu(req->txrx_pad_fcs_loop_en);
- if (en)
- hnae_set_bit(loop_en, HCLGE_MAC_APP_LP_B, 1);
- else
- hnae_set_bit(loop_en, HCLGE_MAC_APP_LP_B, 0);
+ /* 2 Then setup the loopback flag */
+ loop_en = le32_to_cpu(req->txrx_pad_fcs_loop_en);
+ hnae_set_bit(loop_en, HCLGE_MAC_APP_LP_B, en ? 1 : 0);
- req->txrx_pad_fcs_loop_en = cpu_to_le32(loop_en);
+ req->txrx_pad_fcs_loop_en = cpu_to_le32(loop_en);
- /* 3 Config mac work mode with loopback flag
- * and its original configure parameters
- */
- hclge_cmd_reuse_desc(&desc, false);
- ret = hclge_cmd_send(&hdev->hw, &desc, 1);
- if (ret)
- dev_err(&hdev->pdev->dev,
- "mac loopback set fail, ret =%d.\n", ret);
+ /* 3 Config mac work mode with loopback flag
+ * and its original configure parameters
+ */
+ hclge_cmd_reuse_desc(&desc, false);
+ ret = hclge_cmd_send(&hdev->hw, &desc, 1);
+ if (ret)
+ dev_err(&hdev->pdev->dev,
+ "mac loopback set fail, ret =%d.\n", ret);
+ return ret;
+}
+
+static int hclge_set_loopback(struct hnae3_handle *handle,
+ enum hnae3_loop loop_mode, bool en)
+{
+ struct hclge_vport *vport = hclge_get_vport(handle);
+ struct hclge_dev *hdev = vport->back;
+ int ret;
+
+ switch (loop_mode) {
+ case HNAE3_MAC_INTER_LOOP_MAC:
+ ret = hclge_set_mac_loopback(hdev, en);
break;
default:
ret = -ENOTSUPP;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 3/4] net: hns3: fix for cleaning ring problem
From: Salil Mehta @ 2018-05-09 16:24 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Yunsheng Lin
In-Reply-To: <20180509162441.18068-1-salil.mehta@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
The head or tail in hardware is not longer valid when resetting,
current hns3_clear_all_ring use them to clean the ring, which
will cause problem during resetting.
This patch fixes it by using next_to_use and next_to_clean in
the ring struct.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 34 ++++++++++++++++++++++---
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index bd8e14b..4031174 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3203,9 +3203,35 @@ static void hns3_recover_hw_addr(struct net_device *ndev)
hns3_nic_mc_sync(ndev, ha->addr);
}
-static void hns3_drop_skb_data(struct hns3_enet_ring *ring, struct sk_buff *skb)
+static void hns3_clear_tx_ring(struct hns3_enet_ring *ring)
{
- dev_kfree_skb_any(skb);
+ if (!HNAE3_IS_TX_RING(ring))
+ return;
+
+ while (ring->next_to_clean != ring->next_to_use) {
+ hns3_free_buffer_detach(ring, ring->next_to_clean);
+ ring_ptr_move_fw(ring, next_to_clean);
+ }
+}
+
+static void hns3_clear_rx_ring(struct hns3_enet_ring *ring)
+{
+ if (HNAE3_IS_TX_RING(ring))
+ return;
+
+ while (ring->next_to_use != ring->next_to_clean) {
+ /* When a buffer is not reused, it's memory has been
+ * freed in hns3_handle_rx_bd or will be freed by
+ * stack, so only need to unmap the buffer here.
+ */
+ if (!ring->desc_cb[ring->next_to_use].reuse_flag) {
+ hns3_unmap_buffer(ring,
+ &ring->desc_cb[ring->next_to_use]);
+ ring->desc_cb[ring->next_to_use].dma = 0;
+ }
+
+ ring_ptr_move_fw(ring, next_to_use);
+ }
}
static void hns3_clear_all_ring(struct hnae3_handle *h)
@@ -3219,13 +3245,13 @@ static void hns3_clear_all_ring(struct hnae3_handle *h)
struct hns3_enet_ring *ring;
ring = priv->ring_data[i].ring;
- hns3_clean_tx_ring(ring, ring->desc_num);
+ hns3_clear_tx_ring(ring);
dev_queue = netdev_get_tx_queue(ndev,
priv->ring_data[i].queue_index);
netdev_tx_reset_queue(dev_queue);
ring = priv->ring_data[i + h->kinfo.num_tqps].ring;
- hns3_clean_rx_ring(ring, ring->desc_num, hns3_drop_skb_data);
+ hns3_clear_rx_ring(ring);
}
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/4] net: hns3: remove add/del_tunnel_udp in hns3_enet module
From: Salil Mehta @ 2018-05-09 16:24 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Yunsheng Lin
In-Reply-To: <20180509162441.18068-1-salil.mehta@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
The add/del_tunnel_udp is not implemented in hclge_main moulde,
the NETIF_F_RX_UDP_TUNNEL_PORT feature bit is added automatically
by stack when ndo_udp_tunnel_add is not null in dev->netdev_ops.
This patch removes the add/del_tunnel_udp related function, for
we do not support this feature now.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 7 --
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 89 -------------------------
2 files changed, 96 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 37ec1b3..804ea83 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -273,10 +273,6 @@ struct hnae3_ae_dev {
* Map rings to vector
* unmap_ring_from_vector()
* Unmap rings from vector
- * add_tunnel_udp()
- * Add tunnel information to hardware
- * del_tunnel_udp()
- * Delete tunnel information from hardware
* reset_queue()
* Reset queue
* get_fw_version()
@@ -388,9 +384,6 @@ struct hnae3_ae_ops {
int vector_num,
struct hnae3_ring_chain_node *vr_chain);
- int (*add_tunnel_udp)(struct hnae3_handle *handle, u16 port_num);
- int (*del_tunnel_udp)(struct hnae3_handle *handle, u16 port_num);
-
void (*reset_queue)(struct hnae3_handle *handle, u16 queue_id);
u32 (*get_fw_version)(struct hnae3_handle *handle);
void (*get_mdix_mode)(struct hnae3_handle *handle,
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index a55c8f515..bd8e14b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1244,93 +1244,6 @@ static void hns3_nic_get_stats64(struct net_device *netdev,
stats->tx_compressed = netdev->stats.tx_compressed;
}
-static void hns3_add_tunnel_port(struct net_device *netdev, u16 port,
- enum hns3_udp_tnl_type type)
-{
- struct hns3_nic_priv *priv = netdev_priv(netdev);
- struct hns3_udp_tunnel *udp_tnl = &priv->udp_tnl[type];
- struct hnae3_handle *h = priv->ae_handle;
-
- if (udp_tnl->used && udp_tnl->dst_port == port) {
- udp_tnl->used++;
- return;
- }
-
- if (udp_tnl->used) {
- netdev_warn(netdev,
- "UDP tunnel [%d], port [%d] offload\n", type, port);
- return;
- }
-
- udp_tnl->dst_port = port;
- udp_tnl->used = 1;
- /* TBD send command to hardware to add port */
- if (h->ae_algo->ops->add_tunnel_udp)
- h->ae_algo->ops->add_tunnel_udp(h, port);
-}
-
-static void hns3_del_tunnel_port(struct net_device *netdev, u16 port,
- enum hns3_udp_tnl_type type)
-{
- struct hns3_nic_priv *priv = netdev_priv(netdev);
- struct hns3_udp_tunnel *udp_tnl = &priv->udp_tnl[type];
- struct hnae3_handle *h = priv->ae_handle;
-
- if (!udp_tnl->used || udp_tnl->dst_port != port) {
- netdev_warn(netdev,
- "Invalid UDP tunnel port %d\n", port);
- return;
- }
-
- udp_tnl->used--;
- if (udp_tnl->used)
- return;
-
- udp_tnl->dst_port = 0;
- /* TBD send command to hardware to del port */
- if (h->ae_algo->ops->del_tunnel_udp)
- h->ae_algo->ops->del_tunnel_udp(h, port);
-}
-
-/* hns3_nic_udp_tunnel_add - Get notifiacetion about UDP tunnel ports
- * @netdev: This physical ports's netdev
- * @ti: Tunnel information
- */
-static void hns3_nic_udp_tunnel_add(struct net_device *netdev,
- struct udp_tunnel_info *ti)
-{
- u16 port_n = ntohs(ti->port);
-
- switch (ti->type) {
- case UDP_TUNNEL_TYPE_VXLAN:
- hns3_add_tunnel_port(netdev, port_n, HNS3_UDP_TNL_VXLAN);
- break;
- case UDP_TUNNEL_TYPE_GENEVE:
- hns3_add_tunnel_port(netdev, port_n, HNS3_UDP_TNL_GENEVE);
- break;
- default:
- netdev_err(netdev, "unsupported tunnel type %d\n", ti->type);
- break;
- }
-}
-
-static void hns3_nic_udp_tunnel_del(struct net_device *netdev,
- struct udp_tunnel_info *ti)
-{
- u16 port_n = ntohs(ti->port);
-
- switch (ti->type) {
- case UDP_TUNNEL_TYPE_VXLAN:
- hns3_del_tunnel_port(netdev, port_n, HNS3_UDP_TNL_VXLAN);
- break;
- case UDP_TUNNEL_TYPE_GENEVE:
- hns3_del_tunnel_port(netdev, port_n, HNS3_UDP_TNL_GENEVE);
- break;
- default:
- break;
- }
-}
-
static int hns3_setup_tc(struct net_device *netdev, void *type_data)
{
struct tc_mqprio_qopt_offload *mqprio_qopt = type_data;
@@ -1569,8 +1482,6 @@ static const struct net_device_ops hns3_nic_netdev_ops = {
.ndo_get_stats64 = hns3_nic_get_stats64,
.ndo_setup_tc = hns3_nic_setup_tc,
.ndo_set_rx_mode = hns3_nic_set_rx_mode,
- .ndo_udp_tunnel_add = hns3_nic_udp_tunnel_add,
- .ndo_udp_tunnel_del = hns3_nic_udp_tunnel_del,
.ndo_vlan_rx_add_vid = hns3_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = hns3_vlan_rx_kill_vid,
.ndo_set_vf_vlan = hns3_ndo_set_vf_vlan,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/4] net: hns3: Fix for setting mac address when resetting
From: Salil Mehta @ 2018-05-09 16:24 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Yunsheng Lin
In-Reply-To: <20180509162441.18068-1-salil.mehta@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
When hns3_init_mac_addr is called during reset process, it will
get the mac address from NCL_CONFIG and set it to hardware. If
user has changed the mac address, then the mac address set by
user is lost during resetting.
This patch fixes it by not getting the mac address from NCL_CONFIG
when resetting.
Fixes: 424eb834a9be ("net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08 SoC")
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 729bcab..a55c8f515 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3046,13 +3046,13 @@ int hns3_uninit_all_ring(struct hns3_nic_priv *priv)
}
/* Set mac addr if it is configured. or leave it to the AE driver */
-static void hns3_init_mac_addr(struct net_device *netdev)
+static void hns3_init_mac_addr(struct net_device *netdev, bool init)
{
struct hns3_nic_priv *priv = netdev_priv(netdev);
struct hnae3_handle *h = priv->ae_handle;
u8 mac_addr_temp[ETH_ALEN];
- if (h->ae_algo->ops->get_mac_addr) {
+ if (h->ae_algo->ops->get_mac_addr && init) {
h->ae_algo->ops->get_mac_addr(h, mac_addr_temp);
ether_addr_copy(netdev->dev_addr, mac_addr_temp);
}
@@ -3106,7 +3106,7 @@ static int hns3_client_init(struct hnae3_handle *handle)
handle->kinfo.netdev = netdev;
handle->priv = (void *)priv;
- hns3_init_mac_addr(netdev);
+ hns3_init_mac_addr(netdev, true);
hns3_set_default_feature(netdev);
@@ -3353,7 +3353,7 @@ static int hns3_reset_notify_init_enet(struct hnae3_handle *handle)
struct hns3_nic_priv *priv = netdev_priv(netdev);
int ret;
- hns3_init_mac_addr(netdev);
+ hns3_init_mac_addr(netdev, false);
hns3_nic_set_rx_mode(netdev);
hns3_recover_hw_addr(netdev);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 0/4] Misc bug fixes for HNS3 Ethernet Driver
From: Salil Mehta @ 2018-05-09 16:24 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm
Fixes to some of the bugs found during system test, internal review
and clean-up
Yunsheng Lin (4):
net: hns3: Fix for setting mac address when resetting
net: hns3: remove add/del_tunnel_udp in hns3_enet module
net: hns3: fix for cleaning ring problem
net: hns3: refactor the loopback related function
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 7 --
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 131 ++++++---------------
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 21 ++--
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 68 +++++------
4 files changed, 76 insertions(+), 151 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH] ixgbe: fix memory leak on ipsec allocation
From: Shannon Nelson @ 2018-05-09 16:22 UTC (permalink / raw)
To: Colin King, Jeff Kirsher, David S . Miller, intel-wired-lan,
netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20180509135848.20530-1-colin.king@canonical.com>
On 5/9/2018 6:58 AM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The error clean up path kfree's adapter->ipsec and should be
> instead kfree'ing ipsec. Fix this. Also, the err1 error exit path
> does not need to kfree ipsec because this failure path was for
> the failed allocation of ipsec.
>
> Detected by CoverityScan, CID#146424 ("Resource Leak")
>
> Fixes: 63a67fe229ea ("ixgbe: add ipsec offload add and remove SA")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Yep, thanks, good catch.
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> index 41af2b81e960..195c0b65eee2 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> @@ -919,8 +919,8 @@ void ixgbe_init_ipsec_offload(struct ixgbe_adapter *adapter)
> kfree(ipsec->ip_tbl);
> kfree(ipsec->rx_tbl);
> kfree(ipsec->tx_tbl);
> + kfree(ipsec);
> err1:
> - kfree(adapter->ipsec);
> netdev_err(adapter->netdev, "Unable to allocate memory for SA tables");
> }
>
>
^ permalink raw reply
* Re: [PATCH bpf] nfp: bpf: allow zero-length capabilities
From: Daniel Borkmann @ 2018-05-09 16:18 UTC (permalink / raw)
To: Jakub Kicinski, alexei.starovoitov; +Cc: oss-drivers, netdev
In-Reply-To: <20180509024241.24032-1-jakub.kicinski@netronome.com>
On 05/09/2018 04:42 AM, Jakub Kicinski wrote:
> Some BPF capabilities carry no value, they simply indicate feature
> is present. Our capability parsing loop will exit early if last
> capability is zero-length because it's looking for more than 8 bytes
> of data (8B is our TLV header length). Allow the last capability to
> be zero-length.
>
> This bug would lead to driver failing to probe with the following error
> if the last capability FW advertises is zero-length:
>
> nfp: BPF capabilities left after parsing, parsed:92 total length:100
> nfp: invalid BPF capabilities at offset:92
>
> Note the "parsed" and "length" values are 8 apart.
>
> No shipping FW runs into this issue, but we can't guarantee that will
> remain the case.
>
> Fixes: 77a844ee650c ("nfp: bpf: prepare for parsing BPF FW capabilities")
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
Applied to bpf tree, thanks!
^ permalink raw reply
* Re: [PATCH bpf-next] xsk: fix 64-bit division
From: Daniel Borkmann @ 2018-05-09 16:13 UTC (permalink / raw)
To: Randy Dunlap, Björn Töpel, ast, netdev
Cc: Björn Töpel, Stephen Rothwell, magnus.karlsson,
linux-next, linux-kernel
In-Reply-To: <baf737cf-a0c4-b542-8d37-fd9cdfe7101d@infradead.org>
On 05/07/2018 08:25 PM, Randy Dunlap wrote:
> On 05/07/2018 10:43 AM, Björn Töpel wrote:
>> From: Björn Töpel <bjorn.topel@intel.com>
>>
>> i386 builds report:
>> net/xdp/xdp_umem.o: In function `xdp_umem_reg':
>> xdp_umem.c:(.text+0x47e): undefined reference to `__udivdi3'
>>
>> This fix uses div_u64 instead of the GCC built-in.
>>
>> Fixes: c0c77d8fb787 ("xsk: add user memory registration support sockopt")
>> Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
>
> I don't know why the subject says xsk (instead of xdp), but anyway:
>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Tested-by: Randy Dunlap <rdunlap@infradead.org>
Applied to bpf-next, thanks everyone!
^ permalink raw reply
* Re: KASAN: use-after-free Read in __dev_queue_xmit
From: Willem de Bruijn @ 2018-05-09 16:11 UTC (permalink / raw)
To: Eric Biggers
Cc: Eric Dumazet, Eric Dumazet, syzbot, alexander.deucher,
Andrey Konovalov, Anoob Soman, chris, David Miller,
Reshetova, Elena, Greg Kroah-Hartman, Kees Cook, LKML,
Mike Maloney, mchehab, netdev, Rosen, Rami, Sowmini Varadhan,
syzkaller-bugs, Willem de Bruijn
In-Reply-To: <20180509073754.GG711@sol.localdomain>
On Wed, May 9, 2018 at 3:37 AM, Eric Biggers <ebiggers3@gmail.com> wrote:
> On Wed, Jan 03, 2018 at 10:53:14PM -0800, Eric Dumazet wrote:
>> 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 bug triggered for this particular repro is in flow dissector
>> :/
>>
>> I will test :
>>
>> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
>> index 15ce300637650e17fcab7e378b20fe7972686d46..544bddf08e13c7f6e47aadc737244c9ba5af56b2 100644
>> --- a/net/core/flow_dissector.c
>> +++ b/net/core/flow_dissector.c
>> @@ -976,8 +976,8 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>> out_good:
>> ret = true;
>>
>> - key_control->thoff = (u16)nhoff;
>> out:
>> + key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
>> key_basic->n_proto = proto;
>> key_basic->ip_proto = ip_proto;
>>
>> @@ -985,7 +985,6 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>>
>> out_bad:
>> ret = false;
>> - key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
>> goto out;
>> }
>> EXPORT_SYMBOL(__skb_flow_dissect);
>
> Fix for this was commit d0c081b49137cd:
>
> #syz fix: flow_dissector: properly cap thoff field
>
> But a crash with the same signature is still occurring, so it should eventually
> get reported again. C reproducer is here, it works on Linus' tree (commit
> 036db8bd963): https://syzkaller.appspot.com/text?tag=ReproC&x=105b1ae7800000
This appears to be a separate issue.
This reproducer requires a setsockopt SOL_SOCKET/SO_TIMESTAMPING
to trigger the use-after-free. And the freed path also points at a timestamping
skb:
[ 31.963619] Freed by task 2672:
[ 31.964006] __kasan_slab_free+0x125/0x170
[ 31.964509] kfree+0x8b/0x1a0
[ 31.964875] skb_free_head+0x6f/0xa0
[ 31.965314] skb_release_data+0x420/0x5a0
[ 31.965802] skb_release_all+0x46/0x60
[ 31.966260] kfree_skb+0x91/0x1c0
[ 31.966669] __skb_complete_tx_timestamp+0x2e9/0x3d0
[ 31.967273] __skb_tstamp_tx+0x3b3/0x620
[ 31.967774] __dev_queue_xmit+0xed5/0x1a20
[ 31.968300] packet_sendmsg+0x36fd/0x5400
[ 31.968821] sock_sendmsg+0xc0/0x100
[ 31.969284] ___sys_sendmsg+0x367/0x880
[ 31.969777] __sys_sendmmsg+0x178/0x410
[ 31.970267] __x64_sys_sendmmsg+0x99/0x100
[ 31.970789] do_syscall_64+0x9a/0x2c0
[ 31.971260] entry_SYSCALL_64_after_hwframe+0x44/0xa9
The data skb itself is zero bytes, it appears.
^ permalink raw reply
* Re: [PATCH bpf-next 0/2] nfp: bpf: add programmable RSS support
From: Daniel Borkmann @ 2018-05-09 16:09 UTC (permalink / raw)
To: Alexei Starovoitov, Jakub Kicinski; +Cc: davem, netdev, oss-drivers
In-Reply-To: <20180509024215.xnlajxrua7jluoon@ast-mbp>
On 05/09/2018 04:42 AM, Alexei Starovoitov wrote:
> On Tue, May 08, 2018 at 07:37:05PM -0700, Jakub Kicinski wrote:
>> Hi!
>>
>> This small series adds a feature which extends BPF offload beyond
>> a pure host processing offload and firmly into the realm of
>> heterogeneous processing. Allowing offloaded XDP programs to set
>> the RX queue index opens the door for defining fully programmable
>> RSS/n-tuple filter replacement. In fact the device datapath will
>> skip the RSS processing completely if BPF decided on the queue
>> already, making the XDP program replace part of the standard NIC
>> datapath.
>
> Absolutely love it!
> Huge feature enabled by such tiny diff.
>
> For the set:
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Second that! Applied to bpf-next, thanks Jakub!
^ permalink raw reply
* Re: [PATCH bpf-next 0/6] Introduce BTF ID
From: Daniel Borkmann @ 2018-05-09 16:08 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, kernel-team
In-Reply-To: <20180504214955.1058805-1-kafai@fb.com>
On 05/04/2018 11:49 PM, Martin KaFai Lau wrote:
> This series introduces BTF ID which is exposed through
> the new BPF_BTF_GET_FD_BY_ID cmd, new "struct bpf_btf_info"
> and new members in the "struct bpf_map_info".
>
> Please see individual patch for details.
Applied to bpf-next, thanks Martin!
^ permalink raw reply
* Re: [bpf-next v2 8/9] bpf: Provide helper to do forwarding lookups in kernel FIB table
From: David Ahern @ 2018-05-09 16:05 UTC (permalink / raw)
To: Daniel Borkmann, netdev, borkmann, ast
Cc: davem, shm, roopa, brouer, toke, john.fastabend
In-Reply-To: <433c2320-ed9b-446e-6e29-92075f947251@iogearbox.net>
On 5/9/18 2:15 AM, Daniel Borkmann wrote:
>
> Ohh well, this is causing allmodconfig build warnings (e.g. on x86) as reported today:
lovely.
>
> In file included from include/linux/dma-mapping.h:5:0,
> from include/linux/skbuff.h:34,
> from include/linux/if_ether.h:23,
> from include/uapi/linux/bpf.h:13,
> from include/linux/bpf-cgroup.h:6,
> from include/linux/cgroup-defs.h:22,
> from include/linux/cgroup.h:28,
> from include/linux/perf_event.h:57,
> from include/linux/trace_events.h:10,
> from include/trace/trace_events.h:20,
> from include/trace/define_trace.h:96,
> from drivers/android/binder_trace.h:387,
> from drivers/android/binder.c:5702:
> include/linux/sizes.h:24:0: warning: "SZ_1K" redefined
> #define SZ_1K 0x00000400
> drivers/android/binder.c:116:0: note: this is the location of the previous definition
> #define SZ_1K 0x400
binder.c has very few recent commits to it. Are you ok with me
submitting the change with the others in this set (with proper cc's of
course)?
> fs/ecryptfs/miscdev.c:206:0: warning: "PKT_TYPE_OFFSET" redefined
> #define PKT_TYPE_OFFSET 0
> In file included from include/linux/if_ether.h:23:0,
> from include/uapi/linux/bpf.h:13,
> from include/linux/bpf-cgroup.h:6,
> from include/linux/cgroup-defs.h:22,
> from include/linux/cgroup.h:28,
> from include/linux/writeback.h:183,
> from include/linux/backing-dev.h:16,
> from fs/ecryptfs/ecryptfs_kernel.h:41,
> from fs/ecryptfs/miscdev.c:30:
> include/linux/skbuff.h:753:0: note: this is the location of the previous definition
> #define PKT_TYPE_OFFSET() offsetof(struct sk_buff, __pkt_type_offset)
And this one I renamed to SKB_PKT_TYPE_OFFSET
With that it compiles cleanly.
>
> Lets get a clean, proper version of the whole series into bpf-next. I've dropped it
> from there right now and waiting for your v3 respin to apply with the above fixed.
>
> Thank you.
>
^ permalink raw reply
* [PATCH net-next] hv_netvsc: typo in NDIS RSS parameters structure
From: Stephen Hemminger @ 2018-05-09 16:00 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
Fix simple misspelling kashkey_offset should be hashkey_offset.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
drivers/net/hyperv/hyperv_net.h | 2 +-
drivers/net/hyperv/rndis_filter.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 6ebe39a3dde6..1be34d2e3563 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -110,7 +110,7 @@ struct ndis_recv_scale_param { /* NDIS_RECEIVE_SCALE_PARAMETERS */
u16 hashkey_size;
/* The offset of the secret key from the beginning of this structure */
- u32 kashkey_offset;
+ u32 hashkey_offset;
u32 processor_masks_offset;
u32 num_processor_masks;
diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
index 3b6dbacaf77d..3cb2c4666b2c 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -752,7 +752,7 @@ int rndis_filter_set_rss_param(struct rndis_device *rdev,
rssp->indirect_tabsize = 4*ITAB_NUM;
rssp->indirect_taboffset = sizeof(struct ndis_recv_scale_param);
rssp->hashkey_size = NETVSC_HASH_KEYLEN;
- rssp->kashkey_offset = rssp->indirect_taboffset +
+ rssp->hashkey_offset = rssp->indirect_taboffset +
rssp->indirect_tabsize;
/* Set indirection table entries */
@@ -761,7 +761,7 @@ int rndis_filter_set_rss_param(struct rndis_device *rdev,
itab[i] = rdev->rx_table[i];
/* Set hask key values */
- keyp = (u8 *)((unsigned long)rssp + rssp->kashkey_offset);
+ keyp = (u8 *)((unsigned long)rssp + rssp->hashkey_offset);
memcpy(keyp, rss_key, NETVSC_HASH_KEYLEN);
ret = rndis_filter_send_request(rdev, request);
--
2.17.0
^ permalink raw reply related
* Re: [net-next PATCH v2 0/8] UDP GSO Segmentation clean-ups
From: Alexander Duyck @ 2018-05-09 15:58 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Network Development, Willem de Bruijn, David Miller
In-Reply-To: <CAF=yD-+=9EUjiT=ZG+G=phQcHmD8s3e6mydhBehddVCqL0pEGg@mail.gmail.com>
On Wed, May 9, 2018 at 8:39 AM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> On Mon, May 7, 2018 at 2:02 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Sat, May 5, 2018 at 3:06 AM, Willem de Bruijn
>> <willemdebruijn.kernel@gmail.com> wrote:
>>> On Fri, May 4, 2018 at 8:28 PM, Alexander Duyck
>>> <alexander.duyck@gmail.com> wrote:
>>>> This patch set addresses a number of issues I found while sorting out
>>>> enabling UDP GSO Segmentation support for ixgbe/ixgbevf. Specifically there
>>>> were a number of issues related to the checksum and such that seemed to
>>>> cause either minor irregularities or kernel panics in the case of the
>>>> offload request being allowed to traverse between name spaces.
>>>
>>> Were you able to traverse GSO packets between network namespace before
>>> adding to NETIF_F_GSO_SOFTWARE? It does appear that veth includes
>>> NETIF_F_GSO_ENCAP_ALL, which also allows GSO.
>>
>> Without that change the tunnel wouldn't pass the requests between
>> namespaces. However with it I was able to easily test the software
>> checksum code as otherwise the socket was returning EIO when the
>> hardware checksum was disabled.
>>
>>> In either case, it should not be possible for GSO packets to arrive on a veth
>>> device, as that can result in queuing the GSO packet to a recipient socket.
>>> In this regard veth is like loopback and must exclude GSO support.
>>>
>>> I'll take a look.
>>
>> I suspect it was probably sending veth UDP segmentation offload
>> requests. For now I can probably drop he patch that was adding it and
>> it can be added later to individual drivers if needed.
>
> I just tested udpgso_bench_tx over veth (on a commit without your
> patchset).
>
> Having NETIF_F_GSO_UDP_L4 in NETIF_F_GSO_ENCAP_ALL
> and NETIF_F_GSO_ENCAP_ALL in VETH_FEATURES is
> sufficient to receive large packets on the veth peer.
>
> This is clearly a bug, as is for any device that may loop packets
> onto a local socket. Such as macvlan in bridge mode.
>
> I will have to revise commit 83aa025f535f ("udp: add gso support
> to virtual devices")
>
> It remains useful to have this capability on the bonding device. I
> might remove the flag from NETIF_F_GSO_ENCAP_ALL and add
> it specifically to that device.
>
> This is also all relevant to future work of NETIF_F_GSO_SOFTWARE.
Sounds like a plan. In the meantime I am going to see about getting
some internal paperwork taken care of to get UDP GSO added to
ixgbe/ixgbevf as an official feature.
I need to finish up some work I am doing on macvlan over the next
couple of weeks so I won't be focusing on this code for the next month
or so.
Thanks.
- Alex
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox