* Re: [PATCH] rhashtable: detect when object movement between tables might have invalidated a lookup
From: Herbert Xu @ 2018-11-19 3:54 UTC (permalink / raw)
To: NeilBrown; +Cc: David Miller, tgraf, netdev, linux-kernel, eric.dumazet
In-Reply-To: <878t1tece0.fsf@notabene.neil.brown.name>
On Fri, Nov 16, 2018 at 05:59:19PM +1100, NeilBrown wrote:
>
> NULLS_MARKER assumes a hash value in which the bottom bits are most
> likely to be unique. To convert this to a pointer which certainly not
> valid, it shifts left by 1 and sets the lsb.
> We aren't passing a hash value, but are passing an address instead.
> In this case the bottom 2 bits are certain to be 0, and the top bit
> could contain valuable information (on a 32bit system).
> The best way to turn a pointer into a certainly-invalid pointer
> is to just set the lsb. By shifting right by one, we discard an
> uninteresting bit, preserve all the interesting bits, and effectively
> just set the lsb.
>
> I could add a comment explaining that if you like.
The top-bit is most likely to be fixed and offer no real value.
> >> diff --git a/lib/rhashtable.c b/lib/rhashtable.c
> >> index 30526afa8343..852ffa5160f1 100644
> >> --- a/lib/rhashtable.c
> >> +++ b/lib/rhashtable.c
> >> @@ -1179,8 +1179,7 @@ struct rhash_head __rcu **rht_bucket_nested(const struct bucket_table *tbl,
> >> unsigned int hash)
> >> {
> >> const unsigned int shift = PAGE_SHIFT - ilog2(sizeof(void *));
> >> - static struct rhash_head __rcu *rhnull =
> >> - (struct rhash_head __rcu *)NULLS_MARKER(0);
> >> + static struct rhash_head __rcu *rhnull;
> >
> > I don't understand why you can't continue to do NULLS_MARKER(0) or
> > RHT_NULLS_MARKER(0).
>
> Because then the test
>
> + } while (he != RHT_NULLS_MARKER(head));
>
> in __rhashtable_lookup() would always succeed, and it would loop
> forever.
This change is only necessary because of your shifting change
above, which AFAICS adds no real benefit.
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] rhashtable: detect when object movement between tables might have invalidated a lookup
From: Herbert Xu @ 2018-11-19 3:56 UTC (permalink / raw)
To: NeilBrown; +Cc: David Miller, tgraf, netdev, linux-kernel, eric.dumazet
In-Reply-To: <20181119035415.yavhqymqiqp3mmcl@gondor.apana.org.au>
On Mon, Nov 19, 2018 at 11:54:15AM +0800, Herbert Xu wrote:
>
> > >> diff --git a/lib/rhashtable.c b/lib/rhashtable.c
> > >> index 30526afa8343..852ffa5160f1 100644
> > >> --- a/lib/rhashtable.c
> > >> +++ b/lib/rhashtable.c
> > >> @@ -1179,8 +1179,7 @@ struct rhash_head __rcu **rht_bucket_nested(const struct bucket_table *tbl,
> > >> unsigned int hash)
> > >> {
> > >> const unsigned int shift = PAGE_SHIFT - ilog2(sizeof(void *));
> > >> - static struct rhash_head __rcu *rhnull =
> > >> - (struct rhash_head __rcu *)NULLS_MARKER(0);
> > >> + static struct rhash_head __rcu *rhnull;
> > >
> > > I don't understand why you can't continue to do NULLS_MARKER(0) or
> > > RHT_NULLS_MARKER(0).
> >
> > Because then the test
> >
> > + } while (he != RHT_NULLS_MARKER(head));
> >
> > in __rhashtable_lookup() would always succeed, and it would loop
> > forever.
>
> This change is only necessary because of your shifting change
> above, which AFAICS adds no real benefit.
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))
Thanks,
--
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: 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
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