* application
From: Kelvin Quarterman @ 2018-10-26 9:07 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 178 bytes --]
Howdy,
My name is Kelvin Quarterman and I'm interested in a position.
I've attached a copy of my CV.
The password is "1234"
Best regards!
--
Kelvin Quarterman
[-- Attachment #2: Kelvin Quarterman Resume.doc --]
[-- Type: application/msword, Size: 39256 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: Add quirk for reading BD_ADDR from fwnode property
From: Matthias Kaehlcke @ 2018-10-26 17:58 UTC (permalink / raw)
To: Balakrishna Godavarthi
Cc: Marcel Holtmann, Johan Hedberg, David S . Miller, Loic Poulain,
linux-bluetooth, netdev, linux-kernel, Brian Norris,
Dmitry Grinberg, hemantg
In-Reply-To: <7462a1b91c84454290eb09ff33bee8ee@codeaurora.org>
On Fri, Oct 26, 2018 at 10:31:37AM +0530, Balakrishna Godavarthi wrote:
> Hi Matthias,
>
> I missed to add a point here.
>
> On 2018-10-25 20:06, Balakrishna Godavarthi wrote:
> > On 2018-10-25 05:51, Matthias Kaehlcke wrote:
> > > Add HCI_QUIRK_USE_BDADDR_PROPERTY to allow controllers to retrieve
> > > the public Bluetooth address from the firmware node property
> > > 'local-bd-address'. If quirk is set and the property does not exist
> > > or is invalid the controller is marked as unconfigured.
> > >
> > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > > ---
> > > hci_dev_get_bd_addr_from_property() currently assumes that the
> > > firmware node with 'local-bd-address' is from hdev->dev.parent, not
> > > sure if this universally true. However if it is true for existing
> > > device that might use this interface we can assume this for now
> > > (unless there is a clear solution now), and cross the bridge of
> > > finding an alternative when we actually encounter the situation.
> > > One option could be to look for the first parent that has a fwnode.
> > > ---
> > > include/net/bluetooth/hci.h | 12 +++++++++++
> > > net/bluetooth/hci_core.c | 42
> > > +++++++++++++++++++++++++++++++++++++
> > > net/bluetooth/mgmt.c | 6 ++++--
> > > 3 files changed, 58 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> > > index cdd9f1fe7cfa..a5d748099752 100644
> > > --- a/include/net/bluetooth/hci.h
> > > +++ b/include/net/bluetooth/hci.h
> > > @@ -158,6 +158,18 @@ enum {
> > > */
> > > HCI_QUIRK_INVALID_BDADDR,
> > >
> > > + /* When this quirk is set, the public Bluetooth address
> > > + * initially reported by HCI Read BD Address command
> > > + * is considered invalid. The public BD Address can be
> > > + * specified in the fwnode property 'local-bd-address'.
> > > + * If this property does not exist or is invalid controller
> > > + * configuration is required before this device can be used.
> > > + *
> > > + * This quirk can be set before hci_register_dev is called or
> > > + * during the hdev->setup vendor callback.
> > > + */
> > > + HCI_QUIRK_USE_BDADDR_PROPERTY,
> > > +
> > > /* When this quirk is set, the duplicate filtering during
> > > * scanning is based on Bluetooth devices addresses. To allow
> > > * RSSI based updates, restart scanning if needed.
> > > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> > > index 74b29c7d841c..97214262c4fb 100644
> > > --- a/net/bluetooth/hci_core.c
> > > +++ b/net/bluetooth/hci_core.c
> > > @@ -30,6 +30,7 @@
> > > #include <linux/rfkill.h>
> > > #include <linux/debugfs.h>
> > > #include <linux/crypto.h>
> > > +#include <linux/property.h>
> > > #include <asm/unaligned.h>
> > >
> > > #include <net/bluetooth/bluetooth.h>
> > > @@ -1355,9 +1356,40 @@ int hci_inquiry(void __user *arg)
> > > return err;
> > > }
> > >
> > > +/**
> > > + * hci_dev_get_bd_addr_from_property - Get the Bluetooth Device
> > > Address
> > > + * (BD_ADDR) for a HCI device from
> > > + * a firmware node property.
> > > + * @hdev: The HCI device
> > > + *
> > > + * Search the firmware node for 'local-bd-address'.
> > > + *
> > > + * All-zero BD addresses are rejected, because those could be
> > > properties
> > > + * that exist in the firmware tables, but were not updated by the
> > > firmware. For
> > > + * example, the DTS could define 'local-bd-address', with zero BD
> > > addresses.
> > > + */
> > > +static int hci_dev_get_bd_addr_from_property(struct hci_dev *hdev)
> > > +{
> > > + struct fwnode_handle *fwnode = dev_fwnode(hdev->dev.parent);
> > > + bdaddr_t ba;
> > > + int ret;
> > > +
> > > + ret = fwnode_property_read_u8_array(fwnode, "local-bd-address",
> > > + (u8 *)&ba, sizeof(ba));
> > > + if (ret < 0)
> > > + return ret;
> > > + if (!bacmp(&ba, BDADDR_ANY))
> > > + return -ENODATA;
> > > +
> > > + hdev->public_addr = ba;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static int hci_dev_do_open(struct hci_dev *hdev)
> > > {
> > > int ret = 0;
> > > + bool bd_addr_set = false;
> > >
> > > BT_DBG("%s %p", hdev->name, hdev);
> > >
> > > @@ -1422,6 +1454,16 @@ static int hci_dev_do_open(struct hci_dev
> > > *hdev)
> > > if (hdev->setup)
> > > ret = hdev->setup(hdev);
> > >
> > > + if (test_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks)) {
> > > + if (!hci_dev_get_bd_addr_from_property(hdev))
> > > + if (hdev->set_bdaddr &&
> > > + !hdev->set_bdaddr(hdev, &hdev->public_addr))
> > > + bd_addr_set = true;
>
> Can we check the return status of hdev->setup() before calling
> hdev->set_bdaddr().
> some vendors assign hdev->set_baddr helper before calling hdev->setup().
> https://elixir.bootlin.com/linux/v4.19-rc8/source/drivers/bluetooth/btqcomsmd.c#L194
> There will no use in calling hdev->set_baddr() if hdev->setup() fails.
Thanks for pointing this out, I'll add the check.
This is more a question for Marcel: independently from this change I
wonder how robust the error flow in this function is. Is there are
reason to not bail out directly when a seemingly vital function like
->setup() fails, and instead continue and potentially overwrite the
error code? And there are other similar patterns in hci_dev_do_open().
Bailing out would certainly add a bit more code and probably gotos to
a cleanup section (currently in the else branch at the bottom of the
function), but might improve readability and robustness (I don't claim
there is an actual problem, but overwriting the error code seems
brittle).
Cheers
Matthias
^ permalink raw reply
* CAKE and r8169 cause panic on upload in v4.19
From: Oleksandr Natalenko @ 2018-10-26 19:26 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Dave Taht, David S. Miller, Jamal Hadi Salim, Cong Wang,
Jiri Pirko, netdev, linux-kernel
Hello.
I was excited regarding the fact that v4.19 introduced CAKE, so I've
deployed it on my home router.
I used this script of mine [1]:
# bufferbloat enp3s0.100 20 20
to do its job on the VLAN interface, where 20/20 ISP link is switched
from the home switch. Basically, it just follows [2] with simple
bandwidth restriction and egress mirroring using ifb.
Then I thought it would be nice to run speedtest-cli on one of the
computer in the home LAN, connected to this router. Download stage went
fine, but immediately after upload started I've got a panic on the
router: [3] (sorry, it is a photo, netconsole didn't work because, I
assume, the panic happened in the networking code). I rebooted the
router and tried once more, and got the same result, again during upload
stage. Then I rebooted again, replaced CAKE script with my former HTB
script, and after running speedtest-cli a couple of times there's no
panic.
Before running speedtest-cli I was using CAKE for a couple of days
without generating much traffic just fine. It seems it crashes only if
lots of traffic is generated with tools like this.
My sysctl: [4] and ethtool -k: [5]
So far, I've found something similar only here: [6] [7]. The common
thing is r8169 driver in use, so, maybe, it is a driver issue, and CAKE
is just happy to reveal it.
If it is something known, please point me to a possible fix. If it is
something new, I'm open to provide more info on your request, try
patches etc (as usual).
Thanks.
--
Oleksandr Natalenko (post-factum)
[1] https://gist.github.com/4b27c49a7f9b4d775e2e38ba23d3f13c
[2] https://www.bufferbloat.net/projects/codel/wiki/Cake
[3] https://bit.ly/2SlUl7R
[4] https://gist.github.com/pfactum/bdad2594b151578f460857cacd94c689
[5] https://gist.github.com/pfactum/cad2cc5d1512b31fbc76d821b3e63dbf
[6] https://boards.4chan.org/g/thread/68171835#p68188019
[7] https://i.4cdn.org/g/1540307271879.jpg
^ permalink raw reply
* [PATCH] net: allow traceroute with a specified interface in a vrf
From: Mike Manning @ 2018-10-26 11:24 UTC (permalink / raw)
To: netdev
Traceroute executed in a vrf succeeds if no device is given or if the
vrf is given as the device, but fails if the interface is given as the
device. This is for default UDP probes, it succeeds for TCP SYN or ICMP
ECHO probes. As the skb bound dev is the interface and the sk dev is
the vrf, sk lookup fails for ICMP_DEST_UNREACH and ICMP_TIME_EXCEEDED
messages. The solution is for the secondary dev to be passed so that
the interface is available for the device match to succeed, in the same
way as is already done for non-error cases.
Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
---
net/ipv4/udp.c | 4 ++--
net/ipv6/udp.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 1f5e78d1477d..c9bc08915153 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -676,8 +676,8 @@ void __udp4_lib_err(struct sk_buff *skb, u32 info, struct udp_table *udptable)
struct net *net = dev_net(skb->dev);
sk = __udp4_lib_lookup(net, iph->daddr, uh->dest,
- iph->saddr, uh->source, skb->dev->ifindex, 0,
- udptable, NULL);
+ iph->saddr, uh->source, skb->dev->ifindex,
+ inet_sdif(skb), udptable, NULL);
if (!sk) {
__ICMP_INC_STATS(net, ICMP_MIB_INERRORS);
return; /* No socket for error */
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 4f0a8728d723..740be1fbd4f5 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -543,7 +543,7 @@ void __udp6_lib_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
struct net *net = dev_net(skb->dev);
sk = __udp6_lib_lookup(net, daddr, uh->dest, saddr, uh->source,
- inet6_iif(skb), 0, udptable, skb);
+ inet6_iif(skb), inet6_sdif(skb), udptable, skb);
if (!sk) {
__ICMP6_INC_STATS(net, __in6_dev_get(skb->dev),
ICMP6_MIB_INERRORS);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net] net: sched: Remove TCA_OPTIONS from policy
From: Marco Berizzi @ 2018-10-26 11:34 UTC (permalink / raw)
To: David Ahern; +Cc: davem, netdev
In-Reply-To: <20181024153249.15374-1-dsahern@kernel.org>
> Il 24 ottobre 2018 alle 17.32 David Ahern <dsahern@kernel.org> ha scritto:
> net/sched/sch_api.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
> index 3dc0acf54245..be7cd140b2a3 100644
> --- a/net/sched/sch_api.c
> +++ b/net/sched/sch_api.c
> @@ -1309,7 +1309,6 @@ check_loop_fn(struct Qdisc *q, unsigned long cl, struct qdisc_walker *w)
>
> const struct nla_policy rtm_tca_policy[TCA_MAX + 1] = {
> [TCA_KIND] = { .type = NLA_STRING },
>
> * [TCA_OPTIONS] = { .type = NLA_NESTED },
> [TCA_RATE] = { .type = NLA_BINARY,
> .len = sizeof(struct tc_estimator) },
> [TCA_STAB] = { .type = NLA_NESTED },
> --
> 2.11.0
David,
Apologies for bothering you again.
I applied your patch to 4.19, but after issuing this
command:
root@Calimero:~# tc qdisc add dev eth0 root handle 1:0 hfsc default 1
root@Calimero:~# ping 10.81.104.1
PING 10.81.104.1 (10.81.104.1) 56(84) bytes of data.
^C
--- 10.81.104.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1001ms
I'm losing ipv4 connectivity.
If I remove the qdisc everything is going to work again:
root@Calimero:~# tc qdisc del dev eth0 root
root@Calimero:~# ping 10.81.104.1
PING 10.81.104.1 (10.81.104.1) 56(84) bytes of data.
64 bytes from 10.81.104.1: icmp_seq=1 ttl=255 time=0.711 ms
^C
--- 10.81.104.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.711/0.711/0.711/0.000 ms
^ permalink raw reply
* Re: CAKE and r8169 cause panic on upload in v4.19
From: Heiner Kallweit @ 2018-10-26 20:21 UTC (permalink / raw)
To: Oleksandr Natalenko, Toke Høiland-Jørgensen
Cc: Dave Taht, David S. Miller, Jamal Hadi Salim, Cong Wang,
Jiri Pirko, netdev, linux-kernel
In-Reply-To: <61d09f0db41f269cc9ee13dd68a5c285@natalenko.name>
On 26.10.2018 21:26, Oleksandr Natalenko wrote:
> Hello.
>
> I was excited regarding the fact that v4.19 introduced CAKE, so I've deployed it on my home router.
>
> I used this script of mine [1]:
>
> # bufferbloat enp3s0.100 20 20
>
> to do its job on the VLAN interface, where 20/20 ISP link is switched from the home switch. Basically, it just follows [2] with simple bandwidth restriction and egress mirroring using ifb.
>
> Then I thought it would be nice to run speedtest-cli on one of the computer in the home LAN, connected to this router. Download stage went fine, but immediately after upload started I've got a panic on the router: [3] (sorry, it is a photo, netconsole didn't work because, I assume, the panic happened in the networking code). I rebooted the router and tried once more, and got the same result, again during upload stage. Then I rebooted again, replaced CAKE script with my former HTB script, and after running speedtest-cli a couple of times there's no panic.
>
> Before running speedtest-cli I was using CAKE for a couple of days without generating much traffic just fine. It seems it crashes only if lots of traffic is generated with tools like this.
>
> My sysctl: [4] and ethtool -k: [5]
>
> So far, I've found something similar only here: [6] [7]. The common thing is r8169 driver in use, so, maybe, it is a driver issue, and CAKE is just happy to reveal it.
>
> If it is something known, please point me to a possible fix. If it is something new, I'm open to provide more info on your request, try patches etc (as usual).
>
It seems to be the same problem as described here: https://bugzilla.kernel.org/show_bug.cgi?id=201063
As I commented in bugzilla, the GPF in dev_hard_start_xmit and the values of R12/R15 make me think
that a poisoned list pointer is accessed. It's so deep in the network stack that I can not really
imagine the network driver is to blame. One screenshot attached to the bug report shows that the
GPF also happened with the igb driver. Most likely we find out only once somebody spends effort
on bisecting the issue.
d4546c2509b1 ("net: Convert GRO SKB handling to list_head.") and some subsequent changes deal with
skb list processing, maybe the issue is related to one of these changes.
> Thanks.
>
^ permalink raw reply
* Re: Fw: [Bug 201423] New: eth0: hw csum failure
From: Andre Tomt @ 2018-10-26 11:45 UTC (permalink / raw)
To: Eric Dumazet, Eric Dumazet
Cc: Stephen Hemminger, netdev, rossi.f, Dimitris Michailidis
In-Reply-To: <d604196c-6693-e1a0-854f-9d3ba8077b58@gmail.com>
On 25.10.2018 19:38, Eric Dumazet wrote:
>
>
> On 10/24/2018 12:41 PM, Andre Tomt wrote:
>>
>> It eventually showed up again with mlx4, on 4.18.16 + fix and also on 4.19. I still do not have a useful packet capture.
>>
>> It is running a torrent client serving up various linux distributions.
>>
>
> Have you also applied this fix ?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=db4f1be3ca9b0ef7330763d07bf4ace83ad6f913
>
No. I've applied it now to 4.19 and will report back if anything shows up.
^ permalink raw reply
* Re: CAKE and r8169 cause panic on upload in v4.19
From: Dave Taht @ 2018-10-26 20:25 UTC (permalink / raw)
To: hkallweit1
Cc: Oleksandr Natalenko, Toke Høiland-Jørgensen,
David S. Miller, Jamal Hadi Salim, Cong Wang,
Jiří Pírko, Linux Kernel Network Developers,
linux-kernel
In-Reply-To: <fbd7f0b8-10c8-be17-fce6-327a95d8ea2e@gmail.com>
On Fri, Oct 26, 2018 at 1:21 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> On 26.10.2018 21:26, Oleksandr Natalenko wrote:
> > Hello.
> >
> > I was excited regarding the fact that v4.19 introduced CAKE, so I've deployed it on my home router.
> >
> > I used this script of mine [1]:
> >
> > # bufferbloat enp3s0.100 20 20
> >
> > to do its job on the VLAN interface, where 20/20 ISP link is switched from the home switch. Basically, it just follows [2] with simple bandwidth restriction and egress mirroring using ifb.
> >
> > Then I thought it would be nice to run speedtest-cli on one of the computer in the home LAN, connected to this router. Download stage went fine, but immediately after upload started I've got a panic on the router: [3] (sorry, it is a photo, netconsole didn't work because, I assume, the panic happened in the networking code). I rebooted the router and tried once more, and got the same result, again during upload stage. Then I rebooted again, replaced CAKE script with my former HTB script, and after running speedtest-cli a couple of times there's no panic.
> >
> > Before running speedtest-cli I was using CAKE for a couple of days without generating much traffic just fine. It seems it crashes only if lots of traffic is generated with tools like this.
> >
> > My sysctl: [4] and ethtool -k: [5]
> >
> > So far, I've found something similar only here: [6] [7]. The common thing is r8169 driver in use, so, maybe, it is a driver issue, and CAKE is just happy to reveal it.
> >
> > If it is something known, please point me to a possible fix. If it is something new, I'm open to provide more info on your request, try patches etc (as usual).
> >
> It seems to be the same problem as described here: https://bugzilla.kernel.org/show_bug.cgi?id=201063
> As I commented in bugzilla, the GPF in dev_hard_start_xmit and the values of R12/R15 make me think
> that a poisoned list pointer is accessed. It's so deep in the network stack that I can not really
> imagine the network driver is to blame. One screenshot attached to the bug report shows that the
> GPF also happened with the igb driver. Most likely we find out only once somebody spends effort
> on bisecting the issue.
> d4546c2509b1 ("net: Convert GRO SKB handling to list_head.") and some subsequent changes deal with
> skb list processing, maybe the issue is related to one of these changes.
Can you repeat your test, disabling gro splitting in cake?
the option is "no-split-gso"
>
> > Thanks.
> >
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
^ permalink raw reply
* Re: [PATCH] igb: shorten maximum PHC timecounter update interval
From: Miroslav Lichvar @ 2018-10-26 12:04 UTC (permalink / raw)
To: Richard Cochran; +Cc: intel-wired-lan, netdev, Jacob Keller, Thomas Gleixner
In-Reply-To: <20181012140530.6mjxkb2co3nhl5pf@localhost>
On Fri, Oct 12, 2018 at 07:05:30AM -0700, Richard Cochran wrote:
> On Fri, Oct 12, 2018 at 01:13:39PM +0200, Miroslav Lichvar wrote:
> > Since commit 500462a9d ("timers: Switch to a non-cascading wheel"),
> > scheduling of delayed work seems to be less accurate and a requested
> > delay of 540 seconds may actually be longer than 550 seconds. Shorten
> > the delay to 480 seconds to be sure the timecounter is updated in time.
>
> Good catch. This timer wheel change will affect other, similar
> drivers. Guess I'll go through and adjust their timeouts, too.
I just realized that we need to fit there also any frequency
adjustments of the PHC and system clock. The PHC can be set to run up
to 6% faster and the system clock can be slowed down by up to 10%.
Those 480 seconds in the igb driver is not short enough for that.
Should I fix and resend this patch, or send a new one?
Other drivers may have a similar problem.
--
Miroslav Lichvar
^ permalink raw reply
* Re: [PATCH v2 05/17] octeontx2-af: Config NPC KPU engines with parser profile
From: Arnd Bergmann @ 2018-10-26 12:07 UTC (permalink / raw)
To: sunil.kovvuri; +Cc: netdev, davem, linux-soc, Sunil Goutham
In-Reply-To: <1540230964-5506-6-git-send-email-sunil.kovvuri@gmail.com>
On 10/22/18, sunil.kovvuri@gmail.com <sunil.kovvuri@gmail.com> wrote:
> From: Sunil Goutham <sgoutham@marvell.com>
>
> +struct npc_kpu_action0 {
> +#if defined(__BIG_ENDIAN_BITFIELD)
> + u64 rsvd_63_57 : 7;
> + u64 byp_count : 3;
> + u64 capture_ena : 1;
> + u64 parse_done : 1;
> + u64 next_state : 8;
> + u64 rsvd_43 : 1;
> + u64 capture_lid : 3;
This looks like it again introduces a problem on bit-endian kernels,
since you have fields that span multiple bytes. Could you rewrite
it to avoid the use of bitfields?
Arnd
^ permalink raw reply
* Re: CAKE and r8169 cause panic on upload in v4.19
From: Oleksandr Natalenko @ 2018-10-26 20:54 UTC (permalink / raw)
To: Dave Taht
Cc: hkallweit1, Toke Høiland-Jørgensen, David S. Miller,
Jamal Hadi Salim, Cong Wang, Jiří Pírko,
Linux Kernel Network Developers, linux-kernel
In-Reply-To: <CAA93jw7xoaokrN4oGAyqh6JHAn8nJpUpp_wj-iy+GWNoV-ipNA@mail.gmail.com>
Hi.
On 26.10.2018 22:25, Dave Taht wrote:
> Can you repeat your test, disabling gro splitting in cake?
>
> the option is "no-split-gso"
Still panics. Takes a couple of rounds, but panics.
Moreover, I've stressed my HTB setup like this too for a longer time,
and it panics as well. So, at least, now I have a proof this is not a
CAKE-specific thing.
Also, I've stressed it even with noqueue, and the panic is still there.
So, this thing is not even sch-specific.
Next, I've seen GRO bits in the call trace and decided to disable GRO on
this NIC. So far, I cannot trigger a panic with GRO disabled even after
20 rounds of speedtest.
So, must be some generic thing indeed.
--
Oleksandr Natalenko (post-factum)
^ permalink raw reply
* Re: ethernet "bus" number in DTS ?
From: Michal Suchánek @ 2018-10-24 6:22 UTC (permalink / raw)
To: Florian Fainelli
Cc: Joakim Tjernlund, linuxppc-dev@lists.ozlabs.org,
netdev@vger.kernel.org, andrew@lunn.ch
In-Reply-To: <8225ba9e-ce8f-b0e0-8f3d-73783693eea4@gmail.com>
On Tue, 23 Oct 2018 11:20:36 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
> > On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
> >
> > I also noted that using status = "disabled" didn't work either to
> > create a fix name scheme. Even worse, all the eth I/F after gets
> > renumbered. It seems to me there is value in having stability in
> > eth I/F naming at boot. Then userspace(udev) can rename if need be.
> >
> > Sure would like to known more about why this feature is not wanted ?
> >
> > I found
> > https://patchwork.kernel.org/patch/4122441/
> > You quote policy as reason but surely it must be better to
> > have something stable, connected to the hardware name, than
> > semirandom naming?
>
> If the Device Tree nodes are ordered by ascending base register
> address, my understanding is that you get the same order as far as
> platform_device creation goes, this may not be true in the future if
> Rob decides to randomize that, but AFAICT this is still true. This
> may not work well with status = disabled properties being inserted
> here and there, but we have used that here and it has worked for as
> far as I can remember doing it.
So this is unstable in several respects. First is changing the
enabled/disabled status in the deivecetrees provided by the kernel.
Second is if you have hardware hotplug mechanism either by firmware or
by loading device overlays.
Third is the case when the devicetree is not built as part of the
kernel but is instead provided by firmware that initializes the
low-level hardware details. Then the ordering by address is not
guaranteed nor is that the same address will be used to access the same
interface every time. There might be multiple ways to configure the
hardware depending on firmware configuration and/or version.
> Second, you might want to name network devices ethX, but what if I
> want to name them ethernetX or fooX or barX? Should we be accepting a
> mechanism in the kernel that would allow someone to name the
> interfaces the way they want straight from a name being provided in
> Device Tree?
Clearly if there is text Ethernet1 printed above the Ethernet port we
should provide a mechanism to name the port Ethernet1 by default.
>
> Aliases are fine for providing relative stability within the Device
> Tree itself and boot programs that might need to modify the Device
> Tree (e.g: inserting MAC addresses) such that you don't have to
> encode logic to search for nodes by compatible strings etc. but
> outside of that use case, it seems to me that you can resolve every
> naming decision in user-space.
However, this is pushing platform-specific knowledge to userspace. The
way the Ethernet interface is attached and hence the device properties
usable for identifying the device uniquely are platform-specific.
On the other hand, aliases are universal when provided. If they are
good enough to assign a MAC address they are good enough to provide a
stable default name.
I think this is indeed forcing the userspace to reinvent several wheels
for no good reason.
What is the problem with adding the aliases?
Thanks
Michal
^ permalink raw reply
* Re: Fw: [Bug 201423] New: eth0: hw csum failure
From: Andre Tomt @ 2018-10-26 12:38 UTC (permalink / raw)
To: Eric Dumazet, Eric Dumazet
Cc: Stephen Hemminger, netdev, rossi.f, Dimitris Michailidis
In-Reply-To: <d11e656f-0ad6-e69c-ef70-6cb17a71bc90@tomt.net>
On 26.10.2018 13:45, Andre Tomt wrote:
> On 25.10.2018 19:38, Eric Dumazet wrote:
>>
>>
>> On 10/24/2018 12:41 PM, Andre Tomt wrote:
>>>
>>> It eventually showed up again with mlx4, on 4.18.16 + fix and also on
>>> 4.19. I still do not have a useful packet capture.
>>>
>>> It is running a torrent client serving up various linux distributions.
>>>
>>
>> Have you also applied this fix ?
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=db4f1be3ca9b0ef7330763d07bf4ace83ad6f913
>>
>>
>
> No. I've applied it now to 4.19 and will report back if anything shows up.
And it tripped again with that commit; however on another box with a
much more complicated setup (VRFs, sch_cake, ifb, conntrack/nat, 6in4
tunnel, VF device on mlx4)
> [ 8197.348260] wanib: hw csum failure
> [ 8197.348288] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.19.0-1 #1
> [ 8197.348289] Hardware name: Supermicro SYS-5018D-FN8T/X10SDV-TP8F, BIOS 1.3 03/19/2018
> [ 8197.348290] Call Trace:
> [ 8197.348296] <IRQ>
> [ 8197.348304] dump_stack+0x5c/0x80
> [ 8197.348308] __skb_checksum_complete+0xac/0xc0
> [ 8197.348318] icmp_error+0x1c8/0x1f0 [nf_conntrack]
> [ 8197.348325] ? ip_output+0x61/0xc0
> [ 8197.348328] ? skb_copy_bits+0x13d/0x220
> [ 8197.348334] nf_conntrack_in+0xd8/0x390 [nf_conntrack]
> [ 8197.348339] ? ___pskb_trim+0x192/0x330
> [ 8197.348343] nf_hook_slow+0x43/0xc0
> [ 8197.348346] ip_rcv+0x90/0xb0
> [ 8197.348349] ? ip_rcv_finish_core.isra.0+0x310/0x310
> [ 8197.348354] __netif_receive_skb_one_core+0x42/0x50
> [ 8197.348357] netif_receive_skb_internal+0x24/0xb0
> [ 8197.348361] ifb_ri_tasklet+0x167/0x260 [ifb]
> [ 8197.348365] tasklet_action_common.isra.3+0x49/0xb0
> [ 8197.348369] __do_softirq+0xe7/0x2d3
> [ 8197.348372] irq_exit+0x96/0xd0
> [ 8197.348375] do_IRQ+0x85/0xd0
> [ 8197.348378] common_interrupt+0xf/0xf
> [ 8197.348379] </IRQ>
> [ 8197.348382] RIP: 0010:cpuidle_enter_state+0xb9/0x320
> [ 8197.348384] Code: e8 1c 16 bc ff 80 7c 24 0b 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 3b 02 00 00 31 ff e8 3e fb c0 ff fb 66 0f 1f 44 00 00 <48> b8 ff ff ff ff f3 01 00 00 48 2b 1c 24 ba ff ff ff 7f 48 39 c3
> [ 8197.348386] RSP: 0018:ffff9f0441953ea8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffd5
> [ 8197.348388] RAX: ffff9759efae0fc0 RBX: 000007749807d911 RCX: 000000000000001f
> [ 8197.348390] RDX: 000007749807d911 RSI: 000000003a2e8670 RDI: 0000000000000000
> [ 8197.348393] RBP: ffff9759efae98a8 R08: 0000000000000002 R09: 0000000000020840
> [ 8197.348396] R10: 00626b4810384abc R11: ffff9759efae01e8 R12: 0000000000000001
> [ 8197.348398] R13: ffffffff8d0ac638 R14: 0000000000000001 R15: 0000000000000000
> [ 8197.348402] ? cpuidle_enter_state+0x94/0x320
> [ 8197.348407] do_idle+0x1e4/0x220
> [ 8197.348411] cpu_startup_entry+0x5f/0x70
> [ 8197.348415] start_secondary+0x185/0x1a0
> [ 8197.348417] secondary_startup_64+0xa4/0xb0
^ permalink raw reply
* Re: [PATCH v2 00/17] octeontx2-af: NPC parser and NIX blocks initialization
From: Arnd Bergmann @ 2018-10-26 12:54 UTC (permalink / raw)
To: David Miller; +Cc: sunil.kovvuri, netdev, linux-soc, sgoutham
In-Reply-To: <20181022.201943.53165079906230990.davem@davemloft.net>
On 10/23/18, David Miller <davem@davemloft.net> wrote:
> From: sunil.kovvuri@gmail.com
> Date: Mon, 22 Oct 2018 23:25:47 +0530
>
>> From: Sunil Goutham <sgoutham@marvell.com>
>>
>> This patchset is a continuation to earlier submitted two patch
>> series to add a new driver for Marvell's OcteonTX2 SOC's
>> Resource virtualization unit (RVU) admin function driver.
>>
>> 1. octeontx2-af: Add RVU Admin Function driver
>> https://www.spinics.net/lists/netdev/msg528272.html
>> 2. octeontx2-af: NPA and NIX blocks initialization
>> https://www.spinics.net/lists/netdev/msg529163.html
>>
>> This patch series adds more NIX block configuration logic
>> and additionally adds NPC block parser profile configuration.
>> In brief below is what this series adds.
>> NIX block:
>> - Support for PF/VF to allocate/free transmit scheduler queues,
>> maintenance and their configuration.
>> - Adds support for packet replication lists, only broadcast
>> packets is covered for now.
>> - Defines few RSS flow algorithms for HW to distribute packets.
>> This is not the hash algorithsm (i.e toeplitz or crc32), here SW
>> defines what fields in packet should HW take and calculate the hash.
>> - Support for PF/VF to configure VTAG strip and capture capabilities.
>> - Reset NIXLF statastics.
>>
>> NPC block:
>> This block has multiple parser engines which support packet parsing
>> at multiple layers and generates a parse result which is further used
>> to generate a key. Based on packet field offsets in the key, SW can
>> install packet forwarding rules.
>> This patch series adds
>> - Initial parser profile to be programmed into parser engines.
>> - Default forwarding rules to forward packets to different logical
>> interfaces having a NIXLF attached.
>> - Support for promiscuous and multicast modes.
>>
>> Changes from v1:
>> 1 Fixed kernel build failure when compiled with BIG_ENDIAN enabled.
>> - Reported by Kbuild test robot
>> 2 Fixed a warning observed when kernel is built with
>> -Wunused-but-set-variable
>
> Series applied.
I see this has been applied, but I'd still like to understand better how the
configuration interface is expected to work once the driver is complete.
In particular, so far the interfaces all assume that configuration is
done through the mailbox between PCI devices, which could be done
from a virtual machine kernel with access to PCI, or through the use
of VFIO from a user application.
Is that the only method of configuring it that you support, or will there
also be a devlink based interface or something like that to configure
the aspects of a virtual device that should not be accessible to the
VF itself?
Arnd
^ permalink raw reply
* Re: Fw: [Bug 201423] New: eth0: hw csum failure
From: Eric Dumazet @ 2018-10-26 12:59 UTC (permalink / raw)
To: andre
Cc: Eric Dumazet, Stephen Hemminger, netdev, rossi.f,
Dimitris Michailidis
In-Reply-To: <bf33233e-67f1-a766-be08-19349d13a6e6@tomt.net>
On Fri, Oct 26, 2018 at 5:38 AM Andre Tomt <andre@tomt.net> wrote:
>
> On 26.10.2018 13:45, Andre Tomt wrote:
> > On 25.10.2018 19:38, Eric Dumazet wrote:
> >>
> >>
> >> On 10/24/2018 12:41 PM, Andre Tomt wrote:
> >>>
> >>> It eventually showed up again with mlx4, on 4.18.16 + fix and also on
> >>> 4.19. I still do not have a useful packet capture.
> >>>
> >>> It is running a torrent client serving up various linux distributions.
> >>>
> >>
> >> Have you also applied this fix ?
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=db4f1be3ca9b0ef7330763d07bf4ace83ad6f913
> >>
> >>
> >
> > No. I've applied it now to 4.19 and will report back if anything shows up.
>
> And it tripped again with that commit; however on another box with a
> much more complicated setup (VRFs, sch_cake, ifb, conntrack/nat, 6in4
> tunnel, VF device on mlx4)
>
> > [ 8197.348260] wanib: hw csum failure
> > [ 8197.348288] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.19.0-1 #1
> > [ 8197.348289] Hardware name: Supermicro SYS-5018D-FN8T/X10SDV-TP8F, BIOS 1.3 03/19/2018
> > [ 8197.348290] Call Trace:
> > [ 8197.348296] <IRQ>
> > [ 8197.348304] dump_stack+0x5c/0x80
> > [ 8197.348308] __skb_checksum_complete+0xac/0xc0
> > [ 8197.348318] icmp_error+0x1c8/0x1f0 [nf_conntrack]
> > [ 8197.348325] ? ip_output+0x61/0xc0
> > [ 8197.348328] ? skb_copy_bits+0x13d/0x220
> > [ 8197.348334] nf_conntrack_in+0xd8/0x390 [nf_conntrack]
> > [ 8197.348339] ? ___pskb_trim+0x192/0x330
> > [ 8197.348343] nf_hook_slow+0x43/0xc0
> > [ 8197.348346] ip_rcv+0x90/0xb0
> > [ 8197.348349] ? ip_rcv_finish_core.isra.0+0x310/0x310
> > [ 8197.348354] __netif_receive_skb_one_core+0x42/0x50
> > [ 8197.348357] netif_receive_skb_internal+0x24/0xb0
> > [ 8197.348361] ifb_ri_tasklet+0x167/0x260 [ifb]
> > [ 8197.348365] tasklet_action_common.isra.3+0x49/0xb0
> > [ 8197.348369] __do_softirq+0xe7/0x2d3
> > [ 8197.348372] irq_exit+0x96/0xd0
> > [ 8197.348375] do_IRQ+0x85/0xd0
> > [ 8197.348378] common_interrupt+0xf/0xf
> > [ 8197.348379] </IRQ>
> > [ 8197.348382] RIP: 0010:cpuidle_enter_state+0xb9/0x320
> > [ 8197.348384] Code: e8 1c 16 bc ff 80 7c 24 0b 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 3b 02 00 00 31 ff e8 3e fb c0 ff fb 66 0f 1f 44 00 00 <48> b8 ff ff ff ff f3 01 00 00 48 2b 1c 24 ba ff ff ff 7f 48 39 c3
> > [ 8197.348386] RSP: 0018:ffff9f0441953ea8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffd5
> > [ 8197.348388] RAX: ffff9759efae0fc0 RBX: 000007749807d911 RCX: 000000000000001f
> > [ 8197.348390] RDX: 000007749807d911 RSI: 000000003a2e8670 RDI: 0000000000000000
> > [ 8197.348393] RBP: ffff9759efae98a8 R08: 0000000000000002 R09: 0000000000020840
> > [ 8197.348396] R10: 00626b4810384abc R11: ffff9759efae01e8 R12: 0000000000000001
> > [ 8197.348398] R13: ffffffff8d0ac638 R14: 0000000000000001 R15: 0000000000000000
> > [ 8197.348402] ? cpuidle_enter_state+0x94/0x320
> > [ 8197.348407] do_idle+0x1e4/0x220
> > [ 8197.348411] cpu_startup_entry+0x5f/0x70
> > [ 8197.348415] start_secondary+0x185/0x1a0
> > [ 8197.348417] secondary_startup_64+0xa4/0xb0
Very different trace , yet another bug to track .
If you can, try to remove some components from this setup.
^ permalink raw reply
* [BPF] "padded" structures are not supported by BPF
From: Krishna Chaitanya @ 2018-10-26 13:06 UTC (permalink / raw)
To: netdev; +Cc: Alexei Starovoitov, Daniel Borkmann
Hi,
With below config BPF doesn't seem to support "padded" structures. Is
this a bug or expected?
Kernel Version: 4.15.0-34, Intel, Ubuntu. Below is the BPF JIT output.
struct info {
u16 seq_num;
u32 packet_num;
};
bpf: Failed to load program: Permission denied
0: (69) r1 = *(u16 *)(r1 +12)
1: (6b) *(u16 *)(r10 -8) = r1
2: (b7) r1 = 1000000
3: (63) *(u32 *)(r10 -4) = r1
4: (b7) r1 = 0
5: (63) *(u32 *)(r10 -12) = r1
6: (18) r1 = 0xffff8f86f2998e00
8: (bf) r2 = r10
9: (07) r2 += -12
10: (85) call bpf_map_lookup_elem#1
11: (bf) r6 = r0
12: (15) if r6 == 0x0 goto pc+13
R0=map_value(id=0,off=0,ks=4,vs=4,imm=0)
R6=map_value(id=0,off=0,ks=4,vs=4,imm=0) R10=fp0
13: (61) r1 = *(u32 *)(r6 +0)
R0=map_value(id=0,off=0,ks=4,vs=4,imm=0)
R6=map_value(id=0,off=0,ks=4,vs=4,imm=0) R10=fp0
14: (63) *(u32 *)(r10 -16) = r1
15: (18) r1 = 0xffff8f86f2999400
17: (bf) r2 = r10
18: (07) r2 += -16
19: (bf) r3 = r10
20: (07) r3 += -8
21: (b7) r4 = 0
22: (85) call bpf_map_update_elem#2
invalid indirect read from stack off -8+2 size 8
Traceback (most recent call last):
b = BPF(text=bpf_source)
File "/usr/lib/python2.7/dist-packages/bcc/__init__.py", line 337, in __init__
self._trace_autoload()
File "/usr/lib/python2.7/dist-packages/bcc/__init__.py", line 1038,
in _trace_autoload
fn = self.load_func(func_name, BPF.TRACEPOINT)
File "/usr/lib/python2.7/dist-packages/bcc/__init__.py", line 377,
in load_func
(func_name, errstr))
Exception: Failed to load BPF program tracepoint__<Snip>: Permission denied
If we add "__packed" to above struct is compiled successfully.
--
Thanks,
Regards,
Chaitanya T K.
^ permalink raw reply
* RE: [PATCH net-next v2 6/6] net/ncsi: Configure multi-package, multi-channel modes with failover
From: Justin.Lee1 @ 2018-10-26 21:48 UTC (permalink / raw)
To: sam, netdev; +Cc: davem, linux-kernel, openbmc
In-Reply-To: <20181023215201.27315-7-sam@mendozajonas.com>
Hi Samuel,
There is one place that we assume the next available TX channel is under the same package.
Please see the comment below.
Thanks,
Justin
+/* Change the active Tx channel in a multi-channel setup */
+int ncsi_update_tx_channel(struct ncsi_dev_priv *ndp,
> + struct ncsi_package *np,
> + struct ncsi_channel *disable,
> + struct ncsi_channel *enable)
> +{
> + struct ncsi_cmd_arg nca;
> + struct ncsi_channel *nc;
> + int ret = 0;
> +
> + if (!np->multi_channel)
> + netdev_warn(ndp->ndev.dev,
> + "NCSI: Trying to update Tx channel in single-channel mode\n");
> + nca.ndp = ndp;
> + nca.package = np->id;
If the channel may be on different package, the package ID here may not be correct
in some cases.
> + nca.req_flags = 0;
> +
> + /* Find current channel with Tx enabled */
> + if (!disable) {
> + NCSI_FOR_EACH_CHANNEL(np, nc)
> + if (nc->modes[NCSI_MODE_TX_ENABLE].enable)
> + disable = nc;
> + }
> +
> + /* Find a suitable channel for Tx */
> + if (!enable) {
> + if (np->preferred_channel &&
> + ncsi_channel_has_link(np->preferred_channel)) {
> + enable = np->preferred_channel;
> + } else {
> + NCSI_FOR_EACH_CHANNEL(np, nc) {
> + if (!(np->channel_whitelist & 0x1 << nc->id))
> + continue;
> + if (nc->state != NCSI_CHANNEL_ACTIVE)
> + continue;
> + if (ncsi_channel_has_link(nc)) {
> + enable = nc;
> + break;
> + }
> + }
When we search, we need to consider the other available channel might be on the
package.
> + }
> + }
> +
> + if (disable == enable)
> + return -1;
> +
> + if (!enable)
> + return -1;
> +
> + if (disable) {
> + nca.channel = disable->id;
> + nca.type = NCSI_PKT_CMD_DCNT;
> + ret = ncsi_xmit_cmd(&nca);
> + if (ret)
> + netdev_err(ndp->ndev.dev,
> + "Error %d sending DCNT\n",
> + ret);
> + }
I remove the cable from ncsi0 and it doesn't failover to ncsi3 as ncsi0 and ncsi3 are not under
the same package.
cat /sys/kernel/debug/ncsi_protocol/ncsi_device_
IFIDX IFNAME NAME PID CID RX TX MP MC WP WC PC CS PS LS RU CR NQ HA
======================================================================
2 eth2 ncsi0 000 000 1 1 1 1 1 1 1 3 0 0 1 1 0 1
2 eth2 ncsi1 000 001 0 0 1 1 1 0 0 1 0 1 1 1 0 1
2 eth2 ncsi2 001 000 0 0 1 1 1 0 0 1 0 1 1 1 0 1
2 eth2 ncsi3 001 001 1 0 1 1 1 1 0 2 1 1 1 1 0 1
======================================================================
MP: Multi-mode Package WP: Whitelist Package
MC: Multi-mode Channel WC: Whitelist Channel
PC: Primary Channel CS: Channel State
PS: Poll Status LS: Link Status
RU: Running CR: Carrier OK
NQ: Queue Stopped HA: Hardware Arbitration
^ permalink raw reply
* Re: [PATCH v3 2/2] net: qcom/emac: add phy-handle support for ACPI
From: Andrew Lunn @ 2018-10-26 13:13 UTC (permalink / raw)
To: Wang, Dongsheng
Cc: Timur Tabi, Zheng, Joey, f.fainelli@gmail.com,
netdev@vger.kernel.org, robert.moore@intel.com, rjw@rjwysocki.net,
linux-acpi@vger.kernel.org
In-Reply-To: <a1adfc5a696d40388ad9bf982f0ff64d@HXTBJIDCEMVIW02.hxtcorp.net>
On Fri, Oct 26, 2018 at 03:04:25AM +0000, Wang, Dongsheng wrote:
> On 2018/10/26 10:37, Timur Tabi wrote:
> > On 10/25/18 9:18 PM, Wang, Dongsheng wrote:
> >> But when I was reading Documentation/acpi/DSD-properties-rules.txt, my
> >> understanding is we should try to conform to DT bindings. So maybe ACPI
> >> doesn't have such a document, just DT bindings.
> > There was an attempt to document DSDs, but it was abandoned after a while.
> >
> > https://github.com/ahs3/dsd
> >
>
> Yes, here's a database concept, and I asked some Intel guys, the answer
> I got was there is no such database or document. :(
Hi Dongsheng
If there is no clear documentation for ACPI, it becomes even more
important that the xgene code is refactored into a central location,
and you make use of it. We really need to avoid every ACPI ethernet
driver doing its own thing.
Thanks
Andrew
^ permalink raw reply
* Re: Fw: [Bug 201423] New: eth0: hw csum failure
From: Andre Tomt @ 2018-10-26 13:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Dumazet, Stephen Hemminger, netdev, rossi.f,
Dimitris Michailidis
In-Reply-To: <CANn89iKHKa94DG=-PjwZx7V7zE_EYz5mraQ=VFJaA135pheHXQ@mail.gmail.com>
On 26.10.2018 14:59, Eric Dumazet wrote:
> On Fri, Oct 26, 2018 at 5:38 AM Andre Tomt <andre@tomt.net> wrote:
>> And it tripped again with that commit; however on another box with a
>> much more complicated setup (VRFs, sch_cake, ifb, conntrack/nat, 6in4
>> tunnel, VF device on mlx4)
>>
>>> [ 8197.348260] wanib: hw csum failure
>>> [ 8197.348288] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.19.0-1 #1
>>> [ 8197.348289] Hardware name: Supermicro SYS-5018D-FN8T/X10SDV-TP8F, BIOS 1.3 03/19/2018
>>> [ 8197.348290] Call Trace:
>>> [ 8197.348296] <IRQ>
>>> [ 8197.348304] dump_stack+0x5c/0x80
>>> [ 8197.348308] __skb_checksum_complete+0xac/0xc0
>>> [ 8197.348318] icmp_error+0x1c8/0x1f0 [nf_conntrack]
>>> [ 8197.348325] ? ip_output+0x61/0xc0
>>> [ 8197.348328] ? skb_copy_bits+0x13d/0x220
>>> [ 8197.348334] nf_conntrack_in+0xd8/0x390 [nf_conntrack]
>>> [ 8197.348339] ? ___pskb_trim+0x192/0x330
>>> [ 8197.348343] nf_hook_slow+0x43/0xc0
>>> [ 8197.348346] ip_rcv+0x90/0xb0
>>> [ 8197.348349] ? ip_rcv_finish_core.isra.0+0x310/0x310
>>> [ 8197.348354] __netif_receive_skb_one_core+0x42/0x50
>>> [ 8197.348357] netif_receive_skb_internal+0x24/0xb0
>>> [ 8197.348361] ifb_ri_tasklet+0x167/0x260 [ifb]
>>> [ 8197.348365] tasklet_action_common.isra.3+0x49/0xb0
>>> [ 8197.348369] __do_softirq+0xe7/0x2d3
>>> [ 8197.348372] irq_exit+0x96/0xd0
>>> [ 8197.348375] do_IRQ+0x85/0xd0
>>> [ 8197.348378] common_interrupt+0xf/0xf
>>> [ 8197.348379] </IRQ>
>>> [ 8197.348382] RIP: 0010:cpuidle_enter_state+0xb9/0x320
>>> [ 8197.348384] Code: e8 1c 16 bc ff 80 7c 24 0b 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 3b 02 00 00 31 ff e8 3e fb c0 ff fb 66 0f 1f 44 00 00 <48> b8 ff ff ff ff f3 01 00 00 48 2b 1c 24 ba ff ff ff 7f 48 39 c3
>>> [ 8197.348386] RSP: 0018:ffff9f0441953ea8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffd5
>>> [ 8197.348388] RAX: ffff9759efae0fc0 RBX: 000007749807d911 RCX: 000000000000001f
>>> [ 8197.348390] RDX: 000007749807d911 RSI: 000000003a2e8670 RDI: 0000000000000000
>>> [ 8197.348393] RBP: ffff9759efae98a8 R08: 0000000000000002 R09: 0000000000020840
>>> [ 8197.348396] R10: 00626b4810384abc R11: ffff9759efae01e8 R12: 0000000000000001
>>> [ 8197.348398] R13: ffffffff8d0ac638 R14: 0000000000000001 R15: 0000000000000000
>>> [ 8197.348402] ? cpuidle_enter_state+0x94/0x320
>>> [ 8197.348407] do_idle+0x1e4/0x220
>>> [ 8197.348411] cpu_startup_entry+0x5f/0x70
>>> [ 8197.348415] start_secondary+0x185/0x1a0
>>> [ 8197.348417] secondary_startup_64+0xa4/0xb0
>
>
> Very different trace , yet another bug to track .
>
> If you can, try to remove some components from this setup.
>
Will do. Just remembered I took out the VF stuff a few days ago and that
netdev is just a normal vlan device now. Going to eliminate VRF and
cake/ifb as well.
^ permalink raw reply
* Re: [PATCH v2 00/17] octeontx2-af: NPC parser and NIX blocks initialization
From: Sunil Kovvuri @ 2018-10-26 13:29 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Linux Netdev List, linux-soc, Sunil Goutham
In-Reply-To: <CAK8P3a1zpGZiKDrseHs0TVBy2435PD=D5L+29Zuag62=SGjnpg@mail.gmail.com>
On Fri, Oct 26, 2018 at 6:24 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On 10/23/18, David Miller <davem@davemloft.net> wrote:
> > From: sunil.kovvuri@gmail.com
> > Date: Mon, 22 Oct 2018 23:25:47 +0530
> >
> >> From: Sunil Goutham <sgoutham@marvell.com>
> >>
> >> This patchset is a continuation to earlier submitted two patch
> >> series to add a new driver for Marvell's OcteonTX2 SOC's
> >> Resource virtualization unit (RVU) admin function driver.
> >>
> >> 1. octeontx2-af: Add RVU Admin Function driver
> >> https://www.spinics.net/lists/netdev/msg528272.html
> >> 2. octeontx2-af: NPA and NIX blocks initialization
> >> https://www.spinics.net/lists/netdev/msg529163.html
> >>
> >> This patch series adds more NIX block configuration logic
> >> and additionally adds NPC block parser profile configuration.
> >> In brief below is what this series adds.
> >> NIX block:
> >> - Support for PF/VF to allocate/free transmit scheduler queues,
> >> maintenance and their configuration.
> >> - Adds support for packet replication lists, only broadcast
> >> packets is covered for now.
> >> - Defines few RSS flow algorithms for HW to distribute packets.
> >> This is not the hash algorithsm (i.e toeplitz or crc32), here SW
> >> defines what fields in packet should HW take and calculate the hash.
> >> - Support for PF/VF to configure VTAG strip and capture capabilities.
> >> - Reset NIXLF statastics.
> >>
> >> NPC block:
> >> This block has multiple parser engines which support packet parsing
> >> at multiple layers and generates a parse result which is further used
> >> to generate a key. Based on packet field offsets in the key, SW can
> >> install packet forwarding rules.
> >> This patch series adds
> >> - Initial parser profile to be programmed into parser engines.
> >> - Default forwarding rules to forward packets to different logical
> >> interfaces having a NIXLF attached.
> >> - Support for promiscuous and multicast modes.
> >>
> >> Changes from v1:
> >> 1 Fixed kernel build failure when compiled with BIG_ENDIAN enabled.
> >> - Reported by Kbuild test robot
> >> 2 Fixed a warning observed when kernel is built with
> >> -Wunused-but-set-variable
> >
> > Series applied.
>
> I see this has been applied, but I'd still like to understand better how the
> configuration interface is expected to work once the driver is complete.
>
> In particular, so far the interfaces all assume that configuration is
> done through the mailbox between PCI devices, which could be done
> from a virtual machine kernel with access to PCI, or through the use
> of VFIO from a user application.
>
> Is that the only method of configuring it that you support, or will there
> also be a devlink based interface or something like that to configure
> the aspects of a virtual device that should not be accessible to the
> VF itself?
>
> Arnd
As of now it's only mbox based configuration that is supported.
Thanks,
Sunil.
^ permalink raw reply
* Re: [PATCH net-next] net/ncsi: Add NCSI Mellanox OEM command
From: Vijay Khemka @ 2018-10-26 22:40 UTC (permalink / raw)
To: David Miller
Cc: sam@mendozajonas.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, openbmc@lists.ozlabs.org,
Justin.Lee1@Dell.com, joel@jms.id.au,
linux-aspeed@lists.ozlabs.org
In-Reply-To: <20181026.103617.373827980255084988.davem@davemloft.net>
Thanks David
On 10/26/18, 10:36 AM, "David Miller" <davem@davemloft.net> wrote:
From: Vijay Khemka <vijaykhemka@fb.com>
Date: Fri, 26 Oct 2018 17:19:49 +0000
> Do you have any timeline when it is going to open next or how do I
> know.
I always announce net-next openning and closing here on the list.
There is also a web site:
http://vger.kernel.org/~davem/net-next.html
Thanks.
^ permalink raw reply
* Re: [PATCH v2 00/17] octeontx2-af: NPC parser and NIX blocks initialization
From: Arnd Bergmann @ 2018-10-26 14:04 UTC (permalink / raw)
To: Sunil Kovvuri
Cc: David S. Miller, Linux Netdev List, linux-soc, Sunil Goutham
In-Reply-To: <CA+sq2CdNo4ooSSb3cwZrcbShpWto9uQQB=cfaMAeQqPUdgMv4Q@mail.gmail.com>
On 10/26/18, Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
> On Fri, Oct 26, 2018 at 6:24 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> I see this has been applied, but I'd still like to understand better how
>> the
>> configuration interface is expected to work once the driver is complete.
>>
>> In particular, so far the interfaces all assume that configuration is
>> done through the mailbox between PCI devices, which could be done
>> from a virtual machine kernel with access to PCI, or through the use
>> of VFIO from a user application.
>>
>> Is that the only method of configuring it that you support, or will there
>> also be a devlink based interface or something like that to configure
>> the aspects of a virtual device that should not be accessible to the
>> VF itself?
>>
>
>
> As of now it's only mbox based configuration that is supported.
Ok, thanks for the clarification.
Does this mean that you intend to have user space tools that use
the mbox based interface on VFIO devices to perform configuration
for virtual network devices, or just that the configuration interface
is something that needs to be designed later?
I fear that setting a precedent of using the mbox for user-level
configuration management would mean that we would have to
treat each of these interfaces as an ABI, which in turn requires
much deeper review as well as raising the fundamental question
on how this should be done across drivers. The mailbox interface
seem inherently nonportable to other hardware here, which is
a significant downside.
Arnd
^ permalink raw reply
* KMSAN: uninit-value in dev_mc_add_excl
From: syzbot @ 2018-10-26 22:48 UTC (permalink / raw)
To: davem, edumazet, linux-kernel, netdev, sunlw.fnst, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 4bb25354f0b0 kmsan: unpoison pt_regs in do_nmi()
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=11e4ae95400000
kernel config: https://syzkaller.appspot.com/x/.config?x=36c582b1a617b1e6
dashboard link: https://syzkaller.appspot.com/bug?extid=d53ab4e92a1db04110ff
compiler: clang version 8.0.0 (trunk 339414)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15ac7c79400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15dbbf0d400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+d53ab4e92a1db04110ff@syzkaller.appspotmail.com
sshd (6129) used greatest stack depth: 53504 bytes left
==================================================================
BUG: KMSAN: uninit-value in memcmp+0x117/0x180 lib/string.c:863
CPU: 1 PID: 6214 Comm: syz-executor693 Not tainted 4.19.0-rc8+ #70
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+0x306/0x460 lib/dump_stack.c:113
kmsan_report+0x1a2/0x2e0 mm/kmsan/kmsan.c:917
__msan_warning+0x7c/0xe0 mm/kmsan/kmsan_instr.c:500
memcmp+0x117/0x180 lib/string.c:863
dev_mc_add_excl+0x165/0x770 net/core/dev_addr_lists.c:648
ndo_dflt_fdb_add net/core/rtnetlink.c:3469 [inline]
rtnl_fdb_add+0xe83/0x12a0 net/core/rtnetlink.c:3562
rtnetlink_rcv_msg+0xa53/0x1590 net/core/rtnetlink.c:4730
netlink_rcv_skb+0x394/0x640 net/netlink/af_netlink.c:2454
rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4748
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x166d/0x1720 net/netlink/af_netlink.c:1343
netlink_sendmsg+0x1391/0x1420 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
___sys_sendmsg+0xe47/0x1200 net/socket.c:2116
__sys_sendmsg net/socket.c:2154 [inline]
__do_sys_sendmsg net/socket.c:2163 [inline]
__se_sys_sendmsg+0x307/0x460 net/socket.c:2161
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
do_syscall_64+0xbe/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x440fd9
Code: e8 cc ab 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 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 bb 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffe833197b8 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000440fd9
RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003
RBP: 0000000000000000 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 0000000000010c7d
R13: 0000000000401fb0 R14: 0000000000000000 R15: 0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:255 [inline]
kmsan_internal_poison_shadow+0xc8/0x1d0 mm/kmsan/kmsan.c:180
kmsan_kmalloc+0xa4/0x120 mm/kmsan/kmsan_hooks.c:104
kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan_hooks.c:113
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2727 [inline]
__kmalloc_node_track_caller+0xb43/0x1400 mm/slub.c:4360
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x422/0xe90 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:996 [inline]
netlink_alloc_large_skb net/netlink/af_netlink.c:1189 [inline]
netlink_sendmsg+0xcaf/0x1420 net/netlink/af_netlink.c:1883
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
___sys_sendmsg+0xe47/0x1200 net/socket.c:2116
__sys_sendmsg net/socket.c:2154 [inline]
__do_sys_sendmsg net/socket.c:2163 [inline]
__se_sys_sendmsg+0x307/0x460 net/socket.c:2161
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
do_syscall_64+0xbe/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
==================================================================
---
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: CAKE and r8169 cause panic on upload in v4.19
From: Dave Taht @ 2018-10-26 23:08 UTC (permalink / raw)
To: Oleksandr Natalenko
Cc: hkallweit1, Toke Høiland-Jørgensen, David S. Miller,
Jamal Hadi Salim, Cong Wang, Jiří Pírko,
Linux Kernel Network Developers, linux-kernel
In-Reply-To: <b80e6819da8ea74f18b6ec0aaf9128fa@natalenko.name>
On Fri, Oct 26, 2018 at 1:54 PM Oleksandr Natalenko
<oleksandr@natalenko.name> wrote:
>
> Hi.
>
> On 26.10.2018 22:25, Dave Taht wrote:
> > Can you repeat your test, disabling gro splitting in cake?
> >
> > the option is "no-split-gso"
>
> Still panics. Takes a couple of rounds, but panics.
>
> Moreover, I've stressed my HTB setup like this too for a longer time,
> and it panics as well. So, at least, now I have a proof this is not a
> CAKE-specific thing.
Groovy. :whew:
I do look forward to more cake test results, particularly on different
network cards such as these, and at speeds higher than 10Gbit on high
end hardware, and in the 100-1Gbit range on low to mid-range. After
the last round of features added to cake before it went into linux, we
run now out of cpu on inbound shaping at those speeds on low end apu2
(x86) hardware, (atom and a15 chips are not so hot now either) and I
wish I knew what we could do to speed it up. The new "list skb" and
mirred code looked promising but we haven't got around to exploring it
yet.
Thank you for trying and I hope this gets sorted out on your chipset.
>
> Also, I've stressed it even with noqueue, and the panic is still there.
> So, this thing is not even sch-specific.
>
> Next, I've seen GRO bits in the call trace and decided to disable GRO on
> this NIC. So far, I cannot trigger a panic with GRO disabled even after
> 20 rounds of speedtest.
We tend to use flent's rrul test to *really* abuse things. :)
So cake's ok with gro disabled in hw?
>
> So, must be some generic thing indeed.
>
> --
> Oleksandr Natalenko (post-factum)
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2018-10-26 23:12 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
What better way to start off a weekend than with some networking
bug fixes:
1) net namespace leak in dump filtering code of ipv4 and ipv6, fixed
by David Ahern and Bjørn Mork.
2) Handle bad checksums from hardware when using CHECKSUM_COMPLETE
properly in UDP, from Sean Tranchetti.
3) Remove TCA_OPTIONS from policy validation, it turns out we don't
consistently use nested attributes for this across all packet
schedulers. From David Ahern.
4) Fix SKB corruption in cadence driver, from Tristram Ha.
5) Fix broken WoL handling in r8169 driver, from Heiner Kallweit.
6) Fix OOPS in pneigh_dump_table(), from Eric Dumazet.
Please pull, thanks!
The following changes since commit 01aa9d518eae8a4d75cd3049defc6ed0b6d0a658:
Merge tag 'docs-4.20' of git://git.lwn.net/linux (2018-10-24 18:01:11 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to aab456dfa404f3a16d6f1780e62a6a8533c4d008:
net/neigh: fix NULL deref in pneigh_dump_table() (2018-10-26 16:03:51 -0700)
----------------------------------------------------------------
Andrew Lunn (1):
net: phy: genphy_10g_driver: Avoid NULL pointer dereference
Anirudh Venkataramanan (7):
ice: Make ice_msix_clean_rings static
ice: Change device ID define names to align with branding string
ice: Update expected FW version
ice: Use capability count returned by the firmware
ice: Introduce ice_dev_onetime_setup
ice: Allocate VF interrupts and set queue map
ice: Poll for link status change
Bjørn Mork (1):
net/{ipv4,ipv6}: Do not put target net if input nsid is invalid
Bryan Whitehead (1):
lan743x: Remove SPI dependency from Microchip group.
Dan Carpenter (1):
octeontx2-af: Copy the right amount of memory
David Ahern (6):
net/ipv4: Put target net when address dump fails due to bad attributes
net/ipv6: Put target net when address dump fails due to bad attributes
net: Don't return invalid table id error when dumping all families
net: rtnl_dump_all needs to propagate error from dumpit function
net: sched: Remove TCA_OPTIONS from policy
net/ipv6: Allow onlink routes to have a device mismatch if it is the default route
David S. Miller (2):
Merge branch 'route-dump-filter-fixes'
Merge branch '100GbE' of git://git.kernel.org/.../jkirsher/net-queue
Eric Dumazet (2):
drivers: net: remove <net/busy_poll.h> inclusion when not needed
net/neigh: fix NULL deref in pneigh_dump_table()
Hangbin Liu (1):
bridge: do not add port to router list when receives query with source 0.0.0.0
Heiner Kallweit (1):
r8169: fix broken Wake-on-LAN from S5 (poweroff)
Karsten Graul (1):
net/smc: fix smc_buf_unuse to use the lgr pointer
Mike Manning (1):
net: allow traceroute with a specified interface in a vrf
Sean Tranchetti (1):
net: udp: fix handling of CHECKSUM_COMPLETE packets
Shiju Jose (1):
net: hns3: Fix for warning uninitialized symbol hw_err_lst3
Stefano Brivio (1):
ipv6/ndisc: Preserve IPv6 control buffer if protocol error handlers are called
Tristram Ha (1):
net: ethernet: cadence: fix socket buffer corruption problem
Wei Yongjun (1):
octeontx2-af: Use GFP_ATOMIC under spin lock
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 1 -
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 -
drivers/net/ethernet/cadence/macb_main.c | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 10 +++++----
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 1 -
drivers/net/ethernet/intel/iavf/iavf_txrx.c | 1 -
drivers/net/ethernet/intel/ice/ice_common.c | 52 +++++++++++++++++++--------------------------
drivers/net/ethernet/intel/ice/ice_common.h | 9 +++-----
drivers/net/ethernet/intel/ice/ice_controlq.h | 5 ++---
drivers/net/ethernet/intel/ice/ice_devids.h | 6 +++---
drivers/net/ethernet/intel/ice/ice_hw_autogen.h | 8 +++++++
drivers/net/ethernet/intel/ice/ice_lib.c | 3 ++-
drivers/net/ethernet/intel/ice/ice_lib.h | 1 -
drivers/net/ethernet/intel/ice/ice_main.c | 116 ++++++++++++++++++++++++-----------------------------------------------------------------------------
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 15 +++++++++----
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 -
drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c | 4 ++--
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 1 -
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 1 -
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 1 -
drivers/net/ethernet/microchip/Kconfig | 1 -
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 1 -
drivers/net/ethernet/realtek/r8169.c | 9 ++++++--
drivers/net/phy/phy-c45.c | 2 +-
include/net/ip_fib.h | 1 +
net/bridge/br_multicast.c | 10 ++++++++-
net/core/datagram.c | 5 +++--
net/core/neighbour.c | 4 ++--
net/core/rtnetlink.c | 6 ++++--
net/ipv4/devinet.c | 14 ++++++++-----
net/ipv4/fib_frontend.c | 4 ++++
net/ipv4/ipmr.c | 3 +++
net/ipv4/udp.c | 24 +++++++++++++++++----
net/ipv6/addrconf.c | 15 +++++++------
net/ipv6/ip6_checksum.c | 20 ++++++++++++++++--
net/ipv6/ip6_fib.c | 3 +++
net/ipv6/ip6mr.c | 3 +++
net/ipv6/ndisc.c | 3 +--
net/ipv6/route.c | 2 ++
net/ipv6/udp.c | 2 +-
net/sched/sch_api.c | 1 -
net/smc/smc_core.c | 25 +++++++++++-----------
tools/testing/selftests/net/fib-onlink-tests.sh | 14 ++++++-------
43 files changed, 205 insertions(+), 206 deletions(-)
^ 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