* Re: [PATCH 1/1] net: dsa: b53: Disable all ports on setup
From: Florian Fainelli @ 2019-06-28 17:23 UTC (permalink / raw)
To: Benedikt Spranger
Cc: netdev, Sebastian Andrzej Siewior, Kurt Kanzenbach, Andrew Lunn,
Vivien Didelot
In-Reply-To: <20190628165811.30964-2-b.spranger@linutronix.de>
On 6/28/19 9:58 AM, Benedikt Spranger wrote:
> A b53 device may configured through an external EEPROM like the switch
> device on the Lamobo R1 router board. The configuration of a port may
> therefore differ from the reset configuration of the switch.
>
> The switch configuration reported by the DSA subsystem is different until
> the port is configured by DSA i.e. a port can be active, while the DSA
> subsystem reports the port is inactive. Disable all ports and not only
> the unused ones to put all ports into a well defined state.
>
> Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Makes sense, in fact, that should probably be moved to the DSA core at
some point (wink wink Vivien).
--
Florian
^ permalink raw reply
* Re: [PATCH 1/3, net-next] net: netsec: Use page_pool API
From: Ilias Apalodimas @ 2019-06-28 17:19 UTC (permalink / raw)
To: David Miller
Cc: brouer, netdev, jaswinder.singh, ard.biesheuvel, bjorn.topel,
magnus.karlsson, daniel, ast, makita.toshiaki, jakub.kicinski,
john.fastabend, maciejromanfijalkowski
In-Reply-To: <20190628.094343.1065314747200152509.davem@davemloft.net>
Hi David,
> >> Use page_pool and it's DMA mapping capabilities for Rx buffers instead
> >> of netdev/napi_alloc_frag()
> >>
> >> Although this will result in a slight performance penalty on small sized
> >> packets (~10%) the use of the API will allow to easily add XDP support.
> >> The penalty won't be visible in network testing i.e ipef/netperf etc, it
> >> only happens during raw packet drops.
> >> Furthermore we intend to add recycling capabilities on the API
> >> in the future. Once the recycling is added the performance penalty will
> >> go away.
> >> The only 'real' penalty is the slightly increased memory usage, since we
> >> now allocate a page per packet instead of the amount of bytes we need +
> >> skb metadata (difference is roughly 2kb per packet).
> >> With a minimum of 4BG of RAM on the only SoC that has this NIC the
> >> extra memory usage is negligible (a bit more on 64K pages)
> >>
> >> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> >> ---
> >> drivers/net/ethernet/socionext/Kconfig | 1 +
> >> drivers/net/ethernet/socionext/netsec.c | 121 +++++++++++++++---------
> >> 2 files changed, 75 insertions(+), 47 deletions(-)
> >
> > Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
>
> Jesper this is confusing, you just asked if the code needs to be moved
> around to be correct and then right now immediately afterwards you ACK
> the patch.
I can answer on the driver, page_pool_free() needs re-arranging indeed.
I'll fix it and post a V2. I guess Jesper meant 'acked-if-fixed' so i can it on
V2
Thanks
/Ilias
^ permalink raw reply
* [PATCH 1/1] net: dsa: b53: Disable all ports on setup
From: Benedikt Spranger @ 2019-06-28 16:58 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, Sebastian Andrzej Siewior, Kurt Kanzenbach, Andrew Lunn,
Vivien Didelot
In-Reply-To: <20190628165811.30964-1-b.spranger@linutronix.de>
A b53 device may configured through an external EEPROM like the switch
device on the Lamobo R1 router board. The configuration of a port may
therefore differ from the reset configuration of the switch.
The switch configuration reported by the DSA subsystem is different until
the port is configured by DSA i.e. a port can be active, while the DSA
subsystem reports the port is inactive. Disable all ports and not only
the unused ones to put all ports into a well defined state.
Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
---
drivers/net/dsa/b53/b53_common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index a47f5bc667bd..5127c2fefba9 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -962,13 +962,13 @@ static int b53_setup(struct dsa_switch *ds)
if (ret)
dev_err(ds->dev, "failed to apply configuration\n");
- /* Configure IMP/CPU port, disable unused ports. Enabled
+ /* Configure IMP/CPU port, disable all other ports. Enabled
* ports will be configured with .port_enable
*/
for (port = 0; port < dev->num_ports; port++) {
if (dsa_is_cpu_port(ds, port))
b53_enable_cpu_port(dev, port);
- else if (dsa_is_unused_port(ds, port))
+ else
b53_disable_port(ds, port);
}
--
2.20.1
^ permalink raw reply related
* [PATCH 0/1] Disable all ports on b53 setup
From: Benedikt Spranger @ 2019-06-28 16:58 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, Sebastian Andrzej Siewior, Kurt Kanzenbach, Andrew Lunn,
Vivien Didelot
Hi,
while working on a Banana Pi R1 based system I faced inconsistent
switch configurations. The switch is attached to an EEPROM which feeds
additional configuration which is applied after the reset of the chip.
As a result all ports remained active while the DSA subsystem
assumed that those ports were inactive after the reset.
Disable the ports on switch setup to get a consistent view of things
between real life and DSA.
Benedikt Spranger (1):
net: dsa: b53: Disable all ports on setup
drivers/net/dsa/b53/b53_common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [RFC iproute2 1/1] ip: netns: add mounted state file for each netns
From: Matteo Croce @ 2019-06-28 17:06 UTC (permalink / raw)
To: David Howells
Cc: Nicolas Dichtel, Alexander Aring, netdev, linux-fsdevel, kernel
In-Reply-To: <18557.1561739215@warthog.procyon.org.uk>
On Fri, Jun 28, 2019 at 6:27 PM David Howells <dhowells@redhat.com> wrote:
>
> Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>
> > David Howells was working on a mount notification mechanism:
> > https://lwn.net/Articles/760714/
> > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=notifications
> >
> > I don't know what is the status of this series.
>
> It's still alive. I just posted a new version on it. I'm hoping, possibly
> futiley, to get it in in this merge window.
>
> David
Hi all,
this could cause a clash if I create a netns with name ending with .mounted.
$ sudo ip/ip netns add ns1.mounted
$ sudo ip/ip netns add ns1
Cannot create namespace file "/var/run/netns/ns1.mounted": File exists
Cannot remove namespace file "/var/run/netns/ns1.mounted": Device or
resource busy
If you want to go along this road, please either:
- disallow netns creation with names ending with .mounted
- or properly document it in the manpage
Regards,
--
Matteo Croce
per aspera ad upstream
^ permalink raw reply
* Re: [RFC PATCH 1/1] Documentation: net: dsa: b53: Describe b53 configuration
From: Benedikt Spranger @ 2019-06-28 16:57 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, Sebastian Andrzej Siewior, Kurt Kanzenbach, Andrew Lunn,
Vivien Didelot
In-Reply-To: <5fe6c1b8-6273-be3d-cf75-6efdd7f9b27d@gmail.com>
Am Thu, 27 Jun 2019 09:38:16 -0700
schrieb Florian Fainelli <f.fainelli@gmail.com>:
> On 6/27/19 3:15 AM, Benedikt Spranger wrote:
> > Document the different needs of documentation for the b53 driver.
> >
> > Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
> > ---
> > Documentation/networking/dsa/b53.rst | 300
> > +++++++++++++++++++++++++++ 1 file changed, 300 insertions(+)
> > create mode 100644 Documentation/networking/dsa/b53.rst
> >
> > diff --git a/Documentation/networking/dsa/b53.rst
> > b/Documentation/networking/dsa/b53.rst new file mode 100644
> > index 000000000000..5838cf6230da
> > --- /dev/null
> > +++ b/Documentation/networking/dsa/b53.rst
> > @@ -0,0 +1,300 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +==========================================
> > +Broadcom RoboSwitch Ethernet switch driver
> > +==========================================
> > +
> > +The Broadcom RoboSwitch Ethernet switch family is used in quite a
> > range of +xDSL router, cable modems and other multimedia devices.
> > +
> > +The actual implementation supports the devices BCM5325E, BCM5365,
> > BCM539x, +BCM53115 and BCM53125 as well as BCM63XX.
> > +
> > +Implementation details
> > +======================
> > +
> > +The driver is located in ``drivers/net/dsa/bcm_sf2.c`` and is
> > implemented as a +DSA driver; see
> > ``Documentation/networking/dsa/dsa.rst`` for details on the
> > +subsystemand what it provides.
>
> The driver is under drivers/net/dsa/b53/
Fixed.
> s/ethernet/Ethernet/ for your global submission.
OK.
> What you are describing is not entirely specific to the B53 driver
> (maybe with the exception of having a VLAN tag on the DSA master
> network device, since B53 puts the CPU port tagged in all VLANs by
> default), and therefore the entire document should be written with
> the general DSA devices in mind, and eventually pointing out where
> B53 differs in a separate document.
I have split up the Documentation into
Documentation/networking/dsa/configuration.rst
and
Documentation/networking/dsa/b53.rst
> There are largely two kinds of behavior:
>
> - switches that are configured with DSA_TAG_PROTO_NONE, which behave
> in a certain way and require a bridge with VLAN filtering even when
> ports are intended to be used as standalone devices.
>
> - switches that are configured with a tagging protocol other than
> DSA_TAG_PROTO_NONE, which behave more like traditional network devices
> people are used to use.
OK.
> > +bridge
> > +~~~~~~
>
> I would add something like:
>
> All ports being part of a single bridge/broadcast domain or something
> along those lines. Seeing the "wan" interface being added to a bridge
> is a bit confusing.
> > +
> > +.. code-block:: sh
> > +
> > + # create bridge
> > + ip link add name br0 type bridge
> > +
> > + # add ports to bridge
> > + ip link set dev wan master br0
> > + ip link set dev lan1 master br0
> > + ip link set dev lan2 master br0
> > +
> > + # configure the bridge
> > + ip addr add 192.0.2.129/25 dev br0
> > +
> > + # The master interface needs to be brought up before the slave
> > ports.
> > + ip link set eth0 up
> > +
> > + # bring up the slave interfaces
> > + ip link set wan up
> > + ip link set lan1 up
> > + ip link set lan2 up
> > +
> > + # bring up the bridge
> > + ip link set dev br0 up
> > +
> > +gateway
> > +~~~~~~~
> > +
> > +.. code-block:: sh
> > +
> > + # create bridge
> > + ip link add name br0 type bridge
> > +
> > + # add ports to bridge
> > + ip link set dev lan1 master br0
> > + ip link set dev lan2 master br0
> > +
> > + # configure the bridge
> > + ip addr add 192.0.2.129/25 dev br0
> > +
> > + # configure the upstream port
> > + ip addr add 192.0.2.1/30 dev wan
> > +
> > + # The master interface needs to be brought up before the slave
> > ports.
> > + ip link set eth0 up
> > +
> > + # bring up the slave interfaces
> > + ip link set wan up
> > + ip link set lan1 up
> > + ip link set lan2 up
> > +
> > + # bring up the bridge
> > + ip link set dev br0 up
> > +
> > +Configuration without tagging support
> > +-------------------------------------
> > +
> > +Older models (5325, 5365) support a different tag format that is
> > not supported +yet. 539x and 531x5 require managed mode and some
> > special handling, which is +also not yet supported. The tagging
> > support is disabled in these cases and the +switch need a different
> > configuration.
>
> On that topic, did the patch I sent you ended up working the way you
> wanted it with ifupdown-scripts or are you still chasing some other
> issues with it?
Your patch is needed and working. Stumbled over my own feed.
I have a hackary solution by now. Hackary in terms of not tracking the
master interface state (just *up* it unconditionally).
> > +
> > +single port
> > +~~~~~~~~~~~
> > +The configuration can only be set up via VLAN tagging and bridge
> > setup. +By default packages are tagged with vid 1:
> > +
> > +.. code-block:: sh
> > +
> > + # tag traffic on CPU port
> > + ip link add link eth0 name eth0.1 type vlan id 1
> > + ip link add link eth0 name eth0.2 type vlan id 2
> > + ip link add link eth0 name eth0.3 type vlan id 3
>
> That part is indeed a B53 implementation specific detail because B53
> tags the CPU port in all VLANs, since otherwise any PVID untagged VLAN
> programming would basically change the CPU port's default PVID and
> make it untagged, undesirable.
OK.
> > +
> > + # create bridges
> > + ip link add name br0 type bridge
> > + ip link add name br1 type bridge
> > + ip link add name br2 type bridge
> > +
> > + # activate VLAN filtering
> > + ip link set dev br0 type bridge vlan_filtering 1
> > + ip link set dev br1 type bridge vlan_filtering 1
> > + ip link set dev br2 type bridge vlan_filtering 1
> > +
> > + # add ports to bridges
> > + ip link set dev wan master br0
> > + ip link set eth0.1 master br0
> > + ip link set dev lan1 master br1
> > + ip link set eth0.2 master br1
> > + ip link set dev lan2 master br2
> > + ip link set eth0.3 master br2
>
> I don't think you need one bridge for each port you want to isolate
> with DSA_PROTO_TAG_NONE, you can just have a single bridge and assign
> the ports a different VLAN with the commands below:
Tried that out:
# tag traffic on CPU port
ip link add link eth0 name eth0.1 type vlan id 1
ip link add link eth0 name eth0.2 type vlan id 2
ip link add link eth0 name eth0.3 type vlan id 3
# The master interface needs to be brought up before the slave ports.
ip link set eth0 up
ip link set eth0.1 up
ip link set eth0.2 up
ip link set eth0.3 up
# bring up the slave interfaces
ip link set wan up
ip link set lan1 up
ip link set lan2 up
# create bridge
ip link add name br0 type bridge
# activate VLAN filtering
ip link set dev br0 type bridge vlan_filtering 1
# add ports to bridges
ip link set dev wan master br0
ip link set dev lan1 master br0
ip link set dev lan2 master br0
# tag traffic on ports
bridge vlan add dev lan1 vid 2 pvid untagged
bridge vlan del dev lan1 vid 1
bridge vlan add dev lan2 vid 3 pvid untagged
bridge vlan del dev lan2 vid 1
# configure the VLANs
ip addr add 192.0.2.1/30 dev eth0.1
ip addr add 192.0.2.5/30 dev eth0.2
ip addr add 192.0.2.9/30 dev eth0.3
# bring up the bridge devices
ip link set br0 up
Works quite well :)
> > +
> > + # tag traffic on ports
> > + bridge vlan add dev lan1 vid 2 pvid untagged
> > + bridge vlan del dev lan1 vid 1
> > + bridge vlan add dev lan2 vid 3 pvid untagged
> > + bridge vlan del dev lan2 vid 1
>
> And also permit the different VLANs that you created on the bridge
> master device itself:
>
> bridge vlan add vid 2 dev br0 self
> bridve vlan add vid 3 dev br0 self
>
> Maybe that last part above ^^ was missing and that's why people tend
> to create multiple bridge devices?
From my side there was some tree in the woods problem...
> > +
> > + # configure the bridges
> > + ip addr add 192.0.2.1/30 dev br0
> > + ip addr add 192.0.2.5/30 dev br1
> > + ip addr add 192.0.2.9/30 dev br2
> > +
> > + # The master interface needs to be brought up before the slave
> > ports.
> > + ip link set eth0 up
> > + ip link set eth0.1 up
> > + ip link set eth0.2 up
> > + ip link set eth0.3 up
> > +
> > + # bring up the slave interfaces
> > + ip link set wan up
> > + ip link set lan1 up
> > + ip link set lan2 up
> > +
> > + # bring up the bridge devices
> > + ip link set br0 up
> > + ip link set br1 up
> > + ip link set br2 up
> > +
> > +bridge
> > +~~~~~~
> > +
> > +.. code-block:: sh
> > +
> > + # tag traffic on CPU port
> > + ip link add link eth0 name eth0.1 type vlan id 1
> > +
> > + # create bridge
> > + ip link add name br0 type bridge
> > +
> > + # activate VLAN filtering
> > + ip link set dev br0 type bridge vlan_filtering 1
> > +
> > + # add ports to bridge
> > + ip link set dev wan master br0
> > + ip link set dev lan1 master br0
> > + ip link set dev lan2 master br0
> > + ip link set eth0.1 master br0
> > +
> > + # configure the bridge
> > + ip addr add 192.0.2.129/25 dev br0
> > +
> > + # The master interface needs to be brought up before the slave
> > ports.
> > + ip link set eth0 up
> > + ip link set eth0.1 up
> > +
> > + # bring up the slave interfaces
> > + ip link set wan up
> > + ip link set lan1 up
> > + ip link set lan2 up
> > +
> > + # bring up the bridge
> > + ip link set dev br0 up
> > +
> > +gateway
> > +~~~~~~~
> > +
> > +.. code-block:: sh
> > +
> > + # tag traffic on CPU port
> > + ip link add link eth0 name eth0.1 type vlan id 1
> > + ip link add link eth0 name eth0.2 type vlan id 2
> > +
> > + # create bridges
> > + ip link add name br0 type bridge
> > + ip link add name br1 type bridge
>
> Likewise, I have seen claims of people telling me they used two bridge
> devices, but AFAICT this is only because the bridge master did not
> have VID 2 programmed to it, so if you did the following:
>
> bridge vlan add vid 2 dev br0 self
I tried the following:
# tag traffic on CPU port
ip link add link eth0 name eth0.1 type vlan id 1
ip link add link eth0 name eth0.2 type vlan id 2
# The master interface needs to be brought up before the slave ports.
ip link set eth0 up
ip link set eth0.1 up
ip link set eth0.2 up
# bring up the slave interfaces
ip link set wan up
ip link set lan1 up
ip link set lan2 up
# create bridge
ip link add name br0 type bridge
# activate VLAN filtering
ip link set dev br0 type bridge vlan_filtering 1
# add ports to bridges
ip link set dev wan master br0
ip link set eth0.1 master br0
ip link set dev lan1 master br0
ip link set dev lan2 master br0
# tag traffic on ports
bridge vlan add dev wan vid 2 pvid untagged
bridge vlan del dev wan vid 1
# configure the VLANs
ip addr add 192.0.2.1/30 dev eth0.2
ip addr add 192.0.2.129/25 dev br0
# bring up the bridge devices
ip link set br0 up
Maybe I got it fundamently wrong:
I try to seperate the traffic. If i bound everything to the bridge the
separation will not work out. To split it up like above on the other
hand makes it very clear (at least for me).
I have separate interfaces (here br0 and eth0.2) for the different
networks.
But I am open and grateful for any help and suggestions in that area.
> you should be able to get away with a single bridge master device, can
> you try that?
Done. See above. Works!
> Overall this is fills a lot of gaps and questions that were being
> asked on the lamobo R1 threads on various forums, thanks a lot for
> doing that!
Thx.
Regards
Bene Spranger
^ permalink raw reply
* Re: [PATCH v4] net: netfilter: Fix rpfilter dropping vrf packets by mistake
From: David Ahern @ 2019-06-28 17:04 UTC (permalink / raw)
To: Miaohe Lin, pablo, kadlec, fw, davem, kuznet, yoshfuji,
netfilter-devel, coreteam, netdev, linux-kernel
Cc: mingfangsen
In-Reply-To: <1561712803-195184-1-git-send-email-linmiaohe@huawei.com>
On 6/28/19 3:06 AM, Miaohe Lin wrote:
> diff --git a/net/ipv6/netfilter/ip6t_rpfilter.c b/net/ipv6/netfilter/ip6t_rpfilter.c
> index 6bcaf7357183..3c4a1772c15f 100644
> --- a/net/ipv6/netfilter/ip6t_rpfilter.c
> +++ b/net/ipv6/netfilter/ip6t_rpfilter.c
> @@ -55,6 +55,10 @@ static bool rpfilter_lookup_reverse6(struct net *net, const struct sk_buff *skb,
> if (rpfilter_addr_linklocal(&iph->saddr)) {
> lookup_flags |= RT6_LOOKUP_F_IFACE;
> fl6.flowi6_oif = dev->ifindex;
> + /* Set flowi6_oif for vrf devices to lookup route in l3mdev domain. */
> + } else if (netif_is_l3_master(dev) || netif_is_l3_slave(dev)) {
> + lookup_flags |= FLOWI_FLAG_SKIP_NH_OIF;
you don't need to set that flag here. It is done by the fib_rules code
as needed.
^ permalink raw reply
* Re: [PATCH 00/10] pull request for net-next: batman-adv 2019-06-27 v2
From: Sven Eckelmann @ 2019-06-28 17:01 UTC (permalink / raw)
To: b.a.t.m.a.n; +Cc: David Miller, sw, netdev, Linus Lüssing
In-Reply-To: <20190628.094905.1673194288384587104.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 802 bytes --]
On Friday, 28 June 2019 18:49:05 CEST David Miller wrote:
[...]
> I think that when you have the read_lock held, RCU is not necessary in order
> to use __in6_dev_get() but I may be mistaken. Just FYI...
Problem is that the read_lock() can only be used after the __in6_dev_get()
finished sucessfully. Because the read_lock's lock is stored in the inet6_dev
object which was retrieved via __in6_dev_get. And the __in6_dev_get kerneldoc
states [1] that you either have to hold RTNL or RCU (see also the
rcu_dereference_rtnl call inside this function).
So we can only drop the rcu_read_lock when RTNL lock is held . I would guess
now that this is not the case here - Linus' might want to correct me.
Kind regards,
Sven
[1] https://lxr.missinglinkelectronics.com/linux/include/net/addrconf.h#L335
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 00/11] XDP unaligned chunk placement support
From: Björn Töpel @ 2019-06-28 16:51 UTC (permalink / raw)
To: Laatz, Kevin, Jakub Kicinski
Cc: Jonathan Lemon, netdev, ast, daniel, magnus.karlsson, bpf,
intel-wired-lan, bruce.richardson, ciara.loftus
In-Reply-To: <f0ca817a-02b4-df22-d01b-7bc07171a4dc@intel.com>
On 2019-06-28 18:19, Laatz, Kevin wrote:
> On 27/06/2019 22:25, Jakub Kicinski wrote:
>> On Thu, 27 Jun 2019 12:14:50 +0100, Laatz, Kevin wrote:
>>> On the application side (xdpsock), we don't have to worry about the user
>>> defined headroom, since it is 0, so we only need to account for the
>>> XDP_PACKET_HEADROOM when computing the original address (in the default
>>> scenario).
>> That assumes specific layout for the data inside the buffer. Some NICs
>> will prepend information like timestamp to the packet, meaning the
>> packet would start at offset XDP_PACKET_HEADROOM + metadata len..
>
> Yes, if NICs prepend extra data to the packet that would be a problem for
> using this feature in isolation. However, if we also add in support for
> in-order
> RX and TX rings, that would no longer be an issue. However, even for NICs
> which do prepend data, this patchset should not break anything that is
> currently
> working.
(Late on the ball. I'm in vacation mode.)
In your example Jakub, how would this look in XDP? Wouldn't the
timestamp be part of the metadata (xdp_md.data_meta)? Isn't
data-data_meta (if valid) <= XDP_PACKET_HEADROOM? That was my assumption.
There were some discussion on having meta data length in the struct
xdp_desc, before AF_XDP was merged, but the conclusion was that this was
*not* needed, because AF_XDP and the XDP program had an implicit
contract. If you're running AF_XDP, you also have an XDP program running
and you can determine the meta data length (and also getting back the
original buffer).
So, today in AF_XDP if XDP metadata is added, the userland application
can look it up before the xdp_desc.addr (just like regular XDP), and how
the XDP/AF_XDP application determines length/layout of the metadata i
out-of-band/not specified.
This is a bit messy/handwavy TBH, so maybe adding the length to the
descriptor *is* a good idea (extending the options part of the
xdp_desc)? Less clean though. OTOH the layout of the meta data still
need to be determined.
Björn
^ permalink raw reply
* Re: [PATCH v3 bpf-next 3/9] libbpf: add ability to attach/detach BPF program to perf event
From: Andrii Nakryiko @ 2019-06-28 16:50 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann, Networking,
bpf, Kernel Team
In-Reply-To: <20190628160436.GH4866@mini-arch>
On Fri, Jun 28, 2019 at 9:04 AM Stanislav Fomichev <sdf@fomichev.me> wrote:
>
> On 06/27, Andrii Nakryiko wrote:
> > bpf_program__attach_perf_event allows to attach BPF program to existing
> > perf event hook, providing most generic and most low-level way to attach BPF
> > programs. It returns struct bpf_link, which should be passed to
> > bpf_link__destroy to detach and free resources, associated with a link.
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > tools/lib/bpf/libbpf.c | 58 ++++++++++++++++++++++++++++++++++++++++
> > tools/lib/bpf/libbpf.h | 3 +++
> > tools/lib/bpf/libbpf.map | 1 +
> > 3 files changed, 62 insertions(+)
> >
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index 455795e6f8af..606705f878ba 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -32,6 +32,7 @@
> > #include <linux/limits.h>
> > #include <linux/perf_event.h>
> > #include <linux/ring_buffer.h>
> > +#include <sys/ioctl.h>
> > #include <sys/stat.h>
> > #include <sys/types.h>
> > #include <sys/vfs.h>
> > @@ -3958,6 +3959,63 @@ int bpf_link__destroy(struct bpf_link *link)
> > return err;
> > }
> >
> > +struct bpf_link_fd {
> > + struct bpf_link link; /* has to be at the top of struct */
> [..]
> > + int fd; /* hook FD */
> > +};
> Any cons to storing everything in bpf_link, instead of creating a
> "subclass"? Less things to worry about.
Yes, it's not always enough to just have single FD to detach BPF
program. Check bpf_prog_detach and bpf_prog_detach2 in
tools/lib/bpf/bpf.c. For some types of attachment you have to provide
target_fd+attach_type, for some target_fd+attach_type+attach_bpf_fd.
So those two will use their own bpf_link extensions.
I haven't implemented those attachment APIs yet, but we should.
What should go into bpf_link itself is any information that's common
to any kind of attachment (e.g, "kind of attachment" itself). It's
conceivable that we might allow "casting" bpf_link into specific
variation and having extra "methods" on those. I haven't done that, as
I didn't have a need yet.
>
> > +static int bpf_link__destroy_perf_event(struct bpf_link *link)
> > +{
> > + struct bpf_link_fd *l = (void *)link;
> > + int err;
> > +
> > + if (l->fd < 0)
> > + return 0;
> > +
> > + err = ioctl(l->fd, PERF_EVENT_IOC_DISABLE, 0);
> > + close(l->fd);
> > + return err;
> > +}
> > +
> > +struct bpf_link *bpf_program__attach_perf_event(struct bpf_program *prog,
> > + int pfd)
> > +{
> > + char errmsg[STRERR_BUFSIZE];
> > + struct bpf_link_fd *link;
> > + int bpf_fd, err;
> > +
> > + bpf_fd = bpf_program__fd(prog);
> > + if (bpf_fd < 0) {
> > + pr_warning("program '%s': can't attach before loaded\n",
> > + bpf_program__title(prog, false));
> > + return ERR_PTR(-EINVAL);
> > + }
> > +
> > + link = malloc(sizeof(*link));
> > + if (!link)
> > + return ERR_PTR(-ENOMEM);
> > + link->link.destroy = &bpf_link__destroy_perf_event;
> > + link->fd = pfd;
> > +
> > + if (ioctl(pfd, PERF_EVENT_IOC_SET_BPF, bpf_fd) < 0) {
> > + err = -errno;
> > + free(link);
> > + pr_warning("program '%s': failed to attach to pfd %d: %s\n",
> > + bpf_program__title(prog, false), pfd,
> > + libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
> > + return ERR_PTR(err);
> > + }
> > + if (ioctl(pfd, PERF_EVENT_IOC_ENABLE, 0) < 0) {
> > + err = -errno;
> > + free(link);
> > + pr_warning("program '%s': failed to enable pfd %d: %s\n",
> > + bpf_program__title(prog, false), pfd,
> > + libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
> > + return ERR_PTR(err);
> > + }
> > + return (struct bpf_link *)link;
> > +}
> > +
> > enum bpf_perf_event_ret
> > bpf_perf_event_read_simple(void *mmap_mem, size_t mmap_size, size_t page_size,
> > void **copy_mem, size_t *copy_size,
> > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > index 5082a5ebb0c2..1bf66c4a9330 100644
> > --- a/tools/lib/bpf/libbpf.h
> > +++ b/tools/lib/bpf/libbpf.h
> > @@ -169,6 +169,9 @@ struct bpf_link;
> >
> > LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
> >
> > +LIBBPF_API struct bpf_link *
> > +bpf_program__attach_perf_event(struct bpf_program *prog, int pfd);
> > +
> > struct bpf_insn;
> >
> > /*
> > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> > index 3cde850fc8da..756f5aa802e9 100644
> > --- a/tools/lib/bpf/libbpf.map
> > +++ b/tools/lib/bpf/libbpf.map
> > @@ -169,6 +169,7 @@ LIBBPF_0.0.4 {
> > global:
> > bpf_link__destroy;
> > bpf_object__load_xattr;
> > + bpf_program__attach_perf_event;
> > btf_dump__dump_type;
> > btf_dump__free;
> > btf_dump__new;
> > --
> > 2.17.1
> >
^ permalink raw reply
* Re: pull-request: mac80211 2019-06-28
From: David Miller @ 2019-06-28 16:50 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190628144444.25092-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 28 Jun 2019 16:44:43 +0200
> Just a single patch still for the current RC cycle, I debated
> whether to send a pull request at all or just ask you to apply
> the patch, but did it this way now.
>
> Please pull and let me know if there's any problem.
Either way works for me :)
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH 00/10] pull request for net-next: batman-adv 2019-06-27 v2
From: David Miller @ 2019-06-28 16:49 UTC (permalink / raw)
To: sw; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20190628135604.11581-1-sw@simonwunderlich.de>
From: Simon Wunderlich <sw@simonwunderlich.de>
Date: Fri, 28 Jun 2019 15:55:54 +0200
> here is the updated feature/cleanup pull request of batman-adv for net-next
> from yesterday. Your change suggestions have been integrated into Patch 6
> of the series, everything else is unchanged.
>
> Please pull or let me know of any problem!
Pulled, thanks Simon.
I think that when you have the read_lock held, RCU is not necessary in order
to use __in6_dev_get() but I may be mistaken. Just FYI...
^ permalink raw reply
* Re: [PATCH 3/3, net-next] net: netsec: add XDP support
From: Ilias Apalodimas @ 2019-06-28 16:47 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, jaswinder.singh, ard.biesheuvel, bjorn.topel,
magnus.karlsson, daniel, ast, makita.toshiaki, jakub.kicinski,
john.fastabend, davem, maciejromanfijalkowski
In-Reply-To: <20190628153552.78a8c5ad@carbon>
On Fri, Jun 28, 2019 at 03:35:52PM +0200, Jesper Dangaard Brouer wrote:
> On Fri, 28 Jun 2019 13:39:15 +0300
> Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
>
> > +static int netsec_xdp_setup(struct netsec_priv *priv, struct bpf_prog *prog,
> > + struct netlink_ext_ack *extack)
> > +{
> > + struct net_device *dev = priv->ndev;
> > + struct bpf_prog *old_prog;
> > +
> > + /* For now just support only the usual MTU sized frames */
> > + if (prog && dev->mtu > 1500) {
> > + NL_SET_ERR_MSG_MOD(extack, "Jumbo frames not supported on XDP");
> > + return -EOPNOTSUPP;
> > + }
> > +
> > + if (netif_running(dev))
> > + netsec_netdev_stop(dev);
> > +
> > + /* Detach old prog, if any */
> > + old_prog = xchg(&priv->xdp_prog, prog);
> > + if (old_prog)
> > + bpf_prog_put(old_prog);
> > +
> > + if (netif_running(dev))
> > + netsec_netdev_open(dev);
>
> Shouldn't the if-statement be if (!netif_running(dev))
>
> > +
This is there to restart the device if it's up already (to rebuild the rings).
This should be fine as-is
> > + return 0;
> > +}
Thanks
/Ilias
^ permalink raw reply
* Re: [PATCH 0/2] pull request for net: batman-adv 2019-06-27
From: David Miller @ 2019-06-28 16:45 UTC (permalink / raw)
To: sw; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20190627103119.6969-1-sw@simonwunderlich.de>
From: Simon Wunderlich <sw@simonwunderlich.de>
Date: Thu, 27 Jun 2019 12:31:17 +0200
> here are some bugfixes which we would like to have integrated into net.
>
> Please pull or let me know of any problem!
Pulled, thanks Simon.
^ permalink raw reply
* Re: What to do when a bridge port gets its pvid deleted?
From: Florian Fainelli @ 2019-06-28 16:45 UTC (permalink / raw)
To: Vladimir Oltean, Ido Schimmel
Cc: netdev, Andrew Lunn, Vivien Didelot, stephen
In-Reply-To: <CA+h21hpPD6E_qOS-SxWKeXZKLOnN8og1BN_vSgk1+7XXQVTnBw@mail.gmail.com>
On 6/28/19 5:37 AM, Vladimir Oltean wrote:
> On Fri, 28 Jun 2019 at 15:30, Ido Schimmel <idosch@idosch.org> wrote:
>>
>> On Tue, Jun 25, 2019 at 11:49:29PM +0300, Vladimir Oltean wrote:
>>> A number of DSA drivers (BCM53XX, Microchip KSZ94XX, Mediatek MT7530
>>> at the very least), as well as Mellanox Spectrum (I didn't look at all
>>> the pure switchdev drivers) try to restore the pvid to a default value
>>> on .port_vlan_del.
>>
>> I don't know about DSA drivers, but that's not what mlxsw is doing. If
>> the VLAN that is configured as PVID is deleted from the bridge port, the
>> driver instructs the port to discard untagged and prio-tagged packets.
>> This is consistent with the bridge driver's behavior.
>>
>> We do have a flow the "restores" the PVID, but that's when a port is
>> unlinked from its bridge master. The PVID we set is 4095 which cannot be
>> configured by the 8021q / bridge driver. This is due to the way the
>> underlying hardware works. Even if a port is not bridged and used purely
>> for routing, packets still do L2 lookup first which sends them directly
>> to the router block. If PVID is not configured, untagged packets could
>> not be routed. Obviously, at egress we strip this VLAN.
>>
>>> Sure, the port stops receiving traffic when its pvid is a VLAN ID that
>>> is not installed in its hw filter, but as far as the bridge core is
>>> concerned, this is to be expected:
>>>
>>> # bridge vlan add dev swp2 vid 100 pvid untagged
>>> # bridge vlan
>>> port vlan ids
>>> swp5 1 PVID Egress Untagged
>>>
>>> swp2 1 Egress Untagged
>>> 100 PVID Egress Untagged
>>>
>>> swp3 1 PVID Egress Untagged
>>>
>>> swp4 1 PVID Egress Untagged
>>>
>>> br0 1 PVID Egress Untagged
>>> # ping 10.0.0.1
>>> PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
>>> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.682 ms
>>> 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.299 ms
>>> 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.251 ms
>>> 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.324 ms
>>> 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=0.257 ms
>>> ^C
>>> --- 10.0.0.1 ping statistics ---
>>> 5 packets transmitted, 5 received, 0% packet loss, time 4188ms
>>> rtt min/avg/max/mdev = 0.251/0.362/0.682/0.163 ms
>>> # bridge vlan del dev swp2 vid 100
>>> # bridge vlan
>>> port vlan ids
>>> swp5 1 PVID Egress Untagged
>>>
>>> swp2 1 Egress Untagged
>>>
>>> swp3 1 PVID Egress Untagged
>>>
>>> swp4 1 PVID Egress Untagged
>>>
>>> br0 1 PVID Egress Untagged
>>>
>>> # ping 10.0.0.1
>>> PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
>>> ^C
>>> --- 10.0.0.1 ping statistics ---
>>> 8 packets transmitted, 0 received, 100% packet loss, time 7267ms
>>>
>>> What is the consensus here? Is there a reason why the bridge driver
>>> doesn't take care of this?
>>
>> Take care of what? :) Always maintaining a PVID on the bridge port? It's
>> completely OK not to have a PVID.
>>
>
> Yes, I didn't think it through during the first email. I came to the
> same conclusion in the second one.
>
>>> Do switchdev drivers have to restore the pvid to always be
>>> operational, even if their state becomes inconsistent with the upper
>>> dev? Is it just 'nice to have'? What if VID 1 isn't in the hw filter
>>> either (perfectly legal)?
>>
>> Are you saying that DSA drivers always maintain a PVID on the bridge
>> port and allow untagged traffic to ingress regardless of the bridge
>> driver's configuration? If so, I think this needs to be fixed.
>
> Well, not at the DSA core level.
> But for Microchip:
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/drivers/net/dsa/microchip/ksz9477.c#n576
> For Broadcom:
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/drivers/net/dsa/b53/b53_common.c#n1376
> For Mediatek:
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/drivers/net/dsa/mt7530.c#n1196
>
> There might be others as well.
That sounds bogus indeed, and I bet that the two other drivers just
followed the b53 driver there. I will have to test this again and come
up with a patch eventually.
When the port leaves the bridge we do bring it back into a default PVID
(which is different than the bridge's default PVID) so that part should
be okay.
--
Florian
^ permalink raw reply
* Re: [PATCH 3/3, net-next] net: netsec: add XDP support
From: David Miller @ 2019-06-28 16:44 UTC (permalink / raw)
To: brouer
Cc: ilias.apalodimas, netdev, jaswinder.singh, ard.biesheuvel,
bjorn.topel, magnus.karlsson, daniel, ast, makita.toshiaki,
jakub.kicinski, john.fastabend, maciejromanfijalkowski
In-Reply-To: <20190628153552.78a8c5ad@carbon>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Fri, 28 Jun 2019 15:35:52 +0200
> On Fri, 28 Jun 2019 13:39:15 +0300
> Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
>
>> +static int netsec_xdp_setup(struct netsec_priv *priv, struct bpf_prog *prog,
>> + struct netlink_ext_ack *extack)
>> +{
>> + struct net_device *dev = priv->ndev;
>> + struct bpf_prog *old_prog;
>> +
>> + /* For now just support only the usual MTU sized frames */
>> + if (prog && dev->mtu > 1500) {
>> + NL_SET_ERR_MSG_MOD(extack, "Jumbo frames not supported on XDP");
>> + return -EOPNOTSUPP;
>> + }
>> +
>> + if (netif_running(dev))
>> + netsec_netdev_stop(dev);
>> +
>> + /* Detach old prog, if any */
>> + old_prog = xchg(&priv->xdp_prog, prog);
>> + if (old_prog)
>> + bpf_prog_put(old_prog);
>> +
>> + if (netif_running(dev))
>> + netsec_netdev_open(dev);
>
> Shouldn't the if-statement be if (!netif_running(dev))
Hmmm, does netsec_netdev_stop() clear the running flag? That just
runs the driver internal routine and doesn't update IFF_UP et
al. which the core networking would do.
^ permalink raw reply
* Re: [PATCH 1/3, net-next] net: netsec: Use page_pool API
From: David Miller @ 2019-06-28 16:43 UTC (permalink / raw)
To: brouer
Cc: ilias.apalodimas, netdev, jaswinder.singh, ard.biesheuvel,
bjorn.topel, magnus.karlsson, daniel, ast, makita.toshiaki,
jakub.kicinski, john.fastabend, maciejromanfijalkowski
In-Reply-To: <20190628150434.30da8852@carbon>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Fri, 28 Jun 2019 15:04:34 +0200
> On Fri, 28 Jun 2019 13:39:13 +0300
> Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
>
>> Use page_pool and it's DMA mapping capabilities for Rx buffers instead
>> of netdev/napi_alloc_frag()
>>
>> Although this will result in a slight performance penalty on small sized
>> packets (~10%) the use of the API will allow to easily add XDP support.
>> The penalty won't be visible in network testing i.e ipef/netperf etc, it
>> only happens during raw packet drops.
>> Furthermore we intend to add recycling capabilities on the API
>> in the future. Once the recycling is added the performance penalty will
>> go away.
>> The only 'real' penalty is the slightly increased memory usage, since we
>> now allocate a page per packet instead of the amount of bytes we need +
>> skb metadata (difference is roughly 2kb per packet).
>> With a minimum of 4BG of RAM on the only SoC that has this NIC the
>> extra memory usage is negligible (a bit more on 64K pages)
>>
>> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>> ---
>> drivers/net/ethernet/socionext/Kconfig | 1 +
>> drivers/net/ethernet/socionext/netsec.c | 121 +++++++++++++++---------
>> 2 files changed, 75 insertions(+), 47 deletions(-)
>
> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Jesper this is confusing, you just asked if the code needs to be moved
around to be correct and then right now immediately afterwards you ACK
the patch.
^ permalink raw reply
* Re: [PATCH v3 bpf-next 2/9] libbpf: introduce concept of bpf_link
From: Andrii Nakryiko @ 2019-06-28 16:42 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann, Networking,
bpf, Kernel Team
In-Reply-To: <20190628160230.GG4866@mini-arch>
On Fri, Jun 28, 2019 at 9:02 AM Stanislav Fomichev <sdf@fomichev.me> wrote:
>
> On 06/27, Andrii Nakryiko wrote:
> > bpf_link is and abstraction of an association of a BPF program and one
> > of many possible BPF attachment points (hooks). This allows to have
> > uniform interface for detaching BPF programs regardless of the nature of
> > link and how it was created. Details of creation and setting up of
> > a specific bpf_link is handled by corresponding attachment methods
> > (bpf_program__attach_xxx) added in subsequent commits. Once successfully
> > created, bpf_link has to be eventually destroyed with
> > bpf_link__destroy(), at which point BPF program is disassociated from
> > a hook and all the relevant resources are freed.
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > tools/lib/bpf/libbpf.c | 17 +++++++++++++++++
> > tools/lib/bpf/libbpf.h | 4 ++++
> > tools/lib/bpf/libbpf.map | 3 ++-
> > 3 files changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index 6e6ebef11ba3..455795e6f8af 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -3941,6 +3941,23 @@ int bpf_prog_load_xattr(const struct bpf_prog_load_attr *attr,
> > return 0;
> > }
> >
> > +struct bpf_link {
> Maybe call it bpf_attachment? You call the bpf_program__attach_to_blah
> and you get an attachment?
I wanted to keep it as short as possible, bpf_attachment is way too
long (it's also why as an alternative I've proposed bpf_assoc, not
bpf_association, but bpf_attach isn't great shortening).
>
> > + int (*destroy)(struct bpf_link *link);
> > +};
> > +
> > +int bpf_link__destroy(struct bpf_link *link)
> > +{
> > + int err;
> > +
> > + if (!link)
> > + return 0;
> > +
> > + err = link->destroy(link);
> > + free(link);
> > +
> > + return err;
> > +}
> > +
> > enum bpf_perf_event_ret
> > bpf_perf_event_read_simple(void *mmap_mem, size_t mmap_size, size_t page_size,
> > void **copy_mem, size_t *copy_size,
> > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > index d639f47e3110..5082a5ebb0c2 100644
> > --- a/tools/lib/bpf/libbpf.h
> > +++ b/tools/lib/bpf/libbpf.h
> > @@ -165,6 +165,10 @@ LIBBPF_API int bpf_program__pin(struct bpf_program *prog, const char *path);
> > LIBBPF_API int bpf_program__unpin(struct bpf_program *prog, const char *path);
> > LIBBPF_API void bpf_program__unload(struct bpf_program *prog);
> >
> > +struct bpf_link;
> > +
> > +LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
> > +
> > struct bpf_insn;
> >
> > /*
> > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> > index 2c6d835620d2..3cde850fc8da 100644
> > --- a/tools/lib/bpf/libbpf.map
> > +++ b/tools/lib/bpf/libbpf.map
> > @@ -167,10 +167,11 @@ LIBBPF_0.0.3 {
> >
> > LIBBPF_0.0.4 {
> > global:
> > + bpf_link__destroy;
> > + bpf_object__load_xattr;
> > btf_dump__dump_type;
> > btf_dump__free;
> > btf_dump__new;
> > btf__parse_elf;
> > - bpf_object__load_xattr;
> > libbpf_num_possible_cpus;
> > } LIBBPF_0.0.3;
> > --
> > 2.17.1
> >
^ permalink raw reply
* Re: [PATCH net-next 00/12] net: hns3: some code optimizations & cleanups & bugfixes
From: David Miller @ 2019-06-28 16:40 UTC (permalink / raw)
To: tanhuazhong; +Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm
In-Reply-To: <1561722618-12168-1-git-send-email-tanhuazhong@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
Date: Fri, 28 Jun 2019 19:50:06 +0800
> [patch 01/12] fixes a TX timeout issue.
>
> [patch 02/12 - 04/12] adds some patch related to TM module.
>
> [patch 05/12] fixes a compile warning.
>
> [patch 06/12] adds Asym Pause support for autoneg
>
> [patch 07/12] optimizes the error handler for VF reset.
>
> [patch 08/12] deals with the empty interrupt case.
>
> [patch 09/12 - 12/12] adds some cleanups & optimizations.
Looks good, series applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/5] net: dsa: microchip: Further regmap cleanups
From: Marek Vasut @ 2019-06-28 16:36 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, Andrew Lunn, Florian Fainelli, Tristram Ha, Woojung Huh
In-Reply-To: <20190628113130.GB14087@t480s.localdomain>
On 6/28/19 5:31 PM, Vivien Didelot wrote:
> Hi Marek,
>
> On Thu, 27 Jun 2019 23:55:51 +0200, Marek Vasut <marex@denx.de> wrote:
>> This patchset cleans up KSZ9477 switch driver by replacing various
>> ad-hoc polling implementations and register RMW with regmap functions.
>>
>> Each polling function is replaced separately to make it easier to review
>> and possibly bisect, but maybe the patches can be squashed.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Andrew Lunn <andrew@lunn.ch>
>> Cc: Florian Fainelli <f.fainelli@gmail.com>
>> Cc: Tristram Ha <Tristram.Ha@microchip.com>
>> Cc: Woojung Huh <Woojung.Huh@microchip.com>
>
> Please copy me next time, as per the MAINTAINERS file.
Will do. I plan to submit KSZ8795 support next.
--
Best regards,
Marek Vasut
^ permalink raw reply
* net: check before dereferencing netdev_ops during busy poll
From: Matteo Croce @ 2019-06-28 16:34 UTC (permalink / raw)
To: stable, Sasha Levin; +Cc: Greg Kroah-Hartman, Josh Elsasser, netdev, LKML
Hi,
Is there any reason for this panic fix not being applied in stable?
https://lore.kernel.org/netdev/20180313053248.13654-1-jelsasser@appneta.com/T/
It seems that linux 4.9.184 has the bug too.
Regards,
--
Matteo Croce
per aspera ad upstream
^ permalink raw reply
* Re: [PATCH] hinic: reduce rss_init stack usage
From: David Miller @ 2019-06-28 16:32 UTC (permalink / raw)
To: arnd
Cc: aviad.krawczyk, xuechaojing, jesse.brandeburg, zhaochen6,
edumazet, dann.frazier, netdev, linux-kernel
In-Reply-To: <20190628103158.2446356-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 28 Jun 2019 12:31:44 +0200
> On 32-bit architectures, putting an array of 256 u32 values on the
> stack uses more space than the warning limit:
>
> drivers/net/ethernet/huawei/hinic/hinic_main.c: In function 'hinic_rss_init':
> drivers/net/ethernet/huawei/hinic/hinic_main.c:286:1: error: the frame size of 1068 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>
> I considered changing the code to use u8 values here, since that's
> all the hardware supports, but dynamically allocating the array is
> a more isolated fix here.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied to net-next.
Arnd, please make it clear what tree you are targetting in the
future. Thank you.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/3] Better PHYLINK compliance for SJA1105 DSA
From: David Miller @ 2019-06-28 16:31 UTC (permalink / raw)
To: linux; +Cc: olteanv, f.fainelli, vivien.didelot, andrew, netdev
In-Reply-To: <20190628100542.hmzqnp4bsnkikcvv@shell.armlinux.org.uk>
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Date: Fri, 28 Jun 2019 11:05:42 +0100
> On Fri, Jun 28, 2019 at 12:46:34AM +0300, Vladimir Oltean wrote:
>> After discussing with Russell King, it appears this driver is making a
>> few confusions and not performing some checks for consistent operation.
>>
>> Changes in v2:
>> - Removed redundant print in the phylink_validate callback (in 2/3).
>>
>> Vladimir Oltean (3):
>> net: dsa: sja1105: Don't check state->link in phylink_mac_config
>> net: dsa: sja1105: Check for PHY mode mismatches with what PHYLINK
>> reports
>> net: dsa: sja1105: Mark in-band AN modes not supported for PHYLINK
>>
>> drivers/net/dsa/sja1105/sja1105_main.c | 56 +++++++++++++++++++++++++-
>> 1 file changed, 54 insertions(+), 2 deletions(-)
>
> Thanks. For the whole series:
>
> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Series applied, thanks all.
^ permalink raw reply
* Re: [RFC] longer netdev names proposal
From: Michal Kubecek @ 2019-06-28 16:27 UTC (permalink / raw)
To: netdev
Cc: Jiri Pirko, Andrew Lunn, Stephen Hemminger, David Ahern, davem,
jakub.kicinski, mlxsw
In-Reply-To: <20190628135553.GA6640@nanopsycho>
On Fri, Jun 28, 2019 at 03:55:53PM +0200, Jiri Pirko wrote:
> Fri, Jun 28, 2019 at 03:14:01PM CEST, andrew@lunn.ch wrote:
> >
> >What is your user case for having multiple IFLA_ALT_NAME for the same
> >IFLA_NAME?
>
> I don't know about specific usecase for having more. Perhaps Michal
> does.
One use case that comes to my mind are the "predictable names"
implemented by udev/systemd which can be based on different naming
schemes (bus address, BIOS numbering, MAC address etc.) and it's not
always obvious which scheme is going to be used. I have even seen
multiple times that one schemed was used during system installation and
another in the installed system so that network configuration created by
installer did not work.
For block devices, current practice is not to rename the device and only
create multiple symlinks based on different naming schemes (by id, by
uuid, by label, etc.). With support for multiple altnames, we could also
identify the network device in different ways (all applicable ones).
Michal
^ permalink raw reply
* Re: [RFC iproute2 1/1] ip: netns: add mounted state file for each netns
From: David Howells @ 2019-06-28 16:26 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: dhowells, Alexander Aring, netdev, linux-fsdevel, kernel
In-Reply-To: <293c9bd3-f530-d75e-c353-ddeabac27cf6@6wind.com>
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> David Howells was working on a mount notification mechanism:
> https://lwn.net/Articles/760714/
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=notifications
>
> I don't know what is the status of this series.
It's still alive. I just posted a new version on it. I'm hoping, possibly
futiley, to get it in in this merge window.
David
^ 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