* Re: [PATCH RFC net-next] net: SAIL based FIB lookup for XDP
From: David Ahern @ 2018-11-18 17:42 UTC (permalink / raw)
To: Md. Islam, Netdev, Jesper Dangaard Brouer, David Miller,
Stephen Hemminger, john fastabend, Alexey Kuznetsov
In-Reply-To: <CAFgPn1CDS=1yveZJKZQ6QZkbUwJJZ6qfJLPM2CFj1nuX-K1+EA@mail.gmail.com>
On 11/11/18 7:25 PM, Md. Islam wrote:
> This patch implements SAIL[1] based routing table lookup for XDP. I
> however made some changes from the original proposal (details are
> described in the patch). This changes decreased the memory consumption
> from 21.94 MB to 4.97 MB for my example routing table with 400K
> routes.
>
> This patch can perform FIB lookup in 50 CPU cycles for the example
> routing table (with 400K routes) whereas LC-trie takes around 350 CPU
> cycles.
>
> I tried to follow all the advice I got from my last patch. Looking
> forward to your review.
>
> 1. Yang, Tong, et al. "Guarantee IP lookup performance with FIB
> explosion." ACM SIGCOMM Computer Communication Review. Vol. 44. No. 4.
> ACM, 2014.
This work you are doing on different FIB algorithms is interesting and
probably has its use cases where it is beneficial, but you are still not
integrating it into the Linux stack correctly.
For starters, it is wrong to have 2 separate FIB data structures for the
same network namespace. If SAIL is good enough for XDP, it should be
good enough for normal routing in the namespace. There is no need to put
the same route data in 2 places. That means the FIB algorithm needs to
be selectable - either trie or sail but not both.
Further, you are not handling unexpected conditions - e.g., multipath or
lwtunnel encaps, cleanup of device references on a FIB entry delete or
device overflows ...
> diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
> index 69c91d1..cc275c7 100644
> --- a/include/net/ip_fib.h
> +++ b/include/net/ip_fib.h
> @@ -197,6 +197,62 @@ struct fib_entry_notifier_info {
> u32 tb_id;
> };
>
> +#if IS_ENABLED(CONFIG_FIB_SAIL_XDP)
> +/*
> + * The router can have upto 255 ports. This limitation
> + * allows us to represent netdev_index as an u8
> + */
> +#define NETDEV_COUNT_MAX 255
... 255 is high for a physical port count but not a logical device
count. In the presence of VLANs 255 is nothing and VLANs are an
essential deployment feature.
> +
> +struct chunk {
chunk is too generic. sail_chunk at least puts it in the sail symbol
namespace.
> + /*256-bit bitmap. Here i-th bit (from LSB) is set to 1 if C24[i] > 0 */
> + u64 bitmap[4];
> + /*
> + * Index to C24 where chunk is started. A chunk corresponds
> + * to 256 elements. Instead of having just one start index for the
> + * whole chunk, we divide the chunk into 4 parts and save start
> + * index for each part.
> + */
> + u64 start_index[4];
> +};
> +
> +struct sail {
> + /*default next-hop (Level 0)*/
> + u8 def_nh;
> +
> + /*Level 16*/
> + u8 __rcu *N16;
> + u8 __rcu *P16;
> + u16 __rcu *C16;
> +
> + /*Level 24*/
> + u8 __rcu *N24;
> + u8 __rcu *P24;
> + struct chunk __rcu *CK24;
> + u32 __rcu *C24;
> + u32 cnk24_count;/*Number of chunks in level 24*/
> +
> + /*Level 32*/
> + u8 __rcu *N32;
> + u8 __rcu *P32;
> + u32 cnk32_count;/*Number of chunks in level 32*/
> +
> + /*Index to this array is stored in N16, N24 and N32*/
> + struct net_device *netdevs[NETDEV_COUNT_MAX];
> + u8 netdev_count;/*Number of netdevs*/
> +
> + spinlock_t lock;
> +};
> +
> +int sail_insert(struct sail *s, u32 key,
> + u8 prefix_len, struct net_device *dev);
> +int sail_delete(struct sail *s, u32 key,
> + u8 prefix_len);
> +int sail_flush(struct sail *s);
> +int sail_lookup(const struct sail *s, const __be32 dest,
> + struct net_device **dev);
> +#endif
Put the new FIB algorithm specific defines in a new header.
> +
> struct fib_nh_notifier_info {
> struct fib_notifier_info info; /* must be first */
> struct fib_nh *fib_nh;
> @@ -219,6 +275,10 @@ struct fib_table {
> int tb_num_default;
> struct rcu_head rcu;
> unsigned long *tb_data;
> +#if IS_ENABLED(CONFIG_FIB_SAIL_XDP)
> + /*Each FIB table will have its own SAIL structure.*/
> + struct sail sail;
Per comment above a separate sail entry is unnecessary when this
algorithm is an alternative to trie; It overlaps tb_data - see code
references for it.
> +#endif
> unsigned long __data[0];
> };
>
...
> diff --git a/net/ipv4/fib_sail_xdp.c b/net/ipv4/fib_sail_xdp.c
> new file mode 100644
> index 0000000..f3f56c5
> --- /dev/null
> +++ b/net/ipv4/fib_sail_xdp.c
> @@ -0,0 +1,939 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2018-19 MD Iftakharul Islam (Tamim) <mislam4@kent.edu>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + *
> + *
> + * This is SAIL_L based routing table lookup which was initially proposed in:
> + *
> + * Yang, Tong, Gaogang Xie, YanBiao Li, Qiaobin Fu, Alex X. Liu, Qi Li,
> + * and Laurent Mathy. "Guarantee IP lookup performance with FIB explosion."
> + * In ACM SIGCOMM Computer Communication Review, vol. 44, no. 4, pp. 39-50.
> + * ACM, 2014.
> + *
> + * It however deviates from the SAIL_L in three ways:
> + *
> + * 1. It pushes all the solid nodes in level 1~15 to level 16 whereas SAIL_L
> + * pushes them to either level 16, level 24 or level 32.
> + *
> + * 2. It pushes all the solid nodes in level 17~23 to level 24 whereas SAIL_L
> + * pushes them to either level 24 or level 32.
> + *
> + * 3. It adds a bitmap array, CK24 in addition to C24. This reduces the memory
> + * memory requirement of original C24 from 17.08 MB to 110KB for our example
> + * routing table.
> + */
> +
> +#include <net/ip_fib.h>
> +
> +/*The length of N16, P16 and C16 is 2^16*/
> +#define LEVEL16_SIZE 65536
> +
> +/*Length of C24.*/
> +#define C24_SIZE 1048576
> +
> +/*chunk size is 2^8*/
> +#define CHUNK_SIZE 256
> +
> +/*Total number of chunks preallocated for level 24 and 32*/
> +#define NUM_CHUNKS 16384
> +
> +/*Calculates the number of bits set to 1*/
> +#define POPCNT(X) (hweight64(X))
> +
> +/*POPCNT of left-most N bits of X*/
> +#define POPCNT_OFF(X, N) (hweight64(((1ULL << (N)) - 1) & (X)))
> +
> +/*Calculate index to C24 from CK26 chunk and chunk offset */
> +static u64 calc_c24_idx(struct chunk c, u32 cnk_off)
> +{
> + u8 part_idx, part_off;
> +
> + part_idx = cnk_off / 64;
> + part_off = cnk_off % 64;
> +
> + return c.start_index[part_idx] +
> + POPCNT_OFF(c.bitmap[part_idx], part_off);
> +}
> +
> +/*Converts a net_device to corresponding netdev_index*/
> +static u8 get_netdev_index(struct sail *s, struct net_device *dev)
> +{
> + u8 i;
> +
> + /*checks if the net_device is already seen; if yes then return the
> + *corresponding index
> + */
> + for (i = 0; i < s->netdev_count; i++) {
> + if (s->netdevs[i] == dev)
> + return i;
Linearly walking this array puts a hit on the insert time. Control
management (insert and delete times) are important as well. It is a
trade-off between data plane performance and control plane performance.
You should compare insert and delete times too.
> + }
> + /*If the net_device is not previously seen, then add it to the array*/
> + s->netdevs[s->netdev_count++] = dev;
> + return s->netdev_count - 1;
> +}
Nothing is preventing a route from being inserted using netdev 256; you
are just wrapping the counter and inserting the device which breaks
existing FIB entries using that netdev entry.
What about deletes? I don't see you ever reset the index or check for
holes (unused entries) in the array.
> +int sail_insert(struct sail *s, u32 key, u8 prefix_len,
> + struct net_device *dev)
you are assuming single path routes - an assumption that needs to be
codified, not ignored.
> +{
> + int i;
> + u8 *n16, *p16, *n24, *p24, *n32, *p32;
> + u16 *c16;
> + u32 *c24;
> + struct chunk *ck24;
> + u16 chunk_id;
> + u16 n16_idx;/*Index to N16, P16 and C16*/
> + u64 n24_idx;/*Index to N24 and P24*/
> + u64 c24_idx;/*Index to C24*/
> + u32 ck24_idx;/*Index to CK24*/
> + u64 ck24_off;/*offset inside a chunk*/
> + u8 part_idx, part_off;
> + u64 n32_idx;/*Index to N32 and P32*/
> + u32 num_leafs;/*Number of leafs need to be inserted for this prefix*/
> + u8 netdev_index = get_netdev_index(s, dev);
> + int err = 0;
> +
> + spin_lock(&s->lock);
> +
> + /* Default route */
> + if (prefix_len == 0) {
> + s->def_nh = netdev_index;
> + goto finish;
> + }
> +
> + /* Preallocate all the arrays at once*/
> + if (!s->N16) {
> + n16 = kcalloc(LEVEL16_SIZE, sizeof(*n16), GFP_ATOMIC);
> + p16 = kcalloc(LEVEL16_SIZE, sizeof(*p16), GFP_ATOMIC);
> + c16 = kcalloc(LEVEL16_SIZE, sizeof(*c16), GFP_ATOMIC);
> + n24 = kcalloc(NUM_CHUNKS * CHUNK_SIZE, sizeof(*n24),
> + GFP_ATOMIC);
> + p24 = kcalloc(NUM_CHUNKS * CHUNK_SIZE, sizeof(*p24),
> + GFP_ATOMIC);
> + ck24 = kcalloc(NUM_CHUNKS, sizeof(*ck24), GFP_ATOMIC);
> + c24 = kcalloc(C24_SIZE, sizeof(*c24), GFP_ATOMIC);
> + n32 = kcalloc(NUM_CHUNKS * CHUNK_SIZE, sizeof(*n32),
> + GFP_ATOMIC);
> + p32 = kcalloc(NUM_CHUNKS * CHUNK_SIZE, sizeof(*p32),
> + GFP_ATOMIC);
> +
> + if (!n16 || !c16 || !p16 || !n24 || !p24 || !ck24 ||
> + !c24 || !n32 || !p32) {
> + kfree(n16);
> + kfree(c16);
> + kfree(p16);
> + kfree(n24);
> + kfree(p24);
> + kfree(ck24);
> + kfree(c24);
> + kfree(n32);
> + kfree(p32);
> + pr_err("Out of memory while preallocating SAIL");
> + goto error;
> + }
> +
> + RCU_INIT_POINTER(s->N16, n16);
> + RCU_INIT_POINTER(s->P16, p16);
> + RCU_INIT_POINTER(s->C16, c16);
> + RCU_INIT_POINTER(s->N24, n24);
> + RCU_INIT_POINTER(s->P24, p24);
> + RCU_INIT_POINTER(s->CK24, ck24);
> + RCU_INIT_POINTER(s->C24, c24);
> + RCU_INIT_POINTER(s->N32, n32);
> + RCU_INIT_POINTER(s->P32, p32);
> +
> + synchronize_rcu();
this initialization needs to be done as part of namespace init, not
first FIB insert.
You really need to spend time looking at how to make sail, poptrie and
anything else an alternative to LC trie as opposed to a duplicate algorithm.
^ permalink raw reply
* Re: [PATCH] rhashtable: detect when object movement between tables might have invalidated a lookup
From: Herbert Xu @ 2018-11-19 4:06 UTC (permalink / raw)
To: NeilBrown; +Cc: David Miller, tgraf, netdev, linux-kernel, eric.dumazet
In-Reply-To: <20181119035635.2tizfk3vrmxfrr6e@gondor.apana.org.au>
On Mon, Nov 19, 2018 at 11:56:35AM +0800, Herbert Xu wrote:
>
> I take that back. Because of your shift which cancels out the
> shift in NULLS_MARKER, it would appear that this should work just
> fine with RHT_NULLS_MARRKER(0), no? IOW, it would appear that
>
> RHT_NULLS_MARKER(0) = RHT_NULLS_MARKER(RHT_NULLS_MARKER(0))
My emails to Neil are bouncing:
neilb@suse.com
host smtp.glb1.softwaregrp.com [15.124.2.87]
SMTP error from remote mail server after RCPT TO:<neilb@suse.com>:
550 Cannot process address
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH RFC net-next] net: SAIL based FIB lookup for XDP
From: Andrew Lunn @ 2018-11-18 17:52 UTC (permalink / raw)
To: David Ahern
Cc: Md. Islam, Netdev, Jesper Dangaard Brouer, David Miller,
Stephen Hemminger, john fastabend, Alexey Kuznetsov
In-Reply-To: <f427155e-685c-adb6-1a2e-c78b9f1511f6@gmail.com>
> > + * The router can have upto 255 ports. This limitation
> > + * allows us to represent netdev_index as an u8
> > + */
> > +#define NETDEV_COUNT_MAX 255
>
> ... 255 is high for a physical port count but not a logical device
> count. In the presence of VLANs 255 is nothing and VLANs are an
> essential deployment feature.
I agree with David here. Doing some network simulation work using
namespaces, i've had more than 255 devices in the root namespace.
Andrew
^ permalink raw reply
* Re: DSA support for Marvell 88e6065 switch
From: Pavel Machek @ 2018-11-18 18:07 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, f.fainelli, buytenh, buytenh, nico
In-Reply-To: <20181115202618.GF32274@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]
On Thu 2018-11-15 21:26:18, Andrew Lunn wrote:
> On Thu, Nov 15, 2018 at 08:51:11PM +0100, Pavel Machek wrote:
> > Hi!
> >
> > I'm trying to create support for Marvell 88e6065 switch... and it
> > seems like drivers/net/dsa supports everything, but this model.
> >
> > Did someone work with this hardware before? Any idea if it would be
> > more suitable to support by existing 88e6060 code, or if 88e6xxx code
> > should serve as a base?
>
> Hi Pavel
>
> The 88e6xxx should be extended to support this. I think you will find
> a lot of the building blocks are already in the driver. Compare the
> various implementations of the functions in the mv88e6xxx_ops to what
> the datasheet says for the registers, and pick those that match.
Ok, so I played a bit.
It looks like e6065 has different register layout from those supported
by 6xxx, and is quite similar to e6060.
I understand how 88e6xxx code is supposed to work... but I don't
understand how e6060 code is supposed to be probed. It does not seem
to have device tree support. It seems to be older code, but is way
simpler, and seems to be targetted at similar hardware.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: Linux kernel hangs if using RV1108 with MSZ8863 switch with two ports connected
From: Andrew Lunn @ 2018-11-18 18:12 UTC (permalink / raw)
To: Otavio Salvador; +Cc: netdev, Heiko Stuebner, david.choi, Andy Yan
In-Reply-To: <CAP9ODKqK6VgLYFM-2Qhvq+32HMwUaBg2-zBWEez7RqXH8FMdkQ@mail.gmail.com>
> The kernel starts booting normally and then hangs like this when two
> Ethernet cables are connected to the KSZ8863 switch:
> http://dark-code.bulix.org/3xexu5-507563
>
> This has the lock detection, inside kernel hacking, enabled.
Maybe turn on all the hung-task debug and magic key support. With
magic key, you might be able to get a backtrace of where it is
spinning.
Maybe also add #define DEBUG at the top of drivers/net/phy/phy.c.
Does it hang during a PHY state transition?
Maybe both PHYs are interrupting at the same time, and the interrupt
code is broken?
Maybe look at the switch driver and see if there is any code which is
executed on link up. Put some printk() in there.
If you PHYs are using interrupt mode, maybe disable that and use
polling.
Do you know if this ever worked properly before? If you know when it
did work, you can do a git bisect to narrow it down to the one patch
which broke it..
Basically, at the moment, you just need to try lots of things, to
narrow it down.
Andrew
^ permalink raw reply
* Re: DSA support for Marvell 88e6065 switch
From: Andrew Lunn @ 2018-11-18 18:20 UTC (permalink / raw)
To: Pavel Machek; +Cc: netdev, f.fainelli, buytenh, buytenh, nico
In-Reply-To: <20181118180712.GA16507@amd>
On Sun, Nov 18, 2018 at 07:07:12PM +0100, Pavel Machek wrote:
> On Thu 2018-11-15 21:26:18, Andrew Lunn wrote:
> > On Thu, Nov 15, 2018 at 08:51:11PM +0100, Pavel Machek wrote:
> > > Hi!
> > >
> > > I'm trying to create support for Marvell 88e6065 switch... and it
> > > seems like drivers/net/dsa supports everything, but this model.
> > >
> > > Did someone work with this hardware before? Any idea if it would be
> > > more suitable to support by existing 88e6060 code, or if 88e6xxx code
> > > should serve as a base?
> >
> > Hi Pavel
> >
> > The 88e6xxx should be extended to support this. I think you will find
> > a lot of the building blocks are already in the driver. Compare the
> > various implementations of the functions in the mv88e6xxx_ops to what
> > the datasheet says for the registers, and pick those that match.
>
> Ok, so I played a bit.
>
> It looks like e6065 has different register layout from those supported
> by 6xxx, and is quite similar to e6060.
Hi Pavel
However, if you look in the mv88e6xxx, there are quite a few functions
called mv88e6065_foo. Marvell keeps changing the register layout. When
writing code, we try to name the functions based on which family of
devices introduced those registers. But we don't have the whole
history, so we probably have some names wrong.
> I understand how 88e6xxx code is supposed to work... but I don't
> understand how e6060 code is supposed to be probed. It does not seem
> to have device tree support. It seems to be older code, but is way
> simpler, and seems to be targetted at similar hardware.
The e6060 code is really old, pretty much abandoned. To make it
usable, you are going to have to make a lot of changes. Turn it into
an mdio driver, add device tree, make it use the new dsa2.c API, etc.
I still think you should be looking at the mv88e6xxx driver, but maybe
taking bits of code from the 6060 driver and adding it to the
mv88e6xxx driver as needed.
Andrew
^ permalink raw reply
* [PATCH net] ipv6: Fix PMTU updates for UDP/raw sockets in presence of VRF
From: David Ahern @ 2018-11-18 18:45 UTC (permalink / raw)
To: netdev; +Cc: preethir, David Ahern
From: David Ahern <dsahern@gmail.com>
Preethi reported that PMTU discovery for UDP/raw applications is not
working in the presence of VRF when the socket is not bound to a device.
The problem is that ip6_sk_update_pmtu does not consider the L3 domain
of the skb device if the socket is not bound. Update the function to
set oif to the L3 master device if relevant.
Fixes: ca254490c8df ("net: Add VRF support to IPv6 stack")
Reported-by: Preethi Ramachandra <preethir@juniper.net>
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/ipv6/route.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 14b422f35504..059f0531f7c1 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2359,10 +2359,13 @@ EXPORT_SYMBOL_GPL(ip6_update_pmtu);
void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, __be32 mtu)
{
+ int oif = sk->sk_bound_dev_if;
struct dst_entry *dst;
- ip6_update_pmtu(skb, sock_net(sk), mtu,
- sk->sk_bound_dev_if, sk->sk_mark, sk->sk_uid);
+ if (!oif && skb->dev)
+ oif = l3mdev_master_ifindex(skb->dev);
+
+ ip6_update_pmtu(skb, sock_net(sk), mtu, oif, sk->sk_mark, sk->sk_uid);
dst = __sk_dst_get(sk);
if (!dst || !dst->obsolete ||
--
2.11.0
^ permalink raw reply related
* BUG: unable to handle kernel paging request in bpf_prog_kallsyms_find
From: syzbot @ 2018-11-18 18:49 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 592ee43faf86 bpf: fix null pointer dereference on pointer ..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1211f2d5400000
kernel config: https://syzkaller.appspot.com/x/.config?x=7e5cbc38ae27657e
dashboard link: https://syzkaller.appspot.com/bug?extid=66d6b1d3055f1d9ee4f3
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10e4ec25400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+66d6b1d3055f1d9ee4f3@syzkaller.appspotmail.com
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b1126bc8 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b1126d40 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Oops: 0000 [#2] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b11264d8 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b1126650 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Oops: 0000 [#3] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b1125de8 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b1125f60 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Oops: 0000 [#4] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b11256f8 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b1125870 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Oops: 0000 [#5] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b1125008 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b1125180 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Oops: 0000 [#6] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b1124918 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b1124a90 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Oops: 0000 [#7] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b1124228 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b11243a0 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Oops: 0000 [#8] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b1123b38 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b1123cb0 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Oops: 0000 [#9] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b1123448 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b11235c0 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Oops: 0000 [#10] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b1122d58 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b1122ed0 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Oops: 0000 [#11] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b1122668 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b11227e0 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Oops: 0000 [#12] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b1121f78 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b11220f0 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Oops: 0000 [#13] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b1121888 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b1121a00 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Oops: 0000 [#14] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b1121198 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b1121310 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Thread overran stack, or stack corrupted
Oops: 0000 [#15] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b1120aa8 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b1120c20 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
------------[ cut here ]------------
kernel BUG at mm/slab.c:4425!
invalid opcode: 0000 [#16] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__check_heap_object+0xa7/0xb5 mm/slab.c:4450
Code: 48 c7 c7 d5 b7 14 89 e8 97 e3 0a 00 5d c3 41 8b 91 04 01 00 00 48 29
c7 48 39 d7 77 be 48 01 d0 48 29 c8 48 39 f0 72 b3 5d c3 <0f> 0b 48 c7 c7
d5 b7 14 89 e8 fd eb 0a 00 44 89 e9 48 c7 c7 90 b8
RSP: 0018:ffff8801b111fd38 EFLAGS: 00010046
RAX: 0000000000000001 RBX: 1ffff10036223fae RCX: 000000000000000c
RDX: ffff8801b111ed80 RSI: 0000000000000001 RDI: ffff8801b111ff18
RBP: ffff8801b111fd38 R08: ffff8801c2ac4040 R09: ffff8801da980e00
R10: 0000000000000f86 R11: 0000000000000000 R12: ffff8801b111ff18
R13: 0000000000000001 R14: ffffea0006c44780 R15: 0000000000000001
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
BUG: unable to handle kernel paging request at ffffc90001933030
PGD 1da95a067 P4D 1da95a067 PUD 1da95b067 PMD 1d4203067 PTE 0
Thread overran stack, or stack corrupted
Oops: 0000 [#17] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b111f880 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b111f9f8 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
------------[ cut here ]------------
kernel BUG at mm/slab.c:4425!
invalid opcode: 0000 [#18] PREEMPT SMP KASAN
CPU: 0 PID: 13017 Comm: blkid Not tainted 4.20.0-rc1+ #144
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__check_heap_object+0xa7/0xb5 mm/slab.c:4450
Code: 48 c7 c7 d5 b7 14 89 e8 97 e3 0a 00 5d c3 41 8b 91 04 01 00 00 48 29
c7 48 39 d7 77 be 48 01 d0 48 29 c8 48 39 f0 72 b3 5d c3 <0f> 0b 48 c7 c7
d5 b7 14 89 e8 fd eb 0a 00 44 89 e9 48 c7 c7 90 b8
RSP: 0018:ffff8801b111d300 EFLAGS: 00010046
RAX: 0000000000000001 RBX: 1ffff10036223a67 RCX: 000000000000000c
RDX: ffff8801b111c200 RSI: 0000000000000002 RDI: ffff8801b111d4a8
RBP: ffff8801b111d300 R08: ffff8801c2ac4040 R09: ffff8801da980e00
R10: 0000000000001076 R11: 0000000000000000 R12: ffff8801b111d4a8
R13: 0000000000000002 R14: ffffea0006c44700 R15: 0000000000000001
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modules linked in:
---[ end trace 53dd6c86d14a98c0 ]---
RIP: 0010:bpf_prog_ebpf_jited include/linux/filter.h:885 [inline]
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:384 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:438 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find+0x289/0x4a0 kernel/bpf/core.c:512
Code: 03 42 80 3c 30 00 0f 85 b1 01 00 00 4d 8b 6f 50 49 8d 7d 30 48 89 fa
48 c1 ea 03 42 80 3c 32 00 0f 85 ab 01 00 00 49 8d 7d 02 <4d> 8b 65 30 48
89 fa 48 89 f9 48 c1 ea 03 83 e1 07 42 0f b6 14 32
RSP: 0018:ffff8801b1126bc8 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8801d54e0a30 RCX: ffffffff818c0a21
RDX: 1ffff92000326606 RSI: 0000000000000008 RDI: ffffc90001933002
RBP: ffff8801b1126d40 R08: ffff8801c2ac4040 R09: 0000000000000000
R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
R13: ffffc90001933000 R14: dffffc0000000000 R15: ffff8801d54e0a30
FS: 00007fe237cd5740(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc90001933030 CR3: 00000001b96da000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [iproute2-next PATCH v3 1/2] tc: flower: Classify packets based port ranges
From: Jiri Pirko @ 2018-11-18 19:30 UTC (permalink / raw)
To: Amritha Nambiar
Cc: stephen, netdev, dsahern, jakub.kicinski, sridhar.samudrala, jhs,
xiyou.wangcong
In-Reply-To: <154232971379.10668.16416943966699679792.stgit@anamhost.jf.intel.com>
Fri, Nov 16, 2018 at 01:55:13AM CET, amritha.nambiar@intel.com wrote:
>Added support for filtering based on port ranges.
>UAPI changes have been accepted into net-next.
>
>Example:
>1. Match on a port range:
>-------------------------
>$ tc filter add dev enp4s0 protocol ip parent ffff:\
> prio 1 flower ip_proto tcp dst_port range 20-30 skip_hw\
> action drop
>
>$ tc -s filter show dev enp4s0 parent ffff:
>filter protocol ip pref 1 flower chain 0
>filter protocol ip pref 1 flower chain 0 handle 0x1
> eth_type ipv4
> ip_proto tcp
> dst_port range 20-30
> skip_hw
> not_in_hw
> action order 1: gact action drop
> random type none pass val 0
> index 1 ref 1 bind 1 installed 85 sec used 3 sec
> Action statistics:
> Sent 460 bytes 10 pkt (dropped 10, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
>
>2. Match on IP address and port range:
>--------------------------------------
>$ tc filter add dev enp4s0 protocol ip parent ffff:\
> prio 1 flower dst_ip 192.168.1.1 ip_proto tcp dst_port range 100-200\
> skip_hw action drop
>
>$ tc -s filter show dev enp4s0 parent ffff:
>filter protocol ip pref 1 flower chain 0 handle 0x2
> eth_type ipv4
> ip_proto tcp
> dst_ip 192.168.1.1
> dst_port range 100-200
> skip_hw
> not_in_hw
> action order 1: gact action drop
> random type none pass val 0
> index 2 ref 1 bind 1 installed 58 sec used 2 sec
> Action statistics:
> Sent 920 bytes 20 pkt (dropped 20, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
>
>v3:
>Modified flower_port_range_attr_type calls.
>
>v2:
>Addressed Jiri's comment to sync output format with input
>
>Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
Looks ok. But why do you have man changes in a separate patch ?
I think it should be in this one. Anyway
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* [PATCH 1/4] net-next/hinic:replace multiply and division operators
From: Xue Chaojing @ 2018-11-19 6:12 UTC (permalink / raw)
To: davem
Cc: linux-kernel, xuechaojing, netdev, wulike1, chiqijun, fy.wang,
tony.qu, luoshaokai
To improve performance, this patch uses bit operations to replace
multiply and division operators.
Signed-off-by: Xue Chaojing <xuechaojing@huawei.com>
---
.../net/ethernet/huawei/hinic/hinic_hw_wq.c | 43 +++++++++++++------
.../net/ethernet/huawei/hinic/hinic_hw_wq.h | 3 +-
2 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_wq.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_wq.c
index f92f1bf3901a..34859502c932 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_wq.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_wq.c
@@ -74,12 +74,6 @@
((void *)((cmdq_pages)->shadow_page_vaddr) \
+ (wq)->block_idx * CMDQ_BLOCK_SIZE)
-#define WQE_PAGE_OFF(wq, idx) (((idx) & ((wq)->num_wqebbs_per_page - 1)) * \
- (wq)->wqebb_size)
-
-#define WQE_PAGE_NUM(wq, idx) (((idx) / ((wq)->num_wqebbs_per_page)) \
- & ((wq)->num_q_pages - 1))
-
#define WQ_PAGE_ADDR(wq, idx) \
((wq)->shadow_block_vaddr[WQE_PAGE_NUM(wq, idx)])
@@ -93,6 +87,17 @@
(((unsigned long)(wqe) - (unsigned long)(wq)->shadow_wqe) \
/ (wq)->max_wqe_size)
+static inline int WQE_PAGE_OFF(struct hinic_wq *wq, u16 idx)
+{
+ return (((idx) & ((wq)->num_wqebbs_per_page - 1))
+ << (wq)->wqebb_size_shift);
+}
+
+static inline int WQE_PAGE_NUM(struct hinic_wq *wq, u16 idx)
+{
+ return (((idx) >> ((wq)->wqebbs_per_page_shift))
+ & ((wq)->num_q_pages - 1));
+}
/**
* queue_alloc_page - allocate page for Queue
* @hwif: HW interface for allocating DMA
@@ -513,6 +518,7 @@ int hinic_wq_allocate(struct hinic_wqs *wqs, struct hinic_wq *wq,
struct hinic_hwif *hwif = wqs->hwif;
struct pci_dev *pdev = hwif->pdev;
u16 num_wqebbs_per_page;
+ u16 wqebb_size_shift;
int err;
if (wqebb_size == 0) {
@@ -530,7 +536,9 @@ int hinic_wq_allocate(struct hinic_wqs *wqs, struct hinic_wq *wq,
return -EINVAL;
}
- num_wqebbs_per_page = ALIGN(wq_page_size, wqebb_size) / wqebb_size;
+ wqebb_size_shift = ilog2(wqebb_size);
+ num_wqebbs_per_page = ALIGN(wq_page_size, wqebb_size)
+ >> wqebb_size_shift;
if (num_wqebbs_per_page & (num_wqebbs_per_page - 1)) {
dev_err(&pdev->dev, "num wqebbs per page must be power of 2\n");
@@ -550,7 +558,8 @@ int hinic_wq_allocate(struct hinic_wqs *wqs, struct hinic_wq *wq,
wq->q_depth = q_depth;
wq->max_wqe_size = max_wqe_size;
wq->num_wqebbs_per_page = num_wqebbs_per_page;
-
+ wq->wqebbs_per_page_shift = ilog2(num_wqebbs_per_page);
+ wq->wqebb_size_shift = wqebb_size_shift;
wq->block_vaddr = WQ_BASE_VADDR(wqs, wq);
wq->shadow_block_vaddr = WQ_BASE_ADDR(wqs, wq);
wq->block_paddr = WQ_BASE_PADDR(wqs, wq);
@@ -604,7 +613,9 @@ int hinic_wqs_cmdq_alloc(struct hinic_cmdq_pages *cmdq_pages,
u16 q_depth, u16 max_wqe_size)
{
struct pci_dev *pdev = hwif->pdev;
+ u16 num_wqebbs_per_page_shift;
u16 num_wqebbs_per_page;
+ u16 wqebb_size_shift;
int i, j, err = -ENOMEM;
if (wqebb_size == 0) {
@@ -622,7 +633,9 @@ int hinic_wqs_cmdq_alloc(struct hinic_cmdq_pages *cmdq_pages,
return -EINVAL;
}
- num_wqebbs_per_page = ALIGN(wq_page_size, wqebb_size) / wqebb_size;
+ wqebb_size_shift = ilog2(wqebb_size);
+ num_wqebbs_per_page = ALIGN(wq_page_size, wqebb_size)
+ >> wqebb_size_shift;
if (num_wqebbs_per_page & (num_wqebbs_per_page - 1)) {
dev_err(&pdev->dev, "num wqebbs per page must be power of 2\n");
@@ -636,6 +649,7 @@ int hinic_wqs_cmdq_alloc(struct hinic_cmdq_pages *cmdq_pages,
dev_err(&pdev->dev, "Failed to allocate CMDQ page\n");
return err;
}
+ num_wqebbs_per_page_shift = ilog2(num_wqebbs_per_page);
for (i = 0; i < cmdq_blocks; i++) {
wq[i].hwif = hwif;
@@ -647,7 +661,8 @@ int hinic_wqs_cmdq_alloc(struct hinic_cmdq_pages *cmdq_pages,
wq[i].q_depth = q_depth;
wq[i].max_wqe_size = max_wqe_size;
wq[i].num_wqebbs_per_page = num_wqebbs_per_page;
-
+ wq[i].wqebbs_per_page_shift = num_wqebbs_per_page_shift;
+ wq[i].wqebb_size_shift = wqebb_size_shift;
wq[i].block_vaddr = CMDQ_BASE_VADDR(cmdq_pages, &wq[i]);
wq[i].shadow_block_vaddr = CMDQ_BASE_ADDR(cmdq_pages, &wq[i]);
wq[i].block_paddr = CMDQ_BASE_PADDR(cmdq_pages, &wq[i]);
@@ -741,7 +756,7 @@ struct hinic_hw_wqe *hinic_get_wqe(struct hinic_wq *wq, unsigned int wqe_size,
*prod_idx = MASKED_WQE_IDX(wq, atomic_read(&wq->prod_idx));
- num_wqebbs = ALIGN(wqe_size, wq->wqebb_size) / wq->wqebb_size;
+ num_wqebbs = ALIGN(wqe_size, wq->wqebb_size) >> wq->wqebb_size_shift;
if (atomic_sub_return(num_wqebbs, &wq->delta) <= 0) {
atomic_add(num_wqebbs, &wq->delta);
@@ -795,7 +810,8 @@ void hinic_return_wqe(struct hinic_wq *wq, unsigned int wqe_size)
**/
void hinic_put_wqe(struct hinic_wq *wq, unsigned int wqe_size)
{
- int num_wqebbs = ALIGN(wqe_size, wq->wqebb_size) / wq->wqebb_size;
+ int num_wqebbs = ALIGN(wqe_size, wq->wqebb_size)
+ >> wq->wqebb_size_shift;
atomic_add(num_wqebbs, &wq->cons_idx);
@@ -813,7 +829,8 @@ void hinic_put_wqe(struct hinic_wq *wq, unsigned int wqe_size)
struct hinic_hw_wqe *hinic_read_wqe(struct hinic_wq *wq, unsigned int wqe_size,
u16 *cons_idx)
{
- int num_wqebbs = ALIGN(wqe_size, wq->wqebb_size) / wq->wqebb_size;
+ int num_wqebbs = ALIGN(wqe_size, wq->wqebb_size)
+ >> wq->wqebb_size_shift;
u16 curr_cons_idx, end_cons_idx;
int curr_pg, end_pg;
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_wq.h b/drivers/net/ethernet/huawei/hinic/hinic_hw_wq.h
index 9b66545ba563..0a936cd6709b 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_wq.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_wq.h
@@ -39,7 +39,8 @@ struct hinic_wq {
u16 q_depth;
u16 max_wqe_size;
u16 num_wqebbs_per_page;
-
+ u16 wqebbs_per_page_shift;
+ u16 wqebb_size_shift;
/* The addresses are 64 bit in the HW */
u64 block_paddr;
void **shadow_block_vaddr;
--
2.17.1
^ permalink raw reply related
* [PATCH 2/4] net-next/hinic:add rx checksum offload for HiNIC
From: Xue Chaojing @ 2018-11-19 6:12 UTC (permalink / raw)
To: davem
Cc: linux-kernel, xuechaojing, netdev, wulike1, chiqijun, fy.wang,
tony.qu, luoshaokai
In-Reply-To: <20181119061234.12839-1-xuechaojing@huawei.com>
In order to improve performance, this patch adds rx checksum offload
for the HiNIC driver. Performance test(Iperf) shows more than 80%
improvement in TCP streams.
Signed-off-by: Xue Chaojing <xuechaojing@huawei.com>
---
.../net/ethernet/huawei/hinic/hinic_hw_dev.h | 2 ++
.../net/ethernet/huawei/hinic/hinic_hw_wqe.h | 4 +++
.../net/ethernet/huawei/hinic/hinic_main.c | 8 +++++-
.../net/ethernet/huawei/hinic/hinic_port.c | 28 +++++++++++++++++++
.../net/ethernet/huawei/hinic/hinic_port.h | 10 +++++++
drivers/net/ethernet/huawei/hinic/hinic_rx.c | 24 ++++++++++++++++
drivers/net/ethernet/huawei/hinic/hinic_rx.h | 4 +++
7 files changed, 79 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
index 097b5502603f..d1a7d2522d82 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
@@ -50,6 +50,8 @@ enum hinic_port_cmd {
HINIC_PORT_CMD_GET_LINK_STATE = 24,
+ HINIC_PORT_CMD_SET_RX_CSUM = 26,
+
HINIC_PORT_CMD_SET_PORT_STATE = 41,
HINIC_PORT_CMD_FWCTXT_INIT = 69,
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_wqe.h b/drivers/net/ethernet/huawei/hinic/hinic_hw_wqe.h
index 9754d6ed5f4a..138941527872 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_wqe.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_wqe.h
@@ -170,6 +170,10 @@
#define HINIC_RQ_CQE_STATUS_RXDONE_MASK 0x1
+#define HINIC_RQ_CQE_STATUS_CSUM_ERR_SHIFT 0
+
+#define HINIC_RQ_CQE_STATUS_CSUM_ERR_MASK 0xFFFFU
+
#define HINIC_RQ_CQE_STATUS_GET(val, member) \
(((val) >> HINIC_RQ_CQE_STATUS_##member##_SHIFT) & \
HINIC_RQ_CQE_STATUS_##member##_MASK)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_main.c b/drivers/net/ethernet/huawei/hinic/hinic_main.c
index fdf2bdb6b0d0..0179b6bf124c 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
@@ -726,6 +726,7 @@ static void set_rx_mode(struct work_struct *work)
{
struct hinic_rx_mode_work *rx_mode_work = work_to_rx_mode_work(work);
struct hinic_dev *nic_dev = rx_mode_work_to_nic_dev(rx_mode_work);
+ struct netdev_hw_addr *ha;
netif_info(nic_dev, drv, nic_dev->netdev, "set rx mode work\n");
@@ -806,7 +807,8 @@ static const struct net_device_ops hinic_netdev_ops = {
static void netdev_features_init(struct net_device *netdev)
{
netdev->hw_features = NETIF_F_SG | NETIF_F_HIGHDMA | NETIF_F_IP_CSUM |
- NETIF_F_IPV6_CSUM | NETIF_F_TSO | NETIF_F_TSO6;
+ NETIF_F_IPV6_CSUM | NETIF_F_TSO | NETIF_F_TSO6 |
+ NETIF_F_RXCSUM;
netdev->vlan_features = netdev->hw_features;
@@ -869,12 +871,16 @@ static int set_features(struct hinic_dev *nic_dev,
netdev_features_t features, bool force_change)
{
netdev_features_t changed = force_change ? ~0 : pre_features ^ features;
+ u32 csum_en = HINIC_RX_CSUM_OFFLOAD_EN;
int err = 0;
if (changed & NETIF_F_TSO)
err = hinic_port_set_tso(nic_dev, (features & NETIF_F_TSO) ?
HINIC_TSO_ENABLE : HINIC_TSO_DISABLE);
+ if (changed & NETIF_F_RXCSUM)
+ err = hinic_set_rx_csum_offload(nic_dev, csum_en);
+
return err;
}
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_port.c b/drivers/net/ethernet/huawei/hinic/hinic_port.c
index 7575a7d3bd9f..e9f76e904610 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_port.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_port.c
@@ -409,3 +409,31 @@ int hinic_port_set_tso(struct hinic_dev *nic_dev, enum hinic_tso_state state)
return 0;
}
+
+int hinic_set_rx_csum_offload(struct hinic_dev *nic_dev, u32 en)
+{
+ struct hinic_checksum_offload rx_csum_cfg = {0};
+ struct hinic_hwdev *hwdev = nic_dev->hwdev;
+ struct hinic_hwif *hwif = hwdev->hwif;
+ struct pci_dev *pdev = hwif->pdev;
+ u16 out_size;
+ int err;
+
+ if (!hwdev)
+ return -EINVAL;
+
+ rx_csum_cfg.func_id = HINIC_HWIF_FUNC_IDX(hwif);
+ rx_csum_cfg.rx_csum_offload = en;
+
+ err = hinic_port_msg_cmd(hwdev, HINIC_PORT_CMD_SET_RX_CSUM,
+ &rx_csum_cfg, sizeof(rx_csum_cfg),
+ &rx_csum_cfg, &out_size);
+ if (err || !out_size || rx_csum_cfg.status) {
+ dev_err(&pdev->dev,
+ "Failed to set rx csum offload, ret = %d\n",
+ rx_csum_cfg.status);
+ return -EINVAL;
+ }
+
+ return 0;
+}
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_port.h b/drivers/net/ethernet/huawei/hinic/hinic_port.h
index f6e3220fe28f..02d896eed455 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_port.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_port.h
@@ -183,6 +183,15 @@ struct hinic_tso_config {
u8 resv2[3];
};
+struct hinic_checksum_offload {
+ u8 status;
+ u8 version;
+ u8 rsvd0[6];
+
+ u16 func_id;
+ u16 rsvd1;
+ u32 rx_csum_offload;
+};
int hinic_port_add_mac(struct hinic_dev *nic_dev, const u8 *addr,
u16 vlan_id);
@@ -213,4 +222,5 @@ int hinic_port_get_cap(struct hinic_dev *nic_dev,
int hinic_port_set_tso(struct hinic_dev *nic_dev, enum hinic_tso_state state);
+int hinic_set_rx_csum_offload(struct hinic_dev *nic_dev, u32 en);
#endif
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_rx.c b/drivers/net/ethernet/huawei/hinic/hinic_rx.c
index 4c0f7eda1166..93e8f207f6da 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_rx.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_rx.c
@@ -89,6 +89,28 @@ static void rxq_stats_init(struct hinic_rxq *rxq)
hinic_rxq_clean_stats(rxq);
}
+static void rx_csum(struct hinic_rxq *rxq, u16 cons_idx,
+ struct sk_buff *skb)
+{
+ struct net_device *netdev = rxq->netdev;
+ struct hinic_rq_cqe *cqe;
+ struct hinic_rq *rq;
+ u32 csum_err;
+ u32 status;
+
+ rq = rxq->rq;
+ cqe = rq->cqe[cons_idx];
+ status = be32_to_cpu(cqe->status);
+ csum_err = HINIC_RQ_CQE_STATUS_GET(status, CSUM_ERR);
+
+ if (!(netdev->features & NETIF_F_RXCSUM))
+ return;
+
+ if (!csum_err)
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
+ else
+ skb->ip_summed = CHECKSUM_NONE;
+}
/**
* rx_alloc_skb - allocate skb and map it to dma address
* @rxq: rx queue
@@ -328,6 +350,8 @@ static int rxq_recv(struct hinic_rxq *rxq, int budget)
rx_unmap_skb(rxq, hinic_sge_to_dma(&sge));
+ rx_csum(rxq, ci, skb);
+
prefetch(skb->data);
pkt_len = sge.len;
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_rx.h b/drivers/net/ethernet/huawei/hinic/hinic_rx.h
index 27c9af4b1c12..ab3fabab91b2 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_rx.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_rx.h
@@ -23,6 +23,10 @@
#include "hinic_hw_qp.h"
+#define HINIC_RX_CSUM_OFFLOAD_EN 0xFFF
+#define HINIC_RX_CSUM_HW_CHECK_NONE BIT(7)
+#define HINIC_RX_CSUM_IPSU_OTHER_ERR BIT(8)
+
struct hinic_rxq_stats {
u64 pkts;
u64 bytes;
--
2.17.1
^ permalink raw reply related
* [PATCH 3/4] net-next/hinic:fix a bug in set mac address
From: Xue Chaojing @ 2018-11-19 6:12 UTC (permalink / raw)
To: davem
Cc: linux-kernel, xuechaojing, netdev, wulike1, chiqijun, fy.wang,
tony.qu, luoshaokai
In-Reply-To: <20181119061234.12839-1-xuechaojing@huawei.com>
In add_mac_addr(), if the MAC address is a muliticast address,
it will not be set, which causes the network card fail to receive
the multicast packet. This patch fixes this bug.
Signed-off-by: Xue Chaojing <xuechaojing@huawei.com>
---
drivers/net/ethernet/huawei/hinic/hinic_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_main.c b/drivers/net/ethernet/huawei/hinic/hinic_main.c
index 0179b6bf124c..6d48dc62a44b 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
@@ -600,9 +600,6 @@ static int add_mac_addr(struct net_device *netdev, const u8 *addr)
u16 vid = 0;
int err;
- if (!is_valid_ether_addr(addr))
- return -EADDRNOTAVAIL;
-
netif_info(nic_dev, drv, netdev, "set mac addr = %02x %02x %02x %02x %02x %02x\n",
addr[0], addr[1], addr[2], addr[3], addr[4], addr[5]);
@@ -734,6 +731,9 @@ static void set_rx_mode(struct work_struct *work)
__dev_uc_sync(nic_dev->netdev, add_mac_addr, remove_mac_addr);
__dev_mc_sync(nic_dev->netdev, add_mac_addr, remove_mac_addr);
+
+ netdev_for_each_mc_addr(ha, nic_dev->netdev)
+ add_mac_addr(nic_dev->netdev, ha->addr);
}
static void hinic_set_rx_mode(struct net_device *netdev)
--
2.17.1
^ permalink raw reply related
* [PATCH 4/4] net-next/hinic: fix a bug in rx data flow
From: Xue Chaojing @ 2018-11-19 6:12 UTC (permalink / raw)
To: davem
Cc: linux-kernel, xuechaojing, netdev, wulike1, chiqijun, fy.wang,
tony.qu, luoshaokai
In-Reply-To: <20181119061234.12839-1-xuechaojing@huawei.com>
In rx_alloc_pkts(), there is a loop call of tasklet, which causes
100% cpu utilization, even no packets are being received. This patch
fixes this bug.
Signed-off-by: Xue Chaojing <xuechaojing@huawei.com>
---
drivers/net/ethernet/huawei/hinic/hinic_rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_rx.c b/drivers/net/ethernet/huawei/hinic/hinic_rx.c
index 93e8f207f6da..f86f2e693224 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_rx.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_rx.c
@@ -229,9 +229,9 @@ static int rx_alloc_pkts(struct hinic_rxq *rxq)
wmb(); /* write all the wqes before update PI */
hinic_rq_update(rxq->rq, prod_idx);
+ tasklet_schedule(&rxq->rx_task);
}
- tasklet_schedule(&rxq->rx_task);
return i;
}
--
2.17.1
^ permalink raw reply related
* Re: DSA support for Marvell 88e6065 switch
From: Pavel Machek @ 2018-11-18 20:15 UTC (permalink / raw)
To: Andrew Lunn, pavel; +Cc: netdev, f.fainelli, buytenh, buytenh, nico
In-Reply-To: <20181118182053.GE7446@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]
HI!
> > > > I'm trying to create support for Marvell 88e6065 switch... and it
> > > > seems like drivers/net/dsa supports everything, but this model.
> > > >
> > > > Did someone work with this hardware before? Any idea if it would be
> > > > more suitable to support by existing 88e6060 code, or if 88e6xxx code
> > > > should serve as a base?
> > >
> > > Hi Pavel
> > >
> > > The 88e6xxx should be extended to support this. I think you will find
> > > a lot of the building blocks are already in the driver. Compare the
> > > various implementations of the functions in the mv88e6xxx_ops to what
> > > the datasheet says for the registers, and pick those that match.
> >
> > Ok, so I played a bit.
> >
> > It looks like e6065 has different register layout from those supported
> > by 6xxx, and is quite similar to e6060.
>
> Hi Pavel
>
> However, if you look in the mv88e6xxx, there are quite a few functions
> called mv88e6065_foo. Marvell keeps changing the register layout. When
> writing code, we try to name the functions based on which family of
> devices introduced those registers. But we don't have the whole
> history, so we probably have some names wrong.
Let me check... I thought there was only one such function. Ok, I see
two such functions:
mv88e6065_phylink_validate
mv88e6065_port_set_speed
I may need to re-check, but it looked to me like even functions and
registeres labeled 6xxx are different on 6060 and 6065... which means
changes to the code would not be exactly nice and easy.
> > I understand how 88e6xxx code is supposed to work... but I don't
> > understand how e6060 code is supposed to be probed. It does not seem
> > to have device tree support. It seems to be older code, but is way
> > simpler, and seems to be targetted at similar hardware.
>
> The e6060 code is really old, pretty much abandoned. To make it
> usable, you are going to have to make a lot of changes. Turn it into
> an mdio driver, add device tree, make it use the new dsa2.c API, etc.
If I wanted it to work, what do I need to do? AFAICT phy autoprobing
should just attach it as soon as it is compiled in?
I tried adding nodes in dts trying to make the driver attach, but no
luck so far.
> I still think you should be looking at the mv88e6xxx driver, but maybe
> taking bits of code from the 6060 driver and adding it to the
> mv88e6xxx driver as needed.
e6060 driver is much simpler, which is somehow nice. Let me look
around some more.
Thanks,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH net] sctp: always set frag_point on pmtu change
From: Jakub Audykowicz @ 2018-11-18 20:47 UTC (permalink / raw)
To: linux-sctp, vyasevich, nhorman, marcelo.leitner, davem
Cc: netdev, Jakub Audykowicz
Calling send on a connected SCTP socket results in kernel panic if
spp_pathmtu was configured manually before an association is established
and it was not reconfigured to another value once the association is
established.
Steps to reproduce:
1. Set up a listening SCTP server socket.
2. Set up an SCTP client socket.
3. Configure client socket using setsockopt SCTP_PEER_ADDR_PARAMS with
spp_pathmtu set to a legal value (e.g. 1000) and
SPP_PMTUD_DISABLE set in spp_flags.
4. Connect client to server.
5. Send message from client to server.
At this point oom-killer is invoked, which will eventually lead to:
[ 5.197262] Out of memory and no killable processes...
[ 5.198107] Kernel panic - not syncing: System is deadlocked on memory
Commit 2f5e3c9df693 ("sctp: introduce sctp_assoc_update_frag_point")
introduces sctp_assoc_update_frag_point, but this function is not called
in this case, causing frag_point to be zero:
void sctp_assoc_set_pmtu(struct sctp_association *asoc, __u32 pmtu)
{
- if (asoc->pathmtu != pmtu)
+ if (asoc->pathmtu != pmtu) {
asoc->pathmtu = pmtu;
+ sctp_assoc_update_frag_point(asoc);
+ }
In this scenario, on association establishment, asoc->pathmtu is already
1000 and pmtu will be as well. Before this commit the frag_point was being
correctly set in the scenario described. Moving the call outside the if
block fixes the issue.
I will be providing a separate patch to lksctp-tools with a simple test
reproducing this problem ("func_tests: frag_point should never be zero").
I have also taken the liberty to introduce a sanity check in chunk.c to
set the frag_point to a non-negative value in order to avoid chunking
endlessly (which is the reason for the eventual panic).
Fixes: 2f5e3c9df693 ("sctp: introduce sctp_assoc_update_frag_point")
Signed-off-by: Jakub Audykowicz <jakub.audykowicz@gmail.com>
---
include/net/sctp/constants.h | 3 +++
net/sctp/associola.c | 13 +++++++------
net/sctp/chunk.c | 6 ++++++
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h
index 8dadc74c22e7..90316fab6f04 100644
--- a/include/net/sctp/constants.h
+++ b/include/net/sctp/constants.h
@@ -293,6 +293,9 @@ enum { SCTP_MAX_GABS = 16 };
*/
#define SCTP_DEFAULT_MINSEGMENT 512 /* MTU size ... if no mtu disc */
+/* An association's fragmentation point should never be non-positive */
+#define SCTP_FRAG_POINT_MIN 1
+
#define SCTP_SECRET_SIZE 32 /* Number of octets in a 256 bits. */
#define SCTP_SIGNATURE_SIZE 20 /* size of a SLA-1 signature */
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 6a28b96e779e..44d71a1af62e 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -1431,13 +1431,14 @@ void sctp_assoc_update_frag_point(struct sctp_association *asoc)
void sctp_assoc_set_pmtu(struct sctp_association *asoc, __u32 pmtu)
{
- if (asoc->pathmtu != pmtu) {
- asoc->pathmtu = pmtu;
- sctp_assoc_update_frag_point(asoc);
- }
+ pr_debug("%s: before asoc:%p, pmtu:%d, frag_point:%d\n",
+ __func__, asoc, asoc->pathmtu, asoc->frag_point);
+
+ asoc->pathmtu = pmtu;
+ sctp_assoc_update_frag_point(asoc);
- pr_debug("%s: asoc:%p, pmtu:%d, frag_point:%d\n", __func__, asoc,
- asoc->pathmtu, asoc->frag_point);
+ pr_debug("%s: after asoc:%p, pmtu:%d, frag_point:%d\n",
+ __func__, asoc, asoc->pathmtu, asoc->frag_point);
}
/* Update the association's pmtu and frag_point by going through all the
diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
index ce8087846f05..9f0e64ddbd9c 100644
--- a/net/sctp/chunk.c
+++ b/net/sctp/chunk.c
@@ -190,6 +190,12 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct sctp_association *asoc,
/* This is the biggest possible DATA chunk that can fit into
* the packet
*/
+ if (asoc->frag_point < SCTP_FRAG_POINT_MIN) {
+ pr_warn("%s: asoc:%p->frag_point is less than allowed (%d<%d)",
+ __func__, asoc, asoc->frag_point, SCTP_FRAG_POINT_MIN);
+ pr_warn("forcing minimum value to avoid chunking endlessly");
+ asoc->frag_point = SCTP_FRAG_POINT_MIN;
+ }
max_data = asoc->frag_point;
/* If the the peer requested that we authenticate DATA chunks
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next] add part of TCP counts explanations in snmp_counters.rst
From: David Miller @ 2018-11-18 20:57 UTC (permalink / raw)
To: yupeng0921; +Cc: netdev, xiyou.wangcong, rdunlap
In-Reply-To: <20181116191740.12632-1-yupeng0921@gmail.com>
From: yupeng <yupeng0921@gmail.com>
Date: Fri, 16 Nov 2018 11:17:40 -0800
> Add explanations of some generic TCP counters, fast open
> related counters and TCP abort related counters and several
> examples.
>
> Signed-off-by: yupeng <yupeng0921@gmail.com>
Applied.
^ permalink raw reply
* [PATCH v2 6/7] net: phy: icplus: implement .did_interrupt for IP101A/G
From: Martin Blumenstingl @ 2018-11-18 21:23 UTC (permalink / raw)
To: netdev, devicetree, f.fainelli, andrew, mark.rutland, robh+dt,
davem
Cc: linux-kernel, Martin Blumenstingl
In-Reply-To: <20181118212359.32414-1-martin.blumenstingl@googlemail.com>
The IP101A_G_IRQ_CONF_STATUS register has bits to detect which
interrupts have fired. Implement the .did_interrupt callback to let the
PHY core know whether the interrupt was for this specific PHY.
This is useful for debugging interrupt problems with 32-pin IP101GR PHYs
where the interrupt line is shared with the RX_ERR (receive error
status) signal. The default values are:
- RX_ERR is enabled by default (LOW means that there is no receive
error)
- the PHY's interrupt line is configured "active low" by default
Without any additional changes there is a flood of interrupts if the
RX_ERR/INTR32 signal is configured in RX_ERR mode (which is the
default). Having a did_interrupt ensures that the PHY core returns
IRQ_NONE instead of endlessly triggering the PHY state machine.
Additionally the kernel will report this after a while:
irq 28: nobody cared (try booting with the "irqpoll" option)
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/icplus.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/net/phy/icplus.c b/drivers/net/phy/icplus.c
index c9489ec77cef..3dc8bbbe746b 100644
--- a/drivers/net/phy/icplus.c
+++ b/drivers/net/phy/icplus.c
@@ -44,6 +44,9 @@ MODULE_LICENSE("GPL");
#define IP101A_G_IRQ_CONF_STATUS 0x11 /* Conf Info IRQ & Status Reg */
#define IP101A_G_IRQ_PIN_USED BIT(15) /* INTR pin used */
#define IP101A_G_IRQ_ALL_MASK BIT(11) /* IRQ's inactive */
+#define IP101A_G_IRQ_SPEED_CHANGE BIT(2)
+#define IP101A_G_IRQ_DUPLEX_CHANGE BIT(1)
+#define IP101A_G_IRQ_LINK_CHANGE BIT(0)
static int ip175c_config_init(struct phy_device *phydev)
{
@@ -209,6 +212,18 @@ static int ip101a_g_config_intr(struct phy_device *phydev)
return phy_write(phydev, IP101A_G_IRQ_CONF_STATUS, val);
}
+static int ip101a_g_did_interrupt(struct phy_device *phydev)
+{
+ int val = phy_read(phydev, IP101A_G_IRQ_CONF_STATUS);
+
+ if (val < 0)
+ return 0;
+
+ return val & (IP101A_G_IRQ_SPEED_CHANGE |
+ IP101A_G_IRQ_DUPLEX_CHANGE |
+ IP101A_G_IRQ_LINK_CHANGE);
+}
+
static int ip101a_g_ack_interrupt(struct phy_device *phydev)
{
int err = phy_read(phydev, IP101A_G_IRQ_CONF_STATUS);
@@ -243,6 +258,7 @@ static struct phy_driver icplus_driver[] = {
.phy_id_mask = 0x0ffffff0,
.features = PHY_BASIC_FEATURES,
.config_intr = ip101a_g_config_intr,
+ .did_interrupt = ip101a_g_did_interrupt,
.ack_interrupt = ip101a_g_ack_interrupt,
.config_init = &ip101a_g_config_init,
.suspend = genphy_suspend,
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v2 4/5] phy: mvebu-cp110-comphy: convert to use eth phy mode and submode
From: Maxime Chevallier @ 2018-11-19 8:26 UTC (permalink / raw)
To: Grygorii Strashko
Cc: David S. Miller, Kishon Vijay Abraham I, Russell King - ARM Linux,
netdev, Sekhar Nori, linux-kernel, linux-arm-kernel,
Tony Lindgren, linux-amlogic, linux-mediatek, Alexandre Belloni,
Antoine Tenart, Quentin Schulz, Vivek Gautam, Maxime Ripard,
Chen-Yu Tsai, Carlo Caione, Chunfeng Yun, Matthias Brugger, Manu
In-Reply-To: <20181109234755.21687-5-grygorii.strashko@ti.com>
Hi Grygorii,
On Fri, 9 Nov 2018 17:47:54 -0600
Grygorii Strashko <grygorii.strashko@ti.com> wrote:
>Convert mvebu-cp110-comphy PHY driver to use recently introduced
>PHY_MODE_ETHERNET and phy_set_mode_ext().
Sorry I missed your V2, hopefully I tested the right version this time.
Tested on MCBin, this works just fine.
Thanks,
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
>Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>---
> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +-----
> drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 83 ++++++++++++++-----------
> 2 files changed, 48 insertions(+), 54 deletions(-)
>
>diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
>index 7a37a37..731793a 100644
>--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
>+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
>@@ -1165,28 +1165,13 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
> */
> static int mvpp22_comphy_init(struct mvpp2_port *port)
> {
>- enum phy_mode mode;
> int ret;
>
> if (!port->comphy)
> return 0;
>
>- switch (port->phy_interface) {
>- case PHY_INTERFACE_MODE_SGMII:
>- case PHY_INTERFACE_MODE_1000BASEX:
>- mode = PHY_MODE_SGMII;
>- break;
>- case PHY_INTERFACE_MODE_2500BASEX:
>- mode = PHY_MODE_2500SGMII;
>- break;
>- case PHY_INTERFACE_MODE_10GKR:
>- mode = PHY_MODE_10GKR;
>- break;
>- default:
>- return -EINVAL;
>- }
>-
>- ret = phy_set_mode(port->comphy, mode);
>+ ret = phy_set_mode_ext(port->comphy, PHY_MODE_ETHERNET,
>+ port->phy_interface);
> if (ret)
> return ret;
>
>diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
>index 79b52c3..7dee72b 100644
>--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
>+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
>@@ -9,6 +9,7 @@
> #include <linux/iopoll.h>
> #include <linux/mfd/syscon.h>
> #include <linux/module.h>
>+#include <linux/phy.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> #include <linux/regmap.h>
>@@ -131,26 +132,26 @@ struct mvebu_comhy_conf {
>
> static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
> /* lane 0 */
>- MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
>- MVEBU_COMPHY_CONF(0, 1, PHY_MODE_2500SGMII, 0x1),
>+ MVEBU_COMPHY_CONF(0, 1, PHY_INTERFACE_MODE_SGMII, 0x1),
>+ MVEBU_COMPHY_CONF(0, 1, PHY_INTERFACE_MODE_2500BASEX, 0x1),
> /* lane 1 */
>- MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
>- MVEBU_COMPHY_CONF(1, 2, PHY_MODE_2500SGMII, 0x1),
>+ MVEBU_COMPHY_CONF(1, 2, PHY_INTERFACE_MODE_SGMII, 0x1),
>+ MVEBU_COMPHY_CONF(1, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1),
> /* lane 2 */
>- MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
>- MVEBU_COMPHY_CONF(2, 0, PHY_MODE_2500SGMII, 0x1),
>- MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
>+ MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_SGMII, 0x1),
>+ MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_2500BASEX, 0x1),
>+ MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_10GKR, 0x1),
> /* lane 3 */
>- MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
>- MVEBU_COMPHY_CONF(3, 1, PHY_MODE_2500SGMII, 0x2),
>+ MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_SGMII, 0x2),
>+ MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_2500BASEX, 0x2),
> /* lane 4 */
>- MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
>- MVEBU_COMPHY_CONF(4, 0, PHY_MODE_2500SGMII, 0x2),
>- MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
>- MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
>+ MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_SGMII, 0x2),
>+ MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_2500BASEX, 0x2),
>+ MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_10GKR, 0x2),
>+ MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_SGMII, 0x1),
> /* lane 5 */
>- MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
>- MVEBU_COMPHY_CONF(5, 2, PHY_MODE_2500SGMII, 0x1),
>+ MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_SGMII, 0x1),
>+ MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1),
> };
>
> struct mvebu_comphy_priv {
>@@ -163,10 +164,12 @@ struct mvebu_comphy_lane {
> struct mvebu_comphy_priv *priv;
> unsigned id;
> enum phy_mode mode;
>+ int submode;
> int port;
> };
>
>-static int mvebu_comphy_get_mux(int lane, int port, enum phy_mode mode)
>+static int mvebu_comphy_get_mux(int lane, int port,
>+ enum phy_mode mode, int submode)
> {
> int i, n = ARRAY_SIZE(mvebu_comphy_cp110_modes);
>
>@@ -177,7 +180,7 @@ static int mvebu_comphy_get_mux(int lane, int port, enum phy_mode mode)
> for (i = 0; i < n; i++) {
> if (mvebu_comphy_cp110_modes[i].lane == lane &&
> mvebu_comphy_cp110_modes[i].port == port &&
>- mvebu_comphy_cp110_modes[i].mode == mode)
>+ mvebu_comphy_cp110_modes[i].mode == submode)
> break;
> }
>
>@@ -187,8 +190,7 @@ static int mvebu_comphy_get_mux(int lane, int port, enum phy_mode mode)
> return mvebu_comphy_cp110_modes[i].mux;
> }
>
>-static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane,
>- enum phy_mode mode)
>+static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane)
> {
> struct mvebu_comphy_priv *priv = lane->priv;
> u32 val;
>@@ -206,14 +208,14 @@ static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane,
> MVEBU_COMPHY_SERDES_CFG0_HALF_BUS |
> MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0xf) |
> MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0xf));
>- if (mode == PHY_MODE_10GKR)
>+ if (lane->submode == PHY_INTERFACE_MODE_10GKR)
> val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0xe) |
> MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0xe);
>- else if (mode == PHY_MODE_2500SGMII)
>+ else if (lane->submode == PHY_INTERFACE_MODE_2500BASEX)
> val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x8) |
> MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x8) |
> MVEBU_COMPHY_SERDES_CFG0_HALF_BUS;
>- else if (mode == PHY_MODE_SGMII)
>+ else if (lane->submode == PHY_INTERFACE_MODE_SGMII)
> val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x6) |
> MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x6) |
> MVEBU_COMPHY_SERDES_CFG0_HALF_BUS;
>@@ -243,7 +245,7 @@ static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane,
> /* refclk selection */
> val = readl(priv->base + MVEBU_COMPHY_MISC_CTRL0(lane->id));
> val &= ~MVEBU_COMPHY_MISC_CTRL0_REFCLK_SEL;
>- if (mode == PHY_MODE_10GKR)
>+ if (lane->submode == PHY_INTERFACE_MODE_10GKR)
> val |= MVEBU_COMPHY_MISC_CTRL0_ICP_FORCE;
> writel(val, priv->base + MVEBU_COMPHY_MISC_CTRL0(lane->id));
>
>@@ -261,8 +263,7 @@ static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane,
> writel(val, priv->base + MVEBU_COMPHY_LOOPBACK(lane->id));
> }
>
>-static int mvebu_comphy_init_plls(struct mvebu_comphy_lane *lane,
>- enum phy_mode mode)
>+static int mvebu_comphy_init_plls(struct mvebu_comphy_lane *lane)
> {
> struct mvebu_comphy_priv *priv = lane->priv;
> u32 val;
>@@ -303,13 +304,13 @@ static int mvebu_comphy_init_plls(struct mvebu_comphy_lane *lane,
> return 0;
> }
>
>-static int mvebu_comphy_set_mode_sgmii(struct phy *phy, enum phy_mode mode)
>+static int mvebu_comphy_set_mode_sgmii(struct phy *phy)
> {
> struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
> struct mvebu_comphy_priv *priv = lane->priv;
> u32 val;
>
>- mvebu_comphy_ethernet_init_reset(lane, mode);
>+ mvebu_comphy_ethernet_init_reset(lane);
>
> val = readl(priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
> val &= ~MVEBU_COMPHY_RX_CTRL1_CLK8T_EN;
>@@ -330,7 +331,7 @@ static int mvebu_comphy_set_mode_sgmii(struct phy *phy, enum phy_mode mode)
> val |= MVEBU_COMPHY_GEN1_S0_TX_EMPH(0x1);
> writel(val, priv->base + MVEBU_COMPHY_GEN1_S0(lane->id));
>
>- return mvebu_comphy_init_plls(lane, PHY_MODE_SGMII);
>+ return mvebu_comphy_init_plls(lane);
> }
>
> static int mvebu_comphy_set_mode_10gkr(struct phy *phy)
>@@ -339,7 +340,7 @@ static int mvebu_comphy_set_mode_10gkr(struct phy *phy)
> struct mvebu_comphy_priv *priv = lane->priv;
> u32 val;
>
>- mvebu_comphy_ethernet_init_reset(lane, PHY_MODE_10GKR);
>+ mvebu_comphy_ethernet_init_reset(lane);
>
> val = readl(priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
> val |= MVEBU_COMPHY_RX_CTRL1_RXCLK2X_SEL |
>@@ -469,7 +470,7 @@ static int mvebu_comphy_set_mode_10gkr(struct phy *phy)
> val |= MVEBU_COMPHY_EXT_SELV_RX_SAMPL(0x1a);
> writel(val, priv->base + MVEBU_COMPHY_EXT_SELV(lane->id));
>
>- return mvebu_comphy_init_plls(lane, PHY_MODE_10GKR);
>+ return mvebu_comphy_init_plls(lane);
> }
>
> static int mvebu_comphy_power_on(struct phy *phy)
>@@ -479,7 +480,8 @@ static int mvebu_comphy_power_on(struct phy *phy)
> int ret, mux;
> u32 val;
>
>- mux = mvebu_comphy_get_mux(lane->id, lane->port, lane->mode);
>+ mux = mvebu_comphy_get_mux(lane->id, lane->port,
>+ lane->mode, lane->submode);
> if (mux < 0)
> return -ENOTSUPP;
>
>@@ -492,12 +494,12 @@ static int mvebu_comphy_power_on(struct phy *phy)
> val |= mux << MVEBU_COMPHY_SELECTOR_PHY(lane->id);
> regmap_write(priv->regmap, MVEBU_COMPHY_SELECTOR, val);
>
>- switch (lane->mode) {
>- case PHY_MODE_SGMII:
>- case PHY_MODE_2500SGMII:
>- ret = mvebu_comphy_set_mode_sgmii(phy, lane->mode);
>+ switch (lane->submode) {
>+ case PHY_INTERFACE_MODE_SGMII:
>+ case PHY_INTERFACE_MODE_2500BASEX:
>+ ret = mvebu_comphy_set_mode_sgmii(phy);
> break;
>- case PHY_MODE_10GKR:
>+ case PHY_INTERFACE_MODE_10GKR:
> ret = mvebu_comphy_set_mode_10gkr(phy);
> break;
> default:
>@@ -517,10 +519,17 @@ static int mvebu_comphy_set_mode(struct phy *phy,
> {
> struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
>
>- if (mvebu_comphy_get_mux(lane->id, lane->port, mode) < 0)
>+ if (mode != PHY_MODE_ETHERNET)
>+ return -EINVAL;
>+
>+ if (submode == PHY_INTERFACE_MODE_1000BASEX)
>+ submode = PHY_INTERFACE_MODE_SGMII;
>+
>+ if (mvebu_comphy_get_mux(lane->id, lane->port, mode, submode) < 0)
> return -EINVAL;
>
> lane->mode = mode;
>+ lane->submode = submode;
> return 0;
> }
>
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: KASAN: use-after-free Read in sctp_hash_transport
From: Xin Long @ 2018-11-19 8:30 UTC (permalink / raw)
To: syzbot+0b05d8aa7cb185107483
Cc: davem, LKML, linux-sctp, Marcelo Ricardo Leitner, network dev,
Neil Horman, syzkaller-bugs, Vlad Yasevich
In-Reply-To: <00000000000044e23f057af554d7@google.com>
On Mon, Nov 19, 2018 at 4:23 AM syzbot
<syzbot+0b05d8aa7cb185107483@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: e119a369b0f1 Merge branch 'SMSC95xx-driver-updates'
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=124f5f7b400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=d86f24333880b605
> dashboard link: https://syzkaller.appspot.com/bug?extid=0b05d8aa7cb185107483
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+0b05d8aa7cb185107483@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: use-after-free in sctp_hash_transport+0x803/0x810
> net/sctp/input.c:958
> Read of size 8 at addr ffff8881c6b98cb0 by task syz-executor5/3552
>
> CPU: 0 PID: 3552 Comm: syz-executor5 Not tainted 4.20.0-rc2+ #299
> 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+0x244/0x39d lib/dump_stack.c:113
> print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> sctp_hash_transport+0x803/0x810 net/sctp/input.c:958
Caused by:
commit cd2b708750582e327789d8fb07c6eb5f79f7759f
Author: Xin Long <lucien.xin@gmail.com>
Date: Fri Feb 17 16:35:24 2017 +0800
sctp: check duplicate node before inserting a new transport
A same fix is needed as:
commit bab1be79a5169ac748d8292b20c86d874022d7ba
Author: Xin Long <lucien.xin@gmail.com>
Date: Mon Aug 27 18:38:31 2018 +0800
sctp: hold transport before accessing its asoc in sctp_transport_get_next
> sctp_assoc_add_peer+0xa21/0x10d0 net/sctp/associola.c:724
> sctp_sendmsg_new_asoc+0x5da/0x11f0 net/sctp/socket.c:1757
> sctp_sendmsg+0x18a5/0x1da0 net/sctp/socket.c:2086
> inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:631
> ___sys_sendmsg+0x7fd/0x930 net/socket.c:2116
> __sys_sendmsg+0x11d/0x280 net/socket.c:2154
> __do_sys_sendmsg net/socket.c:2163 [inline]
> __se_sys_sendmsg net/socket.c:2161 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x457569
> Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f45462c7c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457569
> RDX: 0000000000000000 RSI: 000000002001afc8 RDI: 0000000000000005
> RBP: 000000000072c0e0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f45462c86d4
> R13: 00000000004c381e R14: 00000000004d59e8 R15: 00000000ffffffff
>
> Allocated by task 3509:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
> kmem_cache_alloc_trace+0x152/0x750 mm/slab.c:3620
> kmalloc include/linux/slab.h:546 [inline]
> kzalloc include/linux/slab.h:741 [inline]
> sctp_association_new+0x14e/0x2290 net/sctp/associola.c:311
> sctp_sendmsg_new_asoc+0x39c/0x11f0 net/sctp/socket.c:1723
> sctp_sendmsg+0x18a5/0x1da0 net/sctp/socket.c:2086
> inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:631
> ___sys_sendmsg+0x7fd/0x930 net/socket.c:2116
> __sys_sendmsg+0x11d/0x280 net/socket.c:2154
> __do_sys_sendmsg net/socket.c:2163 [inline]
> __se_sys_sendmsg net/socket.c:2161 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 3552:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kfree+0xcf/0x230 mm/slab.c:3817
> sctp_association_destroy net/sctp/associola.c:437 [inline]
> sctp_association_put+0x264/0x350 net/sctp/associola.c:889
> sctp_transport_destroy net/sctp/transport.c:180 [inline]
> sctp_transport_put+0x186/0x1f0 net/sctp/transport.c:340
> sctp_hash_cmp+0x1ef/0x260 net/sctp/input.c:901
> __rhashtable_lookup.isra.24.constprop.29+0x3b6/0x7d0
> include/linux/rhashtable.h:483
> rhltable_lookup include/linux/rhashtable.h:566 [inline]
> sctp_hash_transport+0x2f6/0x810 net/sctp/input.c:954
> sctp_assoc_add_peer+0xa21/0x10d0 net/sctp/associola.c:724
> sctp_sendmsg_new_asoc+0x5da/0x11f0 net/sctp/socket.c:1757
> sctp_sendmsg+0x18a5/0x1da0 net/sctp/socket.c:2086
> inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:631
> ___sys_sendmsg+0x7fd/0x930 net/socket.c:2116
> __sys_sendmsg+0x11d/0x280 net/socket.c:2154
> __do_sys_sendmsg net/socket.c:2163 [inline]
> __se_sys_sendmsg net/socket.c:2161 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff8881c6b98c00
> which belongs to the cache kmalloc-4k of size 4096
> The buggy address is located 176 bytes inside of
> 4096-byte region [ffff8881c6b98c00, ffff8881c6b99c00)
> The buggy address belongs to the page:
> page:ffffea00071ae600 count:1 mapcount:0 mapping:ffff8881da800dc0 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc0000010200(slab|head)
> raw: 02fffc0000010200 ffffea0007175888 ffffea0006421308 ffff8881da800dc0
> raw: 0000000000000000 ffff8881c6b98c00 0000000100000001 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8881c6b98b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8881c6b98c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff8881c6b98c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff8881c6b98d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881c6b98d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
^ permalink raw reply
* Re: KASAN: use-after-free Read in sctp_epaddr_lookup_transport
From: Xin Long @ 2018-11-19 8:31 UTC (permalink / raw)
To: syzbot+aad231d51b1923158444
Cc: davem, LKML, linux-sctp, Marcelo Ricardo Leitner, network dev,
Neil Horman, syzkaller-bugs, Vlad Yasevich
In-Reply-To: <000000000000ce83ad057ad2a0f4@google.com>
On Sat, Nov 17, 2018 at 10:59 AM syzbot
<syzbot+aad231d51b1923158444@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: a97b95653383 drivers/net/ethernet/qlogic/qed/qed_rdma.h: f..
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1217d26d400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=d86f24333880b605
> dashboard link: https://syzkaller.appspot.com/bug?extid=aad231d51b1923158444
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13b5bb0b400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+aad231d51b1923158444@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: use-after-free in sctp_epaddr_lookup_transport+0xacb/0xb20
> net/sctp/input.c:971
> Read of size 8 at addr ffff8881cde426b0 by task syz-executor3/18110
>
The same fix is needed in sctp_epaddr_lookup_transport() as:
commit bab1be79a5169ac748d8292b20c86d874022d7ba
Author: Xin Long <lucien.xin@gmail.com>
Date: Mon Aug 27 18:38:31 2018 +0800
sctp: hold transport before accessing its asoc in sctp_transport_get_next
> CPU: 1 PID: 18110 Comm: syz-executor3 Not tainted 4.20.0-rc2+ #187
> 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+0x244/0x39d lib/dump_stack.c:113
> print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> sctp_epaddr_lookup_transport+0xacb/0xb20 net/sctp/input.c:971
> sctp_endpoint_lookup_assoc+0xe0/0x290 net/sctp/endpointola.c:338
> sctp_addr_id2transport+0x1f8/0x370 net/sctp/socket.c:279
> sctp_getsockopt_peer_addr_params+0x17c/0x1260 net/sctp/socket.c:5613
> sctp_getsockopt+0x44f9/0x7d32 net/sctp/socket.c:7462
> sock_common_getsockopt+0x9a/0xe0 net/core/sock.c:2937
> __sys_getsockopt+0x1ad/0x390 net/socket.c:1939
> __do_sys_getsockopt net/socket.c:1950 [inline]
> __se_sys_getsockopt net/socket.c:1947 [inline]
> __x64_sys_getsockopt+0xbe/0x150 net/socket.c:1947
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x457569
> Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f177b561c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
> RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000457569
> RDX: 0000000000000009 RSI: 0000000000000084 RDI: 0000000000000006
> RBP: 000000000072c180 R08: 000000002044fffc R09: 0000000000000000
> R10: 0000000020a68000 R11: 0000000000000246 R12: 00007f177b5626d4
> R13: 00000000004c8318 R14: 00000000004ce200 R15: 00000000ffffffff
>
> Allocated by task 18068:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
> kmem_cache_alloc_trace+0x152/0x750 mm/slab.c:3620
> kmalloc include/linux/slab.h:546 [inline]
> kzalloc include/linux/slab.h:741 [inline]
> sctp_association_new+0x14e/0x2290 net/sctp/associola.c:311
> sctp_sendmsg_new_asoc+0x39c/0x11f0 net/sctp/socket.c:1723
> sctp_sendmsg+0x18a5/0x1da0 net/sctp/socket.c:2086
> inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:631
> __sys_sendto+0x3d7/0x670 net/socket.c:1788
> __do_sys_sendto net/socket.c:1800 [inline]
> __se_sys_sendto net/socket.c:1796 [inline]
> __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1796
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 18110:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kfree+0xcf/0x230 mm/slab.c:3817
> sctp_association_destroy net/sctp/associola.c:437 [inline]
> sctp_association_put+0x264/0x350 net/sctp/associola.c:889
> sctp_transport_destroy net/sctp/transport.c:180 [inline]
> sctp_transport_put+0x186/0x1f0 net/sctp/transport.c:340
> sctp_hash_cmp+0x1ef/0x260 net/sctp/input.c:825
> __rhashtable_lookup include/linux/rhashtable.h:483 [inline]
> rhltable_lookup include/linux/rhashtable.h:566 [inline]
> sctp_epaddr_lookup_transport+0x4fe/0xb20 net/sctp/input.c:967
> sctp_endpoint_lookup_assoc+0xe0/0x290 net/sctp/endpointola.c:338
> sctp_addr_id2transport+0x1f8/0x370 net/sctp/socket.c:279
> sctp_getsockopt_peer_addr_params+0x17c/0x1260 net/sctp/socket.c:5613
> sctp_getsockopt+0x44f9/0x7d32 net/sctp/socket.c:7462
> sock_common_getsockopt+0x9a/0xe0 net/core/sock.c:2937
> __sys_getsockopt+0x1ad/0x390 net/socket.c:1939
> __do_sys_getsockopt net/socket.c:1950 [inline]
> __se_sys_getsockopt net/socket.c:1947 [inline]
> __x64_sys_getsockopt+0xbe/0x150 net/socket.c:1947
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff8881cde42600
> which belongs to the cache kmalloc-4k of size 4096
> The buggy address is located 176 bytes inside of
> 4096-byte region [ffff8881cde42600, ffff8881cde43600)
> The buggy address belongs to the page:
> page:ffffea0007379080 count:1 mapcount:0 mapping:ffff8881da800dc0 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc0000010200(slab|head)
> raw: 02fffc0000010200 ffffea0007379008 ffffea0007377f08 ffff8881da800dc0
> raw: 0000000000000000 ffff8881cde42600 0000000100000001 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8881cde42580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8881cde42600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff8881cde42680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff8881cde42700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881cde42780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
> kobject: 'loop5' (00000000f0e4ffac): fill_kobj_path: path
> = '/devices/virtual/block/loop5'
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: Linux kernel hangs if using RV1108 with MSZ8863 switch with two ports connected
From: Heiko Stübner @ 2018-11-18 22:27 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Otavio Salvador, netdev, david.choi, Andy Yan
In-Reply-To: <20181118181230.GD7446@lunn.ch>
Hi all,
Am Sonntag, 18. November 2018, 19:12:30 CET schrieb Andrew Lunn:
> > The kernel starts booting normally and then hangs like this when two
> > Ethernet cables are connected to the KSZ8863 switch:
> > http://dark-code.bulix.org/3xexu5-507563
>
> > This has the lock detection, inside kernel hacking, enabled.
>
> Maybe turn on all the hung-task debug and magic key support. With
> magic key, you might be able to get a backtrace of where it is
> spinning.
>
> Maybe also add #define DEBUG at the top of drivers/net/phy/phy.c.
> Does it hang during a PHY state transition?
>
> Maybe both PHYs are interrupting at the same time, and the interrupt
> code is broken?
>
> Maybe look at the switch driver and see if there is any code which is
> executed on link up. Put some printk() in there.
>
> If you PHYs are using interrupt mode, maybe disable that and use
> polling.
>
> Do you know if this ever worked properly before? If you know when it
> did work, you can do a git bisect to narrow it down to the one patch
> which broke it..
>
> Basically, at the moment, you just need to try lots of things, to
> narrow it down.
Your hang also seems to happen around the time the kernel disables
unused clocks and regulators.
So you might also try with these functions disabled, as it may be caused
by some clock or regulator handled wrongly there (I think it's called
clk_ignore_unused as kernel commandline but please double-check
and you'll need to check for a regulator equivalent yourself).
And as I think it might be some sort of driver-related issue, you could
also enable debugging in the driver-core [drivers/base/dd.c]
by either #define DEBUG or just redefining dev_dbg temporarily ;-)
#define dev_dbg dev_warn
or so.
That may help finding the culprit of your hang.
Heiko
^ permalink raw reply
* Re: KASAN: use-after-free Read in __lock_sock
From: Xin Long @ 2018-11-19 8:57 UTC (permalink / raw)
To: syzbot+9276d76e83e3bcde6c99
Cc: davem, LKML, linux-sctp, Marcelo Ricardo Leitner, network dev,
Neil Horman, syzkaller-bugs, Vlad Yasevich
In-Reply-To: <000000000000b98a67057ad7158a@google.com>
On Sat, Nov 17, 2018 at 4:18 PM syzbot
<syzbot+9276d76e83e3bcde6c99@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: ccda4af0f4b9 Linux 4.20-rc2
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=156cd533400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=4a0a89f12ca9b0f5
> dashboard link: https://syzkaller.appspot.com/bug?extid=9276d76e83e3bcde6c99
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+9276d76e83e3bcde6c99@syzkaller.appspotmail.com
>
> netlink: 5 bytes leftover after parsing attributes in process
> `syz-executor5'.
> ==================================================================
> BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20
> kernel/locking/lockdep.c:3218
> Read of size 8 at addr ffff8881d26d60e0 by task syz-executor1/13725
>
> CPU: 0 PID: 13725 Comm: syz-executor1 Not tainted 4.20.0-rc2+ #333
> 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+0x244/0x39d lib/dump_stack.c:113
> print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218
> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
> __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
> _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
> spin_lock_bh include/linux/spinlock.h:334 [inline]
> __lock_sock+0x203/0x350 net/core/sock.c:2253
> lock_sock_nested+0xfe/0x120 net/core/sock.c:2774
> lock_sock include/net/sock.h:1492 [inline]
> sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324
static int sctp_sock_dump(struct sctp_transport *tsp, void *p)
{
struct sctp_endpoint *ep = tsp->asoc->ep;
struct sctp_comm_param *commp = p;
struct sock *sk = ep->base.sk; <--- [1]
...
int err = 0;
lock_sock(sk); <--- [2]
Between [1] and [2], an asoc peeloff may happen, still thinking
how to avoid this.
> sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091
> sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527
> __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049
> inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065
> netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244
> __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352
> netlink_dump_start include/linux/netlink.h:216 [inline]
> inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170
> __sock_diag_cmd net/core/sock_diag.c:232 [inline]
> sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263
> netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477
> sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274
> netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
> netlink_unicast+0x5a5/0x760 net/netlink/af_netlink.c:1336
> netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1917
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:631
> sock_write_iter+0x35e/0x5c0 net/socket.c:900
> call_write_iter include/linux/fs.h:1857 [inline]
> do_iter_readv_writev+0x8b0/0xa80 fs/read_write.c:680
> do_iter_write+0x185/0x5f0 fs/read_write.c:959
> vfs_writev+0x1f1/0x360 fs/read_write.c:1004
> do_writev+0x11a/0x310 fs/read_write.c:1039
> __do_sys_writev fs/read_write.c:1112 [inline]
> __se_sys_writev fs/read_write.c:1109 [inline]
> __x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x457569
> Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f2cdabbac78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457569
> RDX: 0000000000000001 RSI: 000000002051c000 RDI: 000000000000000e
> RBP: 000000000072c0e0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f2cdabbb6d4
> R13: 00000000004c33b1 R14: 00000000004d97c8 R15: 00000000ffffffff
>
> Allocated by task 13672:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
> kmem_cache_alloc+0x12e/0x730 mm/slab.c:3554
> sk_prot_alloc+0x69/0x2e0 net/core/sock.c:1463
> sk_alloc+0x10d/0x1690 net/core/sock.c:1523
> inet_create+0x509/0x1070 net/ipv4/af_inet.c:321
> __sock_create+0x536/0x930 net/socket.c:1277
> sock_create net/socket.c:1317 [inline]
> __sys_socket+0x106/0x260 net/socket.c:1347
> __do_sys_socket net/socket.c:1356 [inline]
> __se_sys_socket net/socket.c:1354 [inline]
> __x64_sys_socket+0x73/0xb0 net/socket.c:1354
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 13680:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kmem_cache_free+0x83/0x290 mm/slab.c:3760
> sk_prot_free net/core/sock.c:1504 [inline]
> __sk_destruct+0x728/0xa80 net/core/sock.c:1588
> sk_destruct+0x78/0x90 net/core/sock.c:1596
> __sk_free+0xcf/0x300 net/core/sock.c:1607
> sk_free+0x42/0x50 net/core/sock.c:1618
> sock_put include/net/sock.h:1693 [inline]
> sctp_close+0x8d4/0xad0 net/sctp/socket.c:1569
> inet_release+0x104/0x1f0 net/ipv4/af_inet.c:428
> __sock_release+0xd7/0x250 net/socket.c:579
> sock_close+0x19/0x20 net/socket.c:1141
> __fput+0x385/0xa30 fs/file_table.c:278
> ____fput+0x15/0x20 fs/file_table.c:309
> task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
> get_signal+0x1558/0x1980 kernel/signal.c:2347
> do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816
> exit_to_usermode_loop+0x2e5/0x380 arch/x86/entry/common.c:162
> prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
> do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff8881d26d6040
> which belongs to the cache SCTP(33:syz1) of size 1776
> The buggy address is located 160 bytes inside of
> 1776-byte region [ffff8881d26d6040, ffff8881d26d6730)
> The buggy address belongs to the page:
> page:ffffea000749b580 count:1 mapcount:0 mapping:ffff8881b517f200 index:0x0
> flags: 0x2fffc0000000200(slab)
> raw: 02fffc0000000200 ffff8881c6685748 ffffea0007538388 ffff8881b517f200
> raw: 0000000000000000 ffff8881d26d6040 0000000100000002 ffff8881b6b4e7c0
> page dumped because: kasan: bad access detected
> page->mem_cgroup:ffff8881b6b4e7c0
>
> Memory state around the buggy address:
> ffff8881d26d5f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8881d26d6000: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> > ffff8881d26d6080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff8881d26d6100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881d26d6180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
^ permalink raw reply
* Re: [PATCH v2 00/25] at24: remove
From: Bartosz Golaszewski @ 2018-11-19 8:58 UTC (permalink / raw)
To: Boris Brezillon
Cc: Sekhar Nori, Kevin Hilman, Russell King, Arnd Bergmann,
Greg Kroah-Hartman, David Woodhouse, Brian Norris, Marek Vasut,
Richard Weinberger, Nicolas Ferre, David S . Miller,
Grygorii Strashko, Srinivas Kandagatla, Andrew Lunn,
Florian Fainelli, Rob Herring, Frank Rowand, Wolfram Sang,
devicetree, netdev
In-Reply-To: <20181118170329.788778a8@bbrezillon>
niedz., 18 lis 2018 o 17:03 Boris Brezillon
<boris.brezillon@bootlin.com> napisał(a):
>
> On Tue, 13 Nov 2018 15:01:08 +0100
> Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> > As far as merging of this series goes: I'd like to avoid dragging it over
> > four releases. The series is logically split into five groups:
> >
> > patches 1-2: nvmem and mtd changes
> > patches 3-9: davinci arch-specific changes
> > patches 10-13: networking changes
> > patches 14-24: davinci specific again
> > patch 25: final at24 change
> >
> > With that I believe we can do the following: Greg KH could pick up the
> > first two patches into his char-misc tree.
>
> The char-misc tree? Why not the MTD or NVMEM tree?
>
There is no NVMEM tree - Srinivas sends his patches to Greg to be
applied to char-misc.
The second patch depends on the first one so in order to avoid more
merging problems I suggested that the MTD patch go through char-misc
as well. If you see a better solution, please let me know.
Bart
^ permalink raw reply
* Re: [RFCv3 PATCH 1/6] uacce: Add documents for WarpDrive/uacce
From: Kenneth Lee @ 2018-11-19 9:14 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Kenneth Lee, Tim Sell, linux-doc, Alexander Shishkin, Zaibo Xu,
zhangfei.gao, linuxarm, haojian.zhuang, Christoph Lameter,
Hao Fang, Gavin Schenk, RDMA mailing list, Zhou Wang,
Jason Gunthorpe, Doug Ledford, Uwe Kleine-König,
David Kershner, Johan Hovold, Cyrille Pitchen
In-Reply-To: <20181115145455.GN3759@mtr-leonro.mtl.com>
On Thu, Nov 15, 2018 at 04:54:55PM +0200, Leon Romanovsky wrote:
> Date: Thu, 15 Nov 2018 16:54:55 +0200
> From: Leon Romanovsky <leon@kernel.org>
> To: Kenneth Lee <liguozhu@hisilicon.com>
> CC: Kenneth Lee <nek.in.cn@gmail.com>, Tim Sell <timothy.sell@unisys.com>,
> linux-doc@vger.kernel.org, Alexander Shishkin
> <alexander.shishkin@linux.intel.com>, Zaibo Xu <xuzaibo@huawei.com>,
> zhangfei.gao@foxmail.com, linuxarm@huawei.com, haojian.zhuang@linaro.org,
> Christoph Lameter <cl@linux.com>, Hao Fang <fanghao11@huawei.com>, Gavin
> Schenk <g.schenk@eckelmann.de>, RDMA mailing list
> <linux-rdma@vger.kernel.org>, Zhou Wang <wangzhou1@hisilicon.com>, Jason
> Gunthorpe <jgg@ziepe.ca>, Doug Ledford <dledford@redhat.com>, Uwe
> Kleine-König <u.kleine-koenig@pengutronix.de>, David Kershner
> <david.kershner@unisys.com>, Johan Hovold <johan@kernel.org>, Cyrille
> Pitchen <cyrille.pitchen@free-electrons.com>, Sagar Dharia
> <sdharia@codeaurora.org>, Jens Axboe <axboe@kernel.dk>,
> guodong.xu@linaro.org, linux-netdev <netdev@vger.kernel.org>, Randy Dunlap
> <rdunlap@infradead.org>, linux-kernel@vger.kernel.org, Vinod Koul
> <vkoul@kernel.org>, linux-crypto@vger.kernel.org, Philippe Ombredanne
> <pombredanne@nexb.com>, Sanyog Kale <sanyog.r.kale@intel.com>, "David S.
> Miller" <davem@davemloft.net>, linux-accelerators@lists.ozlabs.org
> Subject: Re: [RFCv3 PATCH 1/6] uacce: Add documents for WarpDrive/uacce
> User-Agent: Mutt/1.10.1 (2018-07-13)
> Message-ID: <20181115145455.GN3759@mtr-leonro.mtl.com>
>
> On Thu, Nov 15, 2018 at 04:51:09PM +0800, Kenneth Lee wrote:
> > On Wed, Nov 14, 2018 at 06:00:17PM +0200, Leon Romanovsky wrote:
> > > Date: Wed, 14 Nov 2018 18:00:17 +0200
> > > From: Leon Romanovsky <leon@kernel.org>
> > > To: Kenneth Lee <nek.in.cn@gmail.com>
> > > CC: Tim Sell <timothy.sell@unisys.com>, linux-doc@vger.kernel.org,
> > > Alexander Shishkin <alexander.shishkin@linux.intel.com>, Zaibo Xu
> > > <xuzaibo@huawei.com>, zhangfei.gao@foxmail.com, linuxarm@huawei.com,
> > > haojian.zhuang@linaro.org, Christoph Lameter <cl@linux.com>, Hao Fang
> > > <fanghao11@huawei.com>, Gavin Schenk <g.schenk@eckelmann.de>, RDMA mailing
> > > list <linux-rdma@vger.kernel.org>, Zhou Wang <wangzhou1@hisilicon.com>,
> > > Jason Gunthorpe <jgg@ziepe.ca>, Doug Ledford <dledford@redhat.com>, Uwe
> > > Kleine-König <u.kleine-koenig@pengutronix.de>, David Kershner
> > > <david.kershner@unisys.com>, Johan Hovold <johan@kernel.org>, Cyrille
> > > Pitchen <cyrille.pitchen@free-electrons.com>, Sagar Dharia
> > > <sdharia@codeaurora.org>, Jens Axboe <axboe@kernel.dk>,
> > > guodong.xu@linaro.org, linux-netdev <netdev@vger.kernel.org>, Randy Dunlap
> > > <rdunlap@infradead.org>, linux-kernel@vger.kernel.org, Vinod Koul
> > > <vkoul@kernel.org>, linux-crypto@vger.kernel.org, Philippe Ombredanne
> > > <pombredanne@nexb.com>, Sanyog Kale <sanyog.r.kale@intel.com>, Kenneth Lee
> > > <liguozhu@hisilicon.com>, "David S. Miller" <davem@davemloft.net>,
> > > linux-accelerators@lists.ozlabs.org
> > > Subject: Re: [RFCv3 PATCH 1/6] uacce: Add documents for WarpDrive/uacce
> > > User-Agent: Mutt/1.10.1 (2018-07-13)
> > > Message-ID: <20181114160017.GI3759@mtr-leonro.mtl.com>
> > >
> > > On Wed, Nov 14, 2018 at 10:58:09AM +0800, Kenneth Lee wrote:
> > > >
> > > > 在 2018/11/13 上午8:23, Leon Romanovsky 写道:
> > > > > On Mon, Nov 12, 2018 at 03:58:02PM +0800, Kenneth Lee wrote:
> > > > > > From: Kenneth Lee <liguozhu@hisilicon.com>
> > > > > >
> > > > > > WarpDrive is a general accelerator framework for the user application to
> > > > > > access the hardware without going through the kernel in data path.
> > > > > >
> > > > > > The kernel component to provide kernel facility to driver for expose the
> > > > > > user interface is called uacce. It a short name for
> > > > > > "Unified/User-space-access-intended Accelerator Framework".
> > > > > >
> > > > > > This patch add document to explain how it works.
> > > > > + RDMA and netdev folks
> > > > >
> > > > > Sorry, to be late in the game, I don't see other patches, but from
> > > > > the description below it seems like you are reinventing RDMA verbs
> > > > > model. I have hard time to see the differences in the proposed
> > > > > framework to already implemented in drivers/infiniband/* for the kernel
> > > > > space and for the https://github.com/linux-rdma/rdma-core/ for the user
> > > > > space parts.
> > > >
> > > > Thanks Leon,
> > > >
> > > > Yes, we tried to solve similar problem in RDMA. We also learned a lot from
> > > > the exist code of RDMA. But we we have to make a new one because we cannot
> > > > register accelerators such as AI operation, encryption or compression to the
> > > > RDMA framework:)
> > >
> > > Assuming that you did everything right and still failed to use RDMA
> > > framework, you was supposed to fix it and not to reinvent new exactly
> > > same one. It is how we develop kernel, by reusing existing code.
> >
> > Yes, but we don't force other system such as NIC or GPU into RDMA, do we?
>
> You don't introduce new NIC or GPU, but proposing another interface to
> directly access HW memory and bypass kernel for the data path. This is
> whole idea of RDMA and this is why it is already present in the kernel.
>
> Various hardware devices are supported in our stack allow a ton of crazy
> stuff, including GPUs interconnections and NIC functionalities.
Yes. We don't want to invent new wheel. That is why we did it behind VFIO in RFC
v1 and v2. But finally we were persuaded by Mr. Jerome Glisse that VFIO was not
a good place to solve the problem.
And currently, as you see, IB is bound with devices doing RDMA. The register
function, ib_register_device() hint that it is a netdev (get_netdev() callback), it know
about gid, pkey, and Memory Window. IB is not simply a address space management
framework. And verbs to IB are not transparent. If we start to add
compression/decompression, AI (RNN, CNN stuff) operations, and encryption/decryption
to the verbs set. It will become very complexity. Or maybe I misunderstand the
IB idea? But I don't see compression hardware is integrated in the mainline
Kernel. Could you directly point out which one I can used as a reference?
>
> >
> > I assume you would not agree to register a zip accelerator to infiniband? :)
>
> "infiniband" name in the "drivers/infiniband/" is legacy one and the
> current code supports IB, RoCE, iWARP and OmniPath as a transport layers.
> For a lone time, we wanted to rename that folder to be "drivers/rdma",
> but didn't find enough brave men/women to do it, due to backport mess
> for such move.
>
> The addition of zip accelerator to RDMA is possible and depends on how
> you will model such new functionality - new driver, or maybe new ULP.
>
> >
> > Further, I don't think it is wise to break an exist system (RDMA) to fulfill a
> > totally new scenario. The better choice is to let them run in parallel for some
> > time and try to merge them accordingly.
>
> Awesome, so please run your code out-of-tree for now and once you are ready
> for submission let's try to merge it.
Yes, yes. We know trust need time to gain. But the fact is that there is no
accelerator user driver can be added to mainline kernel. We should raise the
topic time to time. So to help the communication to fix the gap, right?
We are also opened to cooperate with IB to do it within the IB framework. But
please let me know where to start. I feel it is quite wired to make a
ib_register_device for a zip or RSA accelerator.
>
> >
> > >
> > > >
> > > > Another problem we tried to address is the way to pin the memory for dma
> > > > operation. The RDMA way to pin the memory cannot avoid the page lost due to
> > > > copy-on-write operation during the memory is used by the device. This may
> > > > not be important to RDMA library. But it is important to accelerator.
> > >
> > > Such support exists in drivers/infiniband/ from late 2014 and
> > > it is called ODP (on demand paging).
> >
> > I reviewed ODP and I think it is a solution bound to infiniband. It is part of
> > MR semantics and required a infiniband specific hook
> > (ucontext->invalidate_range()). And the hook requires the device to be able to
> > stop using the page for a while for the copying. It is ok for infiniband
> > (actually, only mlx5 uses it). I don't think most accelerators can support
> > this mode. But WarpDrive works fully on top of IOMMU interface, it has no this
> > limitation.
>
> 1. It has nothing to do with infiniband.
But it must be a ib_dev first.
> 2. MR and uncontext are verbs semantics and needed to ensure that host
> memory exposed to user is properly protected from security point of view.
> 3. "stop using the page for a while for the copying" - I'm not fully
> understand this claim, maybe this article will help you to better
> describe : https://lwn.net/Articles/753027/
This topic was being discussed in RFCv2. The key problem here is that:
The device need to hold the memory for its own calculation, but the CPU/software
want to stop it for a while for synchronizing with disk or COW.
If the hardware support SVM/SVA (Shared Virtual Memory/Address), it is easy, the
device share page table with CPU, the device will raise a page fault when the
CPU downgrade the PTE to read-only.
If the hardware cannot share page table with the CPU, we then need to have
some way to change the device page table. This is what happen in ODP. It
invalidates the page table in device upon mmu_notifier call back. But this cannot
solve the COW problem: if the user process A share a page P with device, and A
forks a new process B, and it continue to write to the page. By COW, the
process B will keep the page P, while A will get a new page P'. But you have
no way to let the device know it should use P' rather than P.
This may be OK for RDMA application. Because RDMA is a big thing and we can ask
the programmer to avoid the situation. But for a accelerator, I don't think we
can ask a programmer to care for this when use a zlib.
In WarpDrive/uacce, we make this simple. If you support IOMMU and it support
SVM/SVA. Everything will be fine just like ODP implicit mode. And you don't need
to write any code for that. Because it has been done by IOMMU framework. If it
dose not, you have to use the kernel allocated memory which has the same IOVA as
the VA in user space. So we can still maintain a unify address space among the
devices and the applicatin.
> 4. mlx5 supports ODP not because of being partially IB device,
> but because HW performance oriented implementation is not an easy task.
>
> >
> > >
> > > >
> > > > Hope this can help the understanding.
> > >
> > > Yes, it helped me a lot.
> > > Now, I'm more than before convinced that this whole patchset shouldn't
> > > exist in the first place.
> >
> > Then maybe you can tell me how I can register my accelerator to the user space?
>
> Write kernel driver and write user space part of it.
> https://github.com/linux-rdma/rdma-core/
>
> I have no doubts that your colleagues who wrote and maintain
> drivers/infiniband/hw/hns driver know best how to do it.
> They did it very successfully.
>
> Thanks
>
> >
> > >
> > > To be clear, NAK.
> > >
> > > Thanks
> > >
> > > >
> > > > Cheers
> > > >
> > > > >
> > > > > Hard NAK from RDMA side.
> > > > >
> > > > > Thanks
> > > > >
> > > > > > Signed-off-by: Kenneth Lee <liguozhu@hisilicon.com>
> > > > > > ---
> > > > > > Documentation/warpdrive/warpdrive.rst | 260 +++++++
> > > > > > Documentation/warpdrive/wd-arch.svg | 764 ++++++++++++++++++++
> > > > > > Documentation/warpdrive/wd.svg | 526 ++++++++++++++
> > > > > > Documentation/warpdrive/wd_q_addr_space.svg | 359 +++++++++
> > > > > > 4 files changed, 1909 insertions(+)
> > > > > > create mode 100644 Documentation/warpdrive/warpdrive.rst
> > > > > > create mode 100644 Documentation/warpdrive/wd-arch.svg
> > > > > > create mode 100644 Documentation/warpdrive/wd.svg
> > > > > > create mode 100644 Documentation/warpdrive/wd_q_addr_space.svg
> > > > > >
> > > > > > diff --git a/Documentation/warpdrive/warpdrive.rst b/Documentation/warpdrive/warpdrive.rst
> > > > > > new file mode 100644
> > > > > > index 000000000000..ef84d3a2d462
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/warpdrive/warpdrive.rst
> > > > > > @@ -0,0 +1,260 @@
> > > > > > +Introduction of WarpDrive
> > > > > > +=========================
> > > > > > +
> > > > > > +*WarpDrive* is a general accelerator framework for the user application to
> > > > > > +access the hardware without going through the kernel in data path.
> > > > > > +
> > > > > > +It can be used as the quick channel for accelerators, network adaptors or
> > > > > > +other hardware for application in user space.
> > > > > > +
> > > > > > +This may make some implementation simpler. E.g. you can reuse most of the
> > > > > > +*netdev* driver in kernel and just share some ring buffer to the user space
> > > > > > +driver for *DPDK* [4] or *ODP* [5]. Or you can combine the RSA accelerator with
> > > > > > +the *netdev* in the user space as a https reversed proxy, etc.
> > > > > > +
> > > > > > +*WarpDrive* takes the hardware accelerator as a heterogeneous processor which
> > > > > > +can share particular load from the CPU:
> > > > > > +
> > > > > > +.. image:: wd.svg
> > > > > > + :alt: WarpDrive Concept
> > > > > > +
> > > > > > +The virtual concept, queue, is used to manage the requests sent to the
> > > > > > +accelerator. The application send requests to the queue by writing to some
> > > > > > +particular address, while the hardware takes the requests directly from the
> > > > > > +address and send feedback accordingly.
> > > > > > +
> > > > > > +The format of the queue may differ from hardware to hardware. But the
> > > > > > +application need not to make any system call for the communication.
> > > > > > +
> > > > > > +*WarpDrive* tries to create a shared virtual address space for all involved
> > > > > > +accelerators. Within this space, the requests sent to queue can refer to any
> > > > > > +virtual address, which will be valid to the application and all involved
> > > > > > +accelerators.
> > > > > > +
> > > > > > +The name *WarpDrive* is simply a cool and general name meaning the framework
> > > > > > +makes the application faster. It includes general user library, kernel
> > > > > > +management module and drivers for the hardware. In kernel, the management
> > > > > > +module is called *uacce*, meaning "Unified/User-space-access-intended
> > > > > > +Accelerator Framework".
> > > > > > +
> > > > > > +
> > > > > > +How does it work
> > > > > > +================
> > > > > > +
> > > > > > +*WarpDrive* uses *mmap* and *IOMMU* to play the trick.
> > > > > > +
> > > > > > +*Uacce* creates a chrdev for the device registered to it. A "queue" will be
> > > > > > +created when the chrdev is opened. The application access the queue by mmap
> > > > > > +different address region of the queue file.
> > > > > > +
> > > > > > +The following figure demonstrated the queue file address space:
> > > > > > +
> > > > > > +.. image:: wd_q_addr_space.svg
> > > > > > + :alt: WarpDrive Queue Address Space
> > > > > > +
> > > > > > +The first region of the space, device region, is used for the application to
> > > > > > +write request or read answer to or from the hardware.
> > > > > > +
> > > > > > +Normally, there can be three types of device regions mmio and memory regions.
> > > > > > +It is recommended to use common memory for request/answer descriptors and use
> > > > > > +the mmio space for device notification, such as doorbell. But of course, this
> > > > > > +is all up to the interface designer.
> > > > > > +
> > > > > > +There can be two types of device memory regions, kernel-only and user-shared.
> > > > > > +This will be explained in the "kernel APIs" section.
> > > > > > +
> > > > > > +The Static Share Virtual Memory region is necessary only when the device IOMMU
> > > > > > +does not support "Share Virtual Memory". This will be explained after the
> > > > > > +*IOMMU* idea.
> > > > > > +
> > > > > > +
> > > > > > +Architecture
> > > > > > +------------
> > > > > > +
> > > > > > +The full *WarpDrive* architecture is represented in the following class
> > > > > > +diagram:
> > > > > > +
> > > > > > +.. image:: wd-arch.svg
> > > > > > + :alt: WarpDrive Architecture
> > > > > > +
> > > > > > +
> > > > > > +The user API
> > > > > > +------------
> > > > > > +
> > > > > > +We adopt a polling style interface in the user space: ::
> > > > > > +
> > > > > > + int wd_request_queue(struct wd_queue *q);
> > > > > > + void wd_release_queue(struct wd_queue *q);
> > > > > > +
> > > > > > + int wd_send(struct wd_queue *q, void *req);
> > > > > > + int wd_recv(struct wd_queue *q, void **req);
> > > > > > + int wd_recv_sync(struct wd_queue *q, void **req);
> > > > > > + void wd_flush(struct wd_queue *q);
> > > > > > +
> > > > > > +wd_recv_sync() is a wrapper to its non-sync version. It will trapped into
> > > > > > +kernel and waits until the queue become available.
> > > > > > +
> > > > > > +If the queue do not support SVA/SVM. The following helper function
> > > > > > +can be used to create Static Virtual Share Memory: ::
> > > > > > +
> > > > > > + void *wd_preserve_share_memory(struct wd_queue *q, size_t size);
> > > > > > +
> > > > > > +The user API is not mandatory. It is simply a suggestion and hint what the
> > > > > > +kernel interface is supposed to support.
> > > > > > +
> > > > > > +
> > > > > > +The user driver
> > > > > > +---------------
> > > > > > +
> > > > > > +The queue file mmap space will need a user driver to wrap the communication
> > > > > > +protocol. *UACCE* provides some attributes in sysfs for the user driver to
> > > > > > +match the right accelerator accordingly.
> > > > > > +
> > > > > > +The *UACCE* device attribute is under the following directory:
> > > > > > +
> > > > > > +/sys/class/uacce/<dev-name>/params
> > > > > > +
> > > > > > +The following attributes is supported:
> > > > > > +
> > > > > > +nr_queue_remained (ro)
> > > > > > + number of queue remained
> > > > > > +
> > > > > > +api_version (ro)
> > > > > > + a string to identify the queue mmap space format and its version
> > > > > > +
> > > > > > +device_attr (ro)
> > > > > > + attributes of the device, see UACCE_DEV_xxx flag defined in uacce.h
> > > > > > +
> > > > > > +numa_node (ro)
> > > > > > + id of numa node
> > > > > > +
> > > > > > +priority (rw)
> > > > > > + Priority or the device, bigger is higher
> > > > > > +
> > > > > > +(This is not yet implemented in RFC version)
> > > > > > +
> > > > > > +
> > > > > > +The kernel API
> > > > > > +--------------
> > > > > > +
> > > > > > +The *uacce* kernel API is defined in uacce.h. If the hardware support SVM/SVA,
> > > > > > +The driver need only the following API functions: ::
> > > > > > +
> > > > > > + int uacce_register(uacce);
> > > > > > + void uacce_unregister(uacce);
> > > > > > + void uacce_wake_up(q);
> > > > > > +
> > > > > > +*uacce_wake_up* is used to notify the process who epoll() on the queue file.
> > > > > > +
> > > > > > +According to the IOMMU capability, *uacce* categories the devices as follow:
> > > > > > +
> > > > > > +UACCE_DEV_NOIOMMU
> > > > > > + The device has no IOMMU. The user process cannot use VA on the hardware
> > > > > > + This mode is not recommended.
> > > > > > +
> > > > > > +UACCE_DEV_SVA (UACCE_DEV_PASID | UACCE_DEV_FAULT_FROM_DEV)
> > > > > > + The device has IOMMU which can share the same page table with user
> > > > > > + process
> > > > > > +
> > > > > > +UACCE_DEV_SHARE_DOMAIN
> > > > > > + The device has IOMMU which has no multiple page table and device page
> > > > > > + fault support
> > > > > > +
> > > > > > +If the device works in mode other than UACCE_DEV_NOIOMMU, *uacce* will set its
> > > > > > +IOMMU to IOMMU_DOMAIN_UNMANAGED. So the driver must not use any kernel
> > > > > > +DMA API but the following ones from *uacce* instead: ::
> > > > > > +
> > > > > > + uacce_dma_map(q, va, size, prot);
> > > > > > + uacce_dma_unmap(q, va, size, prot);
> > > > > > +
> > > > > > +*uacce_dma_map/unmap* is valid only for UACCE_DEV_SVA device. It creates a
> > > > > > +particular PASID and page table for the kernel in the IOMMU (Not yet
> > > > > > +implemented in the RFC)
> > > > > > +
> > > > > > +For the UACCE_DEV_SHARE_DOMAIN device, uacce_dma_map/unmap is not valid.
> > > > > > +*Uacce* call back start_queue only when the DUS and DKO region is mmapped. The
> > > > > > +accelerator driver must use those dma buffer, via uacce_queue->qfrs[], on
> > > > > > +start_queue call back. The size of the queue file region is defined by
> > > > > > +uacce->ops->qf_pg_start[].
> > > > > > +
> > > > > > +We have to do it this way because most of current IOMMU cannot support the
> > > > > > +kernel and user virtual address at the same time. So we have to let them both
> > > > > > +share the same user virtual address space.
> > > > > > +
> > > > > > +If the device have to support kernel and user at the same time, both kernel
> > > > > > +and the user should use these DMA API. This is not convenient. A better
> > > > > > +solution is to change the future DMA/IOMMU design to let them separate the
> > > > > > +address space between the user and kernel space. But it is not going to be in
> > > > > > +a short time.
> > > > > > +
> > > > > > +
> > > > > > +Multiple processes support
> > > > > > +==========================
> > > > > > +
> > > > > > +In the latest mainline kernel (4.19) when this document is written, the IOMMU
> > > > > > +subsystem do not support multiple process page tables yet.
> > > > > > +
> > > > > > +Most IOMMU hardware implementation support multi-process with the concept
> > > > > > +of PASID. But they may use different name, e.g. it is call sub-stream-id in
> > > > > > +SMMU of ARM. With PASID or similar design, multi page table can be added to
> > > > > > +the IOMMU and referred by its PASID.
> > > > > > +
> > > > > > +*JPB* has a patchset to enable this[1]_. We have tested it with our hardware
> > > > > > +(which is known as *D06*). It works well. *WarpDrive* rely on them to support
> > > > > > +UACCE_DEV_SVA. If it is not enabled, *WarpDrive* can still work. But it
> > > > > > +support only one process, the device will be set to UACCE_DEV_SHARE_DOMAIN
> > > > > > +even it is set to UACCE_DEV_SVA initially.
> > > > > > +
> > > > > > +Static Share Virtual Memory is mainly used by UACCE_DEV_SHARE_DOMAIN device.
> > > > > > +
> > > > > > +
> > > > > > +Legacy Mode Support
> > > > > > +===================
> > > > > > +For the hardware without IOMMU, WarpDrive can still work, the only problem is
> > > > > > +VA cannot be used in the device. The driver should adopt another strategy for
> > > > > > +the shared memory. It is only for testing, and not recommended.
> > > > > > +
> > > > > > +
> > > > > > +The Folk Scenario
> > > > > > +=================
> > > > > > +For a process with allocated queues and shared memory, what happen if it forks
> > > > > > +a child?
> > > > > > +
> > > > > > +The fd of the queue will be duplicated on folk, so the child can send request
> > > > > > +to the same queue as its parent. But the requests which is sent from processes
> > > > > > +except for the one who open the queue will be blocked.
> > > > > > +
> > > > > > +It is recommended to add O_CLOEXEC to the queue file.
> > > > > > +
> > > > > > +The queue mmap space has a VM_DONTCOPY in its VMA. So the child will lost all
> > > > > > +those VMAs.
> > > > > > +
> > > > > > +This is why *WarpDrive* does not adopt the mode used in *VFIO* and *InfiniBand*.
> > > > > > +Both solutions can set any user pointer for hardware sharing. But they cannot
> > > > > > +support fork when the dma is in process. Or the "Copy-On-Write" procedure will
> > > > > > +make the parent process lost its physical pages.
> > > > > > +
> > > > > > +
> > > > > > +The Sample Code
> > > > > > +===============
> > > > > > +There is a sample user land implementation with a simple driver for Hisilicon
> > > > > > +Hi1620 ZIP Accelerator.
> > > > > > +
> > > > > > +To test, do the following in samples/warpdrive (for the case of PC host): ::
> > > > > > + ./autogen.sh
> > > > > > + ./conf.sh # or simply ./configure if you build on target system
> > > > > > + make
> > > > > > +
> > > > > > +Then you can get test_hisi_zip in the test subdirectory. Copy it to the target
> > > > > > +system and make sure the hisi_zip driver is enabled (the major and minor of
> > > > > > +the uacce chrdev can be gotten from the dmesg or sysfs), and run: ::
> > > > > > + mknod /dev/ua1 c <major> <minior>
> > > > > > + test/test_hisi_zip -z < data > data.zip
> > > > > > + test/test_hisi_zip -g < data > data.gzip
> > > > > > +
> > > > > > +
> > > > > > +References
> > > > > > +==========
> > > > > > +.. [1] https://patchwork.kernel.org/patch/10394851/
> > > > > > +
> > > > > > +.. vim: tw=78
> > [...]
> > > > > > --
> > > > > > 2.17.1
> > > > > >
^ permalink raw reply
* Re: [RFCv3 PATCH 1/6] uacce: Add documents for WarpDrive/uacce
From: Kenneth Lee @ 2018-11-19 9:19 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Tim Sell, linux-doc, Alexander Shishkin, Zaibo Xu, zhangfei.gao,
linuxarm, haojian.zhuang, Christoph Lameter, Hao Fang,
Gavin Schenk, RDMA mailing list, Vinod Koul, Jason Gunthorpe,
Doug Ledford, Uwe Kleine-König, David Kershner, Kenneth Lee,
Johan Hovold, Cyrille Pitchen, Sagar Dharia
In-Reply-To: <20181119091405.GE157308@Turing-Arch-b>
On Mon, Nov 19, 2018 at 05:14:05PM +0800, Kenneth Lee wrote:
> Date: Mon, 19 Nov 2018 17:14:05 +0800
> From: Kenneth Lee <liguozhu@hisilicon.com>
> To: Leon Romanovsky <leon@kernel.org>
> CC: Tim Sell <timothy.sell@unisys.com>, linux-doc@vger.kernel.org,
> Alexander Shishkin <alexander.shishkin@linux.intel.com>, Zaibo Xu
> <xuzaibo@huawei.com>, zhangfei.gao@foxmail.com, linuxarm@huawei.com,
> haojian.zhuang@linaro.org, Christoph Lameter <cl@linux.com>, Hao Fang
> <fanghao11@huawei.com>, Gavin Schenk <g.schenk@eckelmann.de>, RDMA mailing
> list <linux-rdma@vger.kernel.org>, Vinod Koul <vkoul@kernel.org>, Jason
> Gunthorpe <jgg@ziepe.ca>, Doug Ledford <dledford@redhat.com>, Uwe
> Kleine-König <u.kleine-koenig@pengutronix.de>, David Kershner
> <david.kershner@unisys.com>, Kenneth Lee <nek.in.cn@gmail.com>, Johan
> Hovold <johan@kernel.org>, Cyrille Pitchen
> <cyrille.pitchen@free-electrons.com>, Sagar Dharia
> <sdharia@codeaurora.org>, Jens Axboe <axboe@kernel.dk>,
> guodong.xu@linaro.org, linux-netdev <netdev@vger.kernel.org>, Randy Dunlap
> <rdunlap@infradead.org>, linux-kernel@vger.kernel.org, Zhou Wang
> <wangzhou1@hisilicon.com>, linux-crypto@vger.kernel.org, Philippe
> Ombredanne <pombredanne@nexb.com>, Sanyog Kale <sanyog.r.kale@intel.com>,
> "David S. Miller" <davem@davemloft.net>,
> linux-accelerators@lists.ozlabs.org
> Subject: Re: [RFCv3 PATCH 1/6] uacce: Add documents for WarpDrive/uacce
> User-Agent: Mutt/1.5.21 (2010-09-15)
> Message-ID: <20181119091405.GE157308@Turing-Arch-b>
>
> On Thu, Nov 15, 2018 at 04:54:55PM +0200, Leon Romanovsky wrote:
> > Date: Thu, 15 Nov 2018 16:54:55 +0200
> > From: Leon Romanovsky <leon@kernel.org>
> > To: Kenneth Lee <liguozhu@hisilicon.com>
> > CC: Kenneth Lee <nek.in.cn@gmail.com>, Tim Sell <timothy.sell@unisys.com>,
> > linux-doc@vger.kernel.org, Alexander Shishkin
> > <alexander.shishkin@linux.intel.com>, Zaibo Xu <xuzaibo@huawei.com>,
> > zhangfei.gao@foxmail.com, linuxarm@huawei.com, haojian.zhuang@linaro.org,
> > Christoph Lameter <cl@linux.com>, Hao Fang <fanghao11@huawei.com>, Gavin
> > Schenk <g.schenk@eckelmann.de>, RDMA mailing list
> > <linux-rdma@vger.kernel.org>, Zhou Wang <wangzhou1@hisilicon.com>, Jason
> > Gunthorpe <jgg@ziepe.ca>, Doug Ledford <dledford@redhat.com>, Uwe
> > Kleine-König <u.kleine-koenig@pengutronix.de>, David Kershner
> > <david.kershner@unisys.com>, Johan Hovold <johan@kernel.org>, Cyrille
> > Pitchen <cyrille.pitchen@free-electrons.com>, Sagar Dharia
> > <sdharia@codeaurora.org>, Jens Axboe <axboe@kernel.dk>,
> > guodong.xu@linaro.org, linux-netdev <netdev@vger.kernel.org>, Randy Dunlap
> > <rdunlap@infradead.org>, linux-kernel@vger.kernel.org, Vinod Koul
> > <vkoul@kernel.org>, linux-crypto@vger.kernel.org, Philippe Ombredanne
> > <pombredanne@nexb.com>, Sanyog Kale <sanyog.r.kale@intel.com>, "David S.
> > Miller" <davem@davemloft.net>, linux-accelerators@lists.ozlabs.org
> > Subject: Re: [RFCv3 PATCH 1/6] uacce: Add documents for WarpDrive/uacce
> > User-Agent: Mutt/1.10.1 (2018-07-13)
> > Message-ID: <20181115145455.GN3759@mtr-leonro.mtl.com>
> >
> > On Thu, Nov 15, 2018 at 04:51:09PM +0800, Kenneth Lee wrote:
> > > On Wed, Nov 14, 2018 at 06:00:17PM +0200, Leon Romanovsky wrote:
> > > > Date: Wed, 14 Nov 2018 18:00:17 +0200
> > > > From: Leon Romanovsky <leon@kernel.org>
> > > > To: Kenneth Lee <nek.in.cn@gmail.com>
> > > > CC: Tim Sell <timothy.sell@unisys.com>, linux-doc@vger.kernel.org,
> > > > Alexander Shishkin <alexander.shishkin@linux.intel.com>, Zaibo Xu
> > > > <xuzaibo@huawei.com>, zhangfei.gao@foxmail.com, linuxarm@huawei.com,
> > > > haojian.zhuang@linaro.org, Christoph Lameter <cl@linux.com>, Hao Fang
> > > > <fanghao11@huawei.com>, Gavin Schenk <g.schenk@eckelmann.de>, RDMA mailing
> > > > list <linux-rdma@vger.kernel.org>, Zhou Wang <wangzhou1@hisilicon.com>,
> > > > Jason Gunthorpe <jgg@ziepe.ca>, Doug Ledford <dledford@redhat.com>, Uwe
> > > > Kleine-König <u.kleine-koenig@pengutronix.de>, David Kershner
> > > > <david.kershner@unisys.com>, Johan Hovold <johan@kernel.org>, Cyrille
> > > > Pitchen <cyrille.pitchen@free-electrons.com>, Sagar Dharia
> > > > <sdharia@codeaurora.org>, Jens Axboe <axboe@kernel.dk>,
> > > > guodong.xu@linaro.org, linux-netdev <netdev@vger.kernel.org>, Randy Dunlap
> > > > <rdunlap@infradead.org>, linux-kernel@vger.kernel.org, Vinod Koul
> > > > <vkoul@kernel.org>, linux-crypto@vger.kernel.org, Philippe Ombredanne
> > > > <pombredanne@nexb.com>, Sanyog Kale <sanyog.r.kale@intel.com>, Kenneth Lee
> > > > <liguozhu@hisilicon.com>, "David S. Miller" <davem@davemloft.net>,
> > > > linux-accelerators@lists.ozlabs.org
> > > > Subject: Re: [RFCv3 PATCH 1/6] uacce: Add documents for WarpDrive/uacce
> > > > User-Agent: Mutt/1.10.1 (2018-07-13)
> > > > Message-ID: <20181114160017.GI3759@mtr-leonro.mtl.com>
> > > >
> > > > On Wed, Nov 14, 2018 at 10:58:09AM +0800, Kenneth Lee wrote:
> > > > >
> > > > > 在 2018/11/13 上午8:23, Leon Romanovsky 写道:
> > > > > > On Mon, Nov 12, 2018 at 03:58:02PM +0800, Kenneth Lee wrote:
> > > > > > > From: Kenneth Lee <liguozhu@hisilicon.com>
> > > > > > >
> > > > > > > WarpDrive is a general accelerator framework for the user application to
> > > > > > > access the hardware without going through the kernel in data path.
> > > > > > >
> > > > > > > The kernel component to provide kernel facility to driver for expose the
> > > > > > > user interface is called uacce. It a short name for
> > > > > > > "Unified/User-space-access-intended Accelerator Framework".
> > > > > > >
> > > > > > > This patch add document to explain how it works.
> > > > > > + RDMA and netdev folks
> > > > > >
> > > > > > Sorry, to be late in the game, I don't see other patches, but from
> > > > > > the description below it seems like you are reinventing RDMA verbs
> > > > > > model. I have hard time to see the differences in the proposed
> > > > > > framework to already implemented in drivers/infiniband/* for the kernel
> > > > > > space and for the https://github.com/linux-rdma/rdma-core/ for the user
> > > > > > space parts.
> > > > >
> > > > > Thanks Leon,
> > > > >
> > > > > Yes, we tried to solve similar problem in RDMA. We also learned a lot from
> > > > > the exist code of RDMA. But we we have to make a new one because we cannot
> > > > > register accelerators such as AI operation, encryption or compression to the
> > > > > RDMA framework:)
> > > >
> > > > Assuming that you did everything right and still failed to use RDMA
> > > > framework, you was supposed to fix it and not to reinvent new exactly
> > > > same one. It is how we develop kernel, by reusing existing code.
> > >
> > > Yes, but we don't force other system such as NIC or GPU into RDMA, do we?
> >
> > You don't introduce new NIC or GPU, but proposing another interface to
> > directly access HW memory and bypass kernel for the data path. This is
> > whole idea of RDMA and this is why it is already present in the kernel.
> >
> > Various hardware devices are supported in our stack allow a ton of crazy
> > stuff, including GPUs interconnections and NIC functionalities.
>
> Yes. We don't want to invent new wheel. That is why we did it behind VFIO in RFC
> v1 and v2. But finally we were persuaded by Mr. Jerome Glisse that VFIO was not
> a good place to solve the problem.
>
> And currently, as you see, IB is bound with devices doing RDMA. The register
> function, ib_register_device() hint that it is a netdev (get_netdev() callback), it know
> about gid, pkey, and Memory Window. IB is not simply a address space management
> framework. And verbs to IB are not transparent. If we start to add
> compression/decompression, AI (RNN, CNN stuff) operations, and encryption/decryption
> to the verbs set. It will become very complexity. Or maybe I misunderstand the
> IB idea? But I don't see compression hardware is integrated in the mainline
> Kernel. Could you directly point out which one I can used as a reference?
>
> >
> > >
> > > I assume you would not agree to register a zip accelerator to infiniband? :)
> >
> > "infiniband" name in the "drivers/infiniband/" is legacy one and the
> > current code supports IB, RoCE, iWARP and OmniPath as a transport layers.
> > For a lone time, we wanted to rename that folder to be "drivers/rdma",
> > but didn't find enough brave men/women to do it, due to backport mess
> > for such move.
> >
> > The addition of zip accelerator to RDMA is possible and depends on how
> > you will model such new functionality - new driver, or maybe new ULP.
> >
> > >
> > > Further, I don't think it is wise to break an exist system (RDMA) to fulfill a
> > > totally new scenario. The better choice is to let them run in parallel for some
> > > time and try to merge them accordingly.
> >
> > Awesome, so please run your code out-of-tree for now and once you are ready
> > for submission let's try to merge it.
>
> Yes, yes. We know trust need time to gain. But the fact is that there is no
> accelerator user driver can be added to mainline kernel. We should raise the
> topic time to time. So to help the communication to fix the gap, right?
>
> We are also opened to cooperate with IB to do it within the IB framework. But
> please let me know where to start. I feel it is quite wired to make a
> ib_register_device for a zip or RSA accelerator.
>
> >
> > >
> > > >
> > > > >
> > > > > Another problem we tried to address is the way to pin the memory for dma
> > > > > operation. The RDMA way to pin the memory cannot avoid the page lost due to
> > > > > copy-on-write operation during the memory is used by the device. This may
> > > > > not be important to RDMA library. But it is important to accelerator.
> > > >
> > > > Such support exists in drivers/infiniband/ from late 2014 and
> > > > it is called ODP (on demand paging).
> > >
> > > I reviewed ODP and I think it is a solution bound to infiniband. It is part of
> > > MR semantics and required a infiniband specific hook
> > > (ucontext->invalidate_range()). And the hook requires the device to be able to
> > > stop using the page for a while for the copying. It is ok for infiniband
> > > (actually, only mlx5 uses it). I don't think most accelerators can support
> > > this mode. But WarpDrive works fully on top of IOMMU interface, it has no this
> > > limitation.
> >
> > 1. It has nothing to do with infiniband.
>
> But it must be a ib_dev first.
>
> > 2. MR and uncontext are verbs semantics and needed to ensure that host
> > memory exposed to user is properly protected from security point of view.
> > 3. "stop using the page for a while for the copying" - I'm not fully
> > understand this claim, maybe this article will help you to better
> > describe : https://lwn.net/Articles/753027/
>
> This topic was being discussed in RFCv2. The key problem here is that:
>
> The device need to hold the memory for its own calculation, but the CPU/software
> want to stop it for a while for synchronizing with disk or COW.
>
> If the hardware support SVM/SVA (Shared Virtual Memory/Address), it is easy, the
> device share page table with CPU, the device will raise a page fault when the
> CPU downgrade the PTE to read-only.
>
> If the hardware cannot share page table with the CPU, we then need to have
> some way to change the device page table. This is what happen in ODP. It
> invalidates the page table in device upon mmu_notifier call back. But this cannot
> solve the COW problem: if the user process A share a page P with device, and A
> forks a new process B, and it continue to write to the page. By COW, the
> process B will keep the page P, while A will get a new page P'. But you have
> no way to let the device know it should use P' rather than P.
>
> This may be OK for RDMA application. Because RDMA is a big thing and we can ask
> the programmer to avoid the situation. But for a accelerator, I don't think we
> can ask a programmer to care for this when use a zlib.
>
> In WarpDrive/uacce, we make this simple. If you support IOMMU and it support
> SVM/SVA. Everything will be fine just like ODP implicit mode. And you don't need
> to write any code for that. Because it has been done by IOMMU framework. If it
> dose not, you have to use the kernel allocated memory which has the same IOVA as
> the VA in user space. So we can still maintain a unify address space among the
> devices and the applicatin.
>
> > 4. mlx5 supports ODP not because of being partially IB device,
> > but because HW performance oriented implementation is not an easy task.
> >
> > >
> > > >
> > > > >
> > > > > Hope this can help the understanding.
> > > >
> > > > Yes, it helped me a lot.
> > > > Now, I'm more than before convinced that this whole patchset shouldn't
> > > > exist in the first place.
> > >
> > > Then maybe you can tell me how I can register my accelerator to the user space?
> >
> > Write kernel driver and write user space part of it.
> > https://github.com/linux-rdma/rdma-core/
> >
> > I have no doubts that your colleagues who wrote and maintain
> > drivers/infiniband/hw/hns driver know best how to do it.
> > They did it very successfully.
> >
> > Thanks
> >
> > >
> > > >
> > > > To be clear, NAK.
> > > >
> > > > Thanks
> > > >
> > > > >
> > > > > Cheers
> > > > >
> > > > > >
> > > > > > Hard NAK from RDMA side.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > > Signed-off-by: Kenneth Lee <liguozhu@hisilicon.com>
> > > > > > > ---
> > > > > > > Documentation/warpdrive/warpdrive.rst | 260 +++++++
> > > > > > > Documentation/warpdrive/wd-arch.svg | 764 ++++++++++++++++++++
> > > > > > > Documentation/warpdrive/wd.svg | 526 ++++++++++++++
> > > > > > > Documentation/warpdrive/wd_q_addr_space.svg | 359 +++++++++
> > > > > > > 4 files changed, 1909 insertions(+)
> > > > > > > create mode 100644 Documentation/warpdrive/warpdrive.rst
> > > > > > > create mode 100644 Documentation/warpdrive/wd-arch.svg
> > > > > > > create mode 100644 Documentation/warpdrive/wd.svg
> > > > > > > create mode 100644 Documentation/warpdrive/wd_q_addr_space.svg
> > > > > > >
> > > > > > > diff --git a/Documentation/warpdrive/warpdrive.rst b/Documentation/warpdrive/warpdrive.rst
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..ef84d3a2d462
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/warpdrive/warpdrive.rst
> > > > > > > @@ -0,0 +1,260 @@
> > > > > > > +Introduction of WarpDrive
> > > > > > > +=========================
> > > > > > > +
> > > > > > > +*WarpDrive* is a general accelerator framework for the user application to
> > > > > > > +access the hardware without going through the kernel in data path.
> > > > > > > +
> > > > > > > +It can be used as the quick channel for accelerators, network adaptors or
> > > > > > > +other hardware for application in user space.
> > > > > > > +
> > > > > > > +This may make some implementation simpler. E.g. you can reuse most of the
> > > > > > > +*netdev* driver in kernel and just share some ring buffer to the user space
> > > > > > > +driver for *DPDK* [4] or *ODP* [5]. Or you can combine the RSA accelerator with
> > > > > > > +the *netdev* in the user space as a https reversed proxy, etc.
> > > > > > > +
> > > > > > > +*WarpDrive* takes the hardware accelerator as a heterogeneous processor which
> > > > > > > +can share particular load from the CPU:
> > > > > > > +
> > > > > > > +.. image:: wd.svg
> > > > > > > + :alt: WarpDrive Concept
> > > > > > > +
> > > > > > > +The virtual concept, queue, is used to manage the requests sent to the
> > > > > > > +accelerator. The application send requests to the queue by writing to some
> > > > > > > +particular address, while the hardware takes the requests directly from the
> > > > > > > +address and send feedback accordingly.
> > > > > > > +
> > > > > > > +The format of the queue may differ from hardware to hardware. But the
> > > > > > > +application need not to make any system call for the communication.
> > > > > > > +
> > > > > > > +*WarpDrive* tries to create a shared virtual address space for all involved
> > > > > > > +accelerators. Within this space, the requests sent to queue can refer to any
> > > > > > > +virtual address, which will be valid to the application and all involved
> > > > > > > +accelerators.
> > > > > > > +
> > > > > > > +The name *WarpDrive* is simply a cool and general name meaning the framework
> > > > > > > +makes the application faster. It includes general user library, kernel
> > > > > > > +management module and drivers for the hardware. In kernel, the management
> > > > > > > +module is called *uacce*, meaning "Unified/User-space-access-intended
> > > > > > > +Accelerator Framework".
> > > > > > > +
> > > > > > > +
> > > > > > > +How does it work
> > > > > > > +================
> > > > > > > +
> > > > > > > +*WarpDrive* uses *mmap* and *IOMMU* to play the trick.
> > > > > > > +
> > > > > > > +*Uacce* creates a chrdev for the device registered to it. A "queue" will be
> > > > > > > +created when the chrdev is opened. The application access the queue by mmap
> > > > > > > +different address region of the queue file.
> > > > > > > +
> > > > > > > +The following figure demonstrated the queue file address space:
> > > > > > > +
> > > > > > > +.. image:: wd_q_addr_space.svg
> > > > > > > + :alt: WarpDrive Queue Address Space
> > > > > > > +
> > > > > > > +The first region of the space, device region, is used for the application to
> > > > > > > +write request or read answer to or from the hardware.
> > > > > > > +
> > > > > > > +Normally, there can be three types of device regions mmio and memory regions.
> > > > > > > +It is recommended to use common memory for request/answer descriptors and use
> > > > > > > +the mmio space for device notification, such as doorbell. But of course, this
> > > > > > > +is all up to the interface designer.
> > > > > > > +
> > > > > > > +There can be two types of device memory regions, kernel-only and user-shared.
> > > > > > > +This will be explained in the "kernel APIs" section.
> > > > > > > +
> > > > > > > +The Static Share Virtual Memory region is necessary only when the device IOMMU
> > > > > > > +does not support "Share Virtual Memory". This will be explained after the
> > > > > > > +*IOMMU* idea.
> > > > > > > +
> > > > > > > +
> > > > > > > +Architecture
> > > > > > > +------------
> > > > > > > +
> > > > > > > +The full *WarpDrive* architecture is represented in the following class
> > > > > > > +diagram:
> > > > > > > +
> > > > > > > +.. image:: wd-arch.svg
> > > > > > > + :alt: WarpDrive Architecture
> > > > > > > +
> > > > > > > +
> > > > > > > +The user API
> > > > > > > +------------
> > > > > > > +
> > > > > > > +We adopt a polling style interface in the user space: ::
> > > > > > > +
> > > > > > > + int wd_request_queue(struct wd_queue *q);
> > > > > > > + void wd_release_queue(struct wd_queue *q);
> > > > > > > +
> > > > > > > + int wd_send(struct wd_queue *q, void *req);
> > > > > > > + int wd_recv(struct wd_queue *q, void **req);
> > > > > > > + int wd_recv_sync(struct wd_queue *q, void **req);
> > > > > > > + void wd_flush(struct wd_queue *q);
> > > > > > > +
> > > > > > > +wd_recv_sync() is a wrapper to its non-sync version. It will trapped into
> > > > > > > +kernel and waits until the queue become available.
> > > > > > > +
> > > > > > > +If the queue do not support SVA/SVM. The following helper function
> > > > > > > +can be used to create Static Virtual Share Memory: ::
> > > > > > > +
> > > > > > > + void *wd_preserve_share_memory(struct wd_queue *q, size_t size);
> > > > > > > +
> > > > > > > +The user API is not mandatory. It is simply a suggestion and hint what the
> > > > > > > +kernel interface is supposed to support.
> > > > > > > +
> > > > > > > +
> > > > > > > +The user driver
> > > > > > > +---------------
> > > > > > > +
> > > > > > > +The queue file mmap space will need a user driver to wrap the communication
> > > > > > > +protocol. *UACCE* provides some attributes in sysfs for the user driver to
> > > > > > > +match the right accelerator accordingly.
> > > > > > > +
> > > > > > > +The *UACCE* device attribute is under the following directory:
> > > > > > > +
> > > > > > > +/sys/class/uacce/<dev-name>/params
> > > > > > > +
> > > > > > > +The following attributes is supported:
> > > > > > > +
> > > > > > > +nr_queue_remained (ro)
> > > > > > > + number of queue remained
> > > > > > > +
> > > > > > > +api_version (ro)
> > > > > > > + a string to identify the queue mmap space format and its version
> > > > > > > +
> > > > > > > +device_attr (ro)
> > > > > > > + attributes of the device, see UACCE_DEV_xxx flag defined in uacce.h
> > > > > > > +
> > > > > > > +numa_node (ro)
> > > > > > > + id of numa node
> > > > > > > +
> > > > > > > +priority (rw)
> > > > > > > + Priority or the device, bigger is higher
> > > > > > > +
> > > > > > > +(This is not yet implemented in RFC version)
> > > > > > > +
> > > > > > > +
> > > > > > > +The kernel API
> > > > > > > +--------------
> > > > > > > +
> > > > > > > +The *uacce* kernel API is defined in uacce.h. If the hardware support SVM/SVA,
> > > > > > > +The driver need only the following API functions: ::
> > > > > > > +
> > > > > > > + int uacce_register(uacce);
> > > > > > > + void uacce_unregister(uacce);
> > > > > > > + void uacce_wake_up(q);
> > > > > > > +
> > > > > > > +*uacce_wake_up* is used to notify the process who epoll() on the queue file.
> > > > > > > +
> > > > > > > +According to the IOMMU capability, *uacce* categories the devices as follow:
> > > > > > > +
> > > > > > > +UACCE_DEV_NOIOMMU
> > > > > > > + The device has no IOMMU. The user process cannot use VA on the hardware
> > > > > > > + This mode is not recommended.
> > > > > > > +
> > > > > > > +UACCE_DEV_SVA (UACCE_DEV_PASID | UACCE_DEV_FAULT_FROM_DEV)
> > > > > > > + The device has IOMMU which can share the same page table with user
> > > > > > > + process
> > > > > > > +
> > > > > > > +UACCE_DEV_SHARE_DOMAIN
> > > > > > > + The device has IOMMU which has no multiple page table and device page
> > > > > > > + fault support
> > > > > > > +
> > > > > > > +If the device works in mode other than UACCE_DEV_NOIOMMU, *uacce* will set its
> > > > > > > +IOMMU to IOMMU_DOMAIN_UNMANAGED. So the driver must not use any kernel
> > > > > > > +DMA API but the following ones from *uacce* instead: ::
> > > > > > > +
> > > > > > > + uacce_dma_map(q, va, size, prot);
> > > > > > > + uacce_dma_unmap(q, va, size, prot);
> > > > > > > +
> > > > > > > +*uacce_dma_map/unmap* is valid only for UACCE_DEV_SVA device. It creates a
> > > > > > > +particular PASID and page table for the kernel in the IOMMU (Not yet
> > > > > > > +implemented in the RFC)
> > > > > > > +
> > > > > > > +For the UACCE_DEV_SHARE_DOMAIN device, uacce_dma_map/unmap is not valid.
> > > > > > > +*Uacce* call back start_queue only when the DUS and DKO region is mmapped. The
> > > > > > > +accelerator driver must use those dma buffer, via uacce_queue->qfrs[], on
> > > > > > > +start_queue call back. The size of the queue file region is defined by
> > > > > > > +uacce->ops->qf_pg_start[].
> > > > > > > +
> > > > > > > +We have to do it this way because most of current IOMMU cannot support the
> > > > > > > +kernel and user virtual address at the same time. So we have to let them both
> > > > > > > +share the same user virtual address space.
> > > > > > > +
> > > > > > > +If the device have to support kernel and user at the same time, both kernel
> > > > > > > +and the user should use these DMA API. This is not convenient. A better
> > > > > > > +solution is to change the future DMA/IOMMU design to let them separate the
> > > > > > > +address space between the user and kernel space. But it is not going to be in
> > > > > > > +a short time.
> > > > > > > +
> > > > > > > +
> > > > > > > +Multiple processes support
> > > > > > > +==========================
> > > > > > > +
> > > > > > > +In the latest mainline kernel (4.19) when this document is written, the IOMMU
> > > > > > > +subsystem do not support multiple process page tables yet.
> > > > > > > +
> > > > > > > +Most IOMMU hardware implementation support multi-process with the concept
> > > > > > > +of PASID. But they may use different name, e.g. it is call sub-stream-id in
> > > > > > > +SMMU of ARM. With PASID or similar design, multi page table can be added to
> > > > > > > +the IOMMU and referred by its PASID.
> > > > > > > +
> > > > > > > +*JPB* has a patchset to enable this[1]_. We have tested it with our hardware
> > > > > > > +(which is known as *D06*). It works well. *WarpDrive* rely on them to support
> > > > > > > +UACCE_DEV_SVA. If it is not enabled, *WarpDrive* can still work. But it
> > > > > > > +support only one process, the device will be set to UACCE_DEV_SHARE_DOMAIN
> > > > > > > +even it is set to UACCE_DEV_SVA initially.
> > > > > > > +
> > > > > > > +Static Share Virtual Memory is mainly used by UACCE_DEV_SHARE_DOMAIN device.
> > > > > > > +
> > > > > > > +
> > > > > > > +Legacy Mode Support
> > > > > > > +===================
> > > > > > > +For the hardware without IOMMU, WarpDrive can still work, the only problem is
> > > > > > > +VA cannot be used in the device. The driver should adopt another strategy for
> > > > > > > +the shared memory. It is only for testing, and not recommended.
> > > > > > > +
> > > > > > > +
> > > > > > > +The Folk Scenario
> > > > > > > +=================
> > > > > > > +For a process with allocated queues and shared memory, what happen if it forks
> > > > > > > +a child?
> > > > > > > +
> > > > > > > +The fd of the queue will be duplicated on folk, so the child can send request
> > > > > > > +to the same queue as its parent. But the requests which is sent from processes
> > > > > > > +except for the one who open the queue will be blocked.
> > > > > > > +
> > > > > > > +It is recommended to add O_CLOEXEC to the queue file.
> > > > > > > +
> > > > > > > +The queue mmap space has a VM_DONTCOPY in its VMA. So the child will lost all
> > > > > > > +those VMAs.
> > > > > > > +
> > > > > > > +This is why *WarpDrive* does not adopt the mode used in *VFIO* and *InfiniBand*.
> > > > > > > +Both solutions can set any user pointer for hardware sharing. But they cannot
> > > > > > > +support fork when the dma is in process. Or the "Copy-On-Write" procedure will
> > > > > > > +make the parent process lost its physical pages.
> > > > > > > +
> > > > > > > +
> > > > > > > +The Sample Code
> > > > > > > +===============
> > > > > > > +There is a sample user land implementation with a simple driver for Hisilicon
> > > > > > > +Hi1620 ZIP Accelerator.
> > > > > > > +
> > > > > > > +To test, do the following in samples/warpdrive (for the case of PC host): ::
> > > > > > > + ./autogen.sh
> > > > > > > + ./conf.sh # or simply ./configure if you build on target system
> > > > > > > + make
> > > > > > > +
> > > > > > > +Then you can get test_hisi_zip in the test subdirectory. Copy it to the target
> > > > > > > +system and make sure the hisi_zip driver is enabled (the major and minor of
> > > > > > > +the uacce chrdev can be gotten from the dmesg or sysfs), and run: ::
> > > > > > > + mknod /dev/ua1 c <major> <minior>
> > > > > > > + test/test_hisi_zip -z < data > data.zip
> > > > > > > + test/test_hisi_zip -g < data > data.gzip
> > > > > > > +
> > > > > > > +
> > > > > > > +References
> > > > > > > +==========
> > > > > > > +.. [1] https://patchwork.kernel.org/patch/10394851/
> > > > > > > +
> > > > > > > +.. vim: tw=78
> > > [...]
> > > > > > > --
> > > > > > > 2.17.1
> > > > > > >
I don't know if Mr. Jerome Glisse in the list. I think I should cc him for my
respectation to his help on last RFC.
- Kenneth
^ 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