* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: Jason Wang @ 2018-08-16 4:24 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David Ahern, Jesper Dangaard Brouer, netdev, linux-kernel, ast,
daniel, mst
In-Reply-To: <20180816040517.7vjm4bwxosyzvapu@ast-mbp.dhcp.thefacebook.com>
On 2018年08月16日 12:05, Alexei Starovoitov wrote:
> On Thu, Aug 16, 2018 at 11:34:20AM +0800, Jason Wang wrote:
>>> Nothing about the topology is hard coded. The idea is to mimic a
>>> hardware pipeline and acknowledging that a port device can have an
>>> arbitrary layers stacked on it - multiple vlan devices, bonds, macvlans, etc
>> I may miss something but BPF forbids loop. Without a loop how can we make
>> sure all stacked devices is enumerated correctly without knowing the
>> topology in advance?
> not following. why do you need a loop to implement macvlan as an xdp prog?
> if loop is needed, such algorithm is not going to scale whether
> it's implemented as bpf program or as in-kernel c code.
David said the port can have arbitrary layers stacked on it. So if we
try to enumerate them before making forwarding decisions purely by BPF
program, it looks to me a loop is needed here.
Thanks
^ permalink raw reply
* Re: [PATCH stable 4.4 0/9] fix SegmentSmack (CVE-2018-5390)
From: maowenan @ 2018-08-16 1:20 UTC (permalink / raw)
To: Greg KH; +Cc: dwmw2, netdev, eric.dumazet, edumazet, davem, ycheng, jdw
In-Reply-To: <20180815154131.GA12619@kroah.com>
On 2018/8/15 23:41, Greg KH wrote:
> On Wed, Aug 15, 2018 at 03:24:32PM +0200, Greg KH wrote:
>> On Wed, Aug 15, 2018 at 09:20:59PM +0800, Mao Wenan wrote:
>>> There are five patches to fix CVE-2018-5390 in latest mainline
>>> branch, but only two patches exist in stable 4.4 and 3.18:
>>> dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
>>> 5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
>>> but I have tested with these patches, and found the cpu usage was very high.
>>> test results:
>>> with fix patch： 78.2% ksoftirqd
>>> no fix patch： 90% ksoftirqd
>>>
>>> After analysing the codes of stable 4.4, and debuging the
>>> system, the search of ofo_queue(tcp ofo using a simple queue) cost more cycles.
>>> So I think only two patches can't fix the CVE-2018-5390.
>>> So I try to backport "tcp: use an RB tree for ooo receive queue" using RB tree
>>> instead of simple queue, then backport Eric Dumazet 5 fixed patches in mainline,
>>> good news is that ksoftirqd is turn to about 20%, which is the same with mainline now.
>>
>> Thanks for doing this work, I had some questions on the individual
>> patches. Can you address them and resend?
>
> Also, always cc: the stable@vger list when sending stable patches so
> that others can review and comment on them.
ok,I will resend patches later after refining them.
>
> thanks,
>
> greg k-h
>
> .
>
^ permalink raw reply
* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: Alexei Starovoitov @ 2018-08-16 4:05 UTC (permalink / raw)
To: Jason Wang
Cc: David Ahern, Jesper Dangaard Brouer, netdev, linux-kernel, ast,
daniel, mst
In-Reply-To: <2792239a-ed3b-d66e-0c1c-e99455311eff@redhat.com>
On Thu, Aug 16, 2018 at 11:34:20AM +0800, Jason Wang wrote:
> > Nothing about the topology is hard coded. The idea is to mimic a
> > hardware pipeline and acknowledging that a port device can have an
> > arbitrary layers stacked on it - multiple vlan devices, bonds, macvlans, etc
>
> I may miss something but BPF forbids loop. Without a loop how can we make
> sure all stacked devices is enumerated correctly without knowing the
> topology in advance?
not following. why do you need a loop to implement macvlan as an xdp prog?
if loop is needed, such algorithm is not going to scale whether
it's implemented as bpf program or as in-kernel c code.
^ permalink raw reply
* KINDLY REPLY stemlightresources@gmail.com URGENTLY
From: STEMLIGHTRESOURCES @ 2018-08-16 0:56 UTC (permalink / raw)
To: Recipients
KINDLY REPLY stemlightresources@gmail.com URGENTLY
^ permalink raw reply
* RE: [PATCH] net: stmmac: Add SMC support for EMAC System Manager register
From: Ooi, Joyce @ 2018-08-16 3:39 UTC (permalink / raw)
To: David Miller
Cc: peppe.cavallaro@st.com, alexandre.torgue@st.com,
joabreu@synopsys.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Ong, Hean Loong, Vandervennet, Yves
In-Reply-To: <20180813.094806.2117966073798365808.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, August 14, 2018 12:48 AM
> To: Ooi, Joyce <joyce.ooi@intel.com>
> Cc: peppe.cavallaro@st.com; alexandre.torgue@st.com;
> joabreu@synopsys.com; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> Ong, Hean Loong <hean.loong.ong@intel.com>; Vandervennet, Yves
> <yves.vandervennet@intel.com>
> Subject: Re: [PATCH] net: stmmac: Add SMC support for EMAC System Manager
> register
>
> From: "Ooi, Joyce" <joyce.ooi@intel.com>
> Date: Sun, 12 Aug 2018 23:41:34 -0700
>
> > As there is restriction to access to EMAC System Manager registers in
> > the kernel for Intel Stratix10, the use of SMC calls are required and
> > added in dwmac-socfpga driver.
> >
> > Signed-off-by: Ooi, Joyce <joyce.ooi@intel.com>
> > ---
> > This patch is dependent on https://lkml.org/lkml/2018/7/26/624
>
> I guess I cannot apply this to my networking tree then.
>
> I would suggest that you make a helper in a header file which dos the special
> SMC EMAC accesses, or alternatively the regular regmap access, based upon the
> CPP ifdef.
Could you please explain what you mean by 'a helper in a header file'?
Thanks.
>
> That way you won't have to put all of those CPP tests in the foo.c code.
>
> Thanks.
^ permalink raw reply
* Re: [PATCH net] veth: Free queues on link delete
From: kbuild test robot @ 2018-08-16 0:44 UTC (permalink / raw)
To: dsahern; +Cc: kbuild-all, netdev, davem, makita.toshiaki, David Ahern
In-Reply-To: <20180814223657.32101-1-dsahern@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]
Hi David,
I love your patch! Yet something to improve:
[auto build test ERROR on net/master]
url: https://github.com/0day-ci/linux/commits/dsahern-kernel-org/veth-Free-queues-on-link-delete/20180816-073955
config: i386-randconfig-x016-201832 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers//net/veth.c: In function 'veth_dellink':
>> drivers//net/veth.c:476:2: error: implicit declaration of function 'veth_free_queues'; did you mean 'veth_dev_free'? [-Werror=implicit-function-declaration]
veth_free_queues(dev);
^~~~~~~~~~~~~~~~
veth_dev_free
cc1: some warnings being treated as errors
vim +476 drivers//net/veth.c
470
471 static void veth_dellink(struct net_device *dev, struct list_head *head)
472 {
473 struct veth_priv *priv;
474 struct net_device *peer;
475
> 476 veth_free_queues(dev);
477 priv = netdev_priv(dev);
478 peer = rtnl_dereference(priv->peer);
479
480 /* Note : dellink() is called from default_device_exit_batch(),
481 * before a rcu_synchronize() point. The devices are guaranteed
482 * not being freed before one RCU grace period.
483 */
484 RCU_INIT_POINTER(priv->peer, NULL);
485 unregister_netdevice_queue(dev, head);
486
487 if (peer) {
488 priv = netdev_priv(peer);
489 RCU_INIT_POINTER(priv->peer, NULL);
490 unregister_netdevice_queue(peer, head);
491 }
492 }
493
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 34697 bytes --]
^ permalink raw reply
* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: Jason Wang @ 2018-08-16 3:34 UTC (permalink / raw)
To: David Ahern, Jesper Dangaard Brouer
Cc: Alexei Starovoitov, netdev, linux-kernel, ast, daniel, mst
In-Reply-To: <f4c0346d-6665-5312-0310-ffbda505b7ec@gmail.com>
On 2018年08月16日 01:17, David Ahern wrote:
> On 8/14/18 6:29 PM, Jason Wang wrote:
>>
>> On 2018年08月14日 22:03, David Ahern wrote:
>>> On 8/14/18 7:20 AM, Jason Wang wrote:
>>>> On 2018年08月14日 18:17, Jesper Dangaard Brouer wrote:
>>>>> On Tue, 14 Aug 2018 15:59:01 +0800
>>>>> Jason Wang <jasowang@redhat.com> wrote:
>>>>>
>>>>>> On 2018年08月14日 08:32, Alexei Starovoitov wrote:
>>>>>>> On Mon, Aug 13, 2018 at 11:17:24AM +0800, Jason Wang wrote:
>>>>>>>> Hi:
>>>>>>>>
>>>>>>>> This series tries to implement XDP support for rx hanlder. This
>>>>>>>> would
>>>>>>>> be useful for doing native XDP on stacked device like macvlan,
>>>>>>>> bridge
>>>>>>>> or even bond.
>>>>>>>>
>>>>>>>> The idea is simple, let stacked device register a XDP rx handler.
>>>>>>>> And
>>>>>>>> when driver return XDP_PASS, it will call a new helper xdp_do_pass()
>>>>>>>> which will try to pass XDP buff to XDP rx handler directly. XDP rx
>>>>>>>> handler may then decide how to proceed, it could consume the
>>>>>>>> buff, ask
>>>>>>>> driver to drop the packet or ask the driver to fallback to normal
>>>>>>>> skb
>>>>>>>> path.
>>>>>>>>
>>>>>>>> A sample XDP rx handler was implemented for macvlan. And virtio-net
>>>>>>>> (mergeable buffer case) was converted to call xdp_do_pass() as an
>>>>>>>> example. For ease comparision, generic XDP support for rx handler
>>>>>>>> was
>>>>>>>> also implemented.
>>>>>>>>
>>>>>>>> Compared to skb mode XDP on macvlan, native XDP on macvlan
>>>>>>>> (XDP_DROP)
>>>>>>>> shows about 83% improvement.
>>>>>>> I'm missing the motiviation for this.
>>>>>>> It seems performance of such solution is ~1M packet per second.
>>>>>> Notice it was measured by virtio-net which is kind of slow.
>>>>>>
>>>>>>> What would be a real life use case for such feature ?
>>>>>> I had another run on top of 10G mlx4 and macvlan:
>>>>>>
>>>>>> XDP_DROP on mlx4: 14.0Mpps
>>>>>> XDP_DROP on macvlan: 10.05Mpps
>>>>>>
>>>>>> Perf shows macvlan_hash_lookup() and indirect call to
>>>>>> macvlan_handle_xdp() are the reasons for the number drop. I think the
>>>>>> numbers are acceptable. And we could try more optimizations on top.
>>>>>>
>>>>>> So here's real life use case is trying to have an fast XDP path for rx
>>>>>> handler based device:
>>>>>>
>>>>>> - For containers, we can run XDP for macvlan (~70% of wire speed).
>>>>>> This
>>>>>> allows a container specific policy.
>>>>>> - For VM, we can implement macvtap XDP rx handler on top. This
>>>>>> allow us
>>>>>> to forward packet to VM without building skb in the setup of macvtap.
>>>>>> - The idea could be used by other rx handler based device like bridge,
>>>>>> we may have a XDP fast forwarding path for bridge.
>>>>>>
>>>>>>> Another concern is that XDP users expect to get line rate performance
>>>>>>> and native XDP delivers it. 'generic XDP' is a fallback only
>>>>>>> mechanism to operate on NICs that don't have native XDP yet.
>>>>>> So I can replace generic XDP TX routine with a native one for macvlan.
>>>>> If you simply implement ndo_xdp_xmit() for macvlan, and instead use
>>>>> XDP_REDIRECT, then we are basically done.
>>>> As I replied in another thread this probably not true. Its
>>>> ndo_xdp_xmit() just need to call under layer device's ndo_xdp_xmit()
>>>> except for the case of bridge mode.
>>>>
>>>>>>> Toshiaki's veth XDP work fits XDP philosophy and allows
>>>>>>> high speed networking to be done inside containers after veth.
>>>>>>> It's trying to get to line rate inside container.
>>>>>> This is one of the goal of this series as well. I agree veth XDP work
>>>>>> looks pretty fine, but it only work for a specific setup I believe
>>>>>> since
>>>>>> it depends on XDP_REDIRECT which is supported by few drivers (and
>>>>>> there's no VF driver support).
>>>>> The XDP_REDIRECT (RX-side) is trivial to add to drivers. It is a bad
>>>>> argument that only a few drivers implement this. Especially since all
>>>>> drivers also need to be extended with your proposed xdp_do_pass() call.
>>>>>
>>>>> (rant) The thing that is delaying XDP_REDIRECT adaption in drivers, is
>>>>> that it is harder to implement the TX-side, as the ndo_xdp_xmit() call
>>>>> have to allocate HW TX-queue resources. If we disconnect RX and TX
>>>>> side of redirect, then we can implement RX-side in an afternoon.
>>>> That's exactly the point, ndo_xdp_xmit() may requires per CPU TX queues
>>>> which breaks assumptions of some drivers. And since we don't disconnect
>>>> RX and TX, it looks to me the partial implementation is even worse?
>>>> Consider a user can redirect from mlx4 to ixgbe but not ixgbe to mlx4.
>>>>
>>>>>> And in order to make it work for a end
>>>>>> user, the XDP program still need logic like hash(map) lookup to
>>>>>> determine the destination veth.
>>>>> That _is_ the general idea behind XDP and eBPF, that we need to add
>>>>> logic
>>>>> that determine the destination. The kernel provides the basic
>>>>> mechanisms for moving/redirecting packets fast, and someone else
>>>>> builds an orchestration tool like Cilium, that adds the needed logic.
>>>> Yes, so my reply is for the concern about performance. I meant anyway
>>>> the hash lookup will make it not hit the wire speed.
>>>>
>>>>> Did you notice that we (Ahern) added bpf_fib_lookup a FIB route lookup
>>>>> accessible from XDP.
>>>> Yes.
>>>>
>>>>> For macvlan, I imagine that we could add a BPF helper that allows you
>>>>> to lookup/call macvlan_hash_lookup().
>>>> That's true but we still need a method to feed macvlan with XDP buff.
>>>> I'm not sure if this could be treated as another kind of redirection,
>>>> but ndo_xdp_xmit() could not be used for this case for sure. Compared to
>>>> redirection, XDP rx handler has its own advantages:
>>>>
>>>> 1) Use the exist API and userspace to setup the network topology instead
>>>> of inventing new tools and its own specific API. This means user can
>>>> just setup macvlan (macvtap, bridge or other) as usual and simply attach
>>>> XDP programs to both macvlan and its under layer device.
>>>> 2) Ease the processing of complex logic, XDP can not do cloning or
>>>> reference counting. We can differ those cases and let normal networking
>>>> stack to deal with such packets seamlessly. I believe this is one of the
>>>> advantage of XDP. This makes us to focus on the fast path and greatly
>>>> simplify the codes.
>>>>
>>>> Like ndo_xdp_xmit(), XDP rx handler is used to feed RX handler with XDP
>>>> buff. It's just another basic mechanism. Policy is still done by XDP
>>>> program itself.
>>>>
>>> I have been looking into handling stacked devices via lookup helper
>>> functions. The idea is that a program only needs to be installed on the
>>> root netdev (ie., the one representing the physical port), and it can
>>> use helpers to create an efficient pipeline to decide what to do with
>>> the packet in the presence of stacked devices.
>>>
>>> For example, anyone doing pure L3 could do:
>>>
>>> {port, vlan} --> [ find l2dev ] --> [ find l3dev ] ...
>>>
>>> --> [ l3 forward lookup ] --> [ header rewrite ] --> XDP_REDIRECT
>>>
>>> port is the netdev associated with the ingress_ifindex in the xdp_md
>>> context, vlan is the vlan in the packet or the assigned PVID if
>>> relevant. From there l2dev could be a bond or bridge device for example,
>>> and l3dev is the one with a network address (vlan netdev, bond netdev,
>>> etc).
>> Looks less flexible since the topology is hard coded in the XDP program
>> itself and this requires all logic to be implemented in the program on
>> the root netdev.
> Nothing about the topology is hard coded. The idea is to mimic a
> hardware pipeline and acknowledging that a port device can have an
> arbitrary layers stacked on it - multiple vlan devices, bonds, macvlans, etc
I may miss something but BPF forbids loop. Without a loop how can we
make sure all stacked devices is enumerated correctly without knowing
the topology in advance?
>
>>> I have L3 forwarding working for vlan devices and bonds. I had not
>>> considered macvlans specifically yet, but it should be straightforward
>>> to add.
>>>
>> Yes, and all these could be done through XDP rx handler as well, and it
>> can do even more with rather simple logic:
> From a forwarding perspective I suspect the rx handler approach is going
> to have much more overhead (ie., higher latency per packet and hence
> lower throughput) as the layers determine which one to use (e.g., is the
> FIB lookup done on the port device, vlan device, or macvlan device on
> the vlan device).
Well, if we want stacked device behave correctly, this is probably the
only way. E.g in the above figure, to make "find l2dev" work correctly,
we still need device specific logic which would be much similar to what
XDP rx handler did.
Thanks
>
>> 1 macvlan has its own namespace, and want its own bpf logic.
>> 2 Ruse the exist topology information for dealing with more complex
>> setup like macvlan on top of bond and team. There's no need to bpf
>> program to care about topology. If you look at the code, there's even no
>> need to attach XDP on each stacked device. The calling of xdp_do_pass()
>> can try to pass XDP buff to upper device even if there's no XDP program
>> attached to current layer.
>> 3 Deliver XDP buff to userspace through macvtap.
>>
>> Thanks
^ permalink raw reply
* Re: [PATCH v2 net-next 0/8] net: dsa: microchip: Modify KSZ9477 DSA driver in preparation to add other KSZ switch drivers
From: Florian Fainelli @ 2018-08-16 0:28 UTC (permalink / raw)
To: Tristram.Ha, Andrew Lunn, Pavel Machek, Ruediger Schmitt
Cc: Arkadi Sharshevsky, UNGLinuxDriver, netdev
In-Reply-To: <1512524798-16210-1-git-send-email-Tristram.Ha@microchip.com>
On 12/05/2017 05:46 PM, Tristram.Ha@microchip.com wrote:
> From: Tristram Ha <Tristram.Ha@microchip.com>
>
> This series of patches is to modify the original KSZ9477 DSA driver so
> that other KSZ switch drivers can be added and use the common code.
>
> There are several steps to accomplish this achievement. First is to
> rename some function names with a prefix to indicate chip specific
> function. Second is to move common code into header that can be shared.
> Last is to modify tag_ksz.c so that it can handle many tail tag formats
> used by different KSZ switch drivers.
>
> ksz_common.c will contain the common code used by all KSZ switch drivers.
> ksz9477.c will contain KSZ9477 code from the original ksz_common.c.
> ksz9477_spi.c is renamed from ksz_spi.c.
> ksz9477_reg.h is renamed from ksz_9477_reg.h.
> ksz_common.h is added to provide common code access to KSZ switch
> drivers.
> ksz_spi.h is added to provide common SPI access functions to KSZ SPI
> drivers.
Is something gating this series from getting included? It's been nearly
8 months now and this has not been include nor resubmitted, any plans to
rebase that patch series and work towards inclusion in net-next when it
opens back again?
Thank you!
>
> v2
> - Initialize reg_mutex before use
> - The alu_mutex is only used inside chip specific functions
>
> v1
> - Each patch in the set is self-contained
> - Use ksz9477 prefix to indicate KSZ9477 specific code
>
> Tristram Ha (8):
> Replace license with GPL.
> Clean up code according to patch check suggestions.
> Initialize mutex before use.
> Rename some functions with ksz9477 prefix to separate chip specific
> code from common code.
> Rename ksz_spi.c to ksz9477_spi.c and update Kconfig in preparation to
> add more KSZ switch drivers.
> Break KSZ9477 DSA driver into two files in preparation to add more KSZ
> switch drivers. Add common functions in ksz_common.h so that other
> KSZ switch drivers can access code in ksz_common.c. Add ksz_spi.h
> for common functions used by KSZ switch SPI drivers.
> Prepare PHY for proper advertisement and get link status for the port.
> Rename ksz_9477_reg.h to ksz9477_reg.h for consistency as the product
> name is always KSZ####.
>
> drivers/net/dsa/microchip/Kconfig | 12 +-
> drivers/net/dsa/microchip/Makefile | 4 +-
> drivers/net/dsa/microchip/ksz9477.c | 1331 ++++++++++++++++++++
> .../microchip/{ksz_9477_reg.h => ksz9477_reg.h} | 23 +-
> drivers/net/dsa/microchip/ksz9477_spi.c | 188 +++
> drivers/net/dsa/microchip/ksz_common.c | 1176 +++--------------
> drivers/net/dsa/microchip/ksz_common.h | 229 ++++
> drivers/net/dsa/microchip/ksz_priv.h | 256 ++--
> drivers/net/dsa/microchip/ksz_spi.c | 216 ----
> drivers/net/dsa/microchip/ksz_spi.h | 82 ++
> 10 files changed, 2122 insertions(+), 1395 deletions(-)
> create mode 100644 drivers/net/dsa/microchip/ksz9477.c
> rename drivers/net/dsa/microchip/{ksz_9477_reg.h => ksz9477_reg.h} (98%)
> create mode 100644 drivers/net/dsa/microchip/ksz9477_spi.c
> create mode 100644 drivers/net/dsa/microchip/ksz_common.h
> delete mode 100644 drivers/net/dsa/microchip/ksz_spi.c
> create mode 100644 drivers/net/dsa/microchip/ksz_spi.h
>
--
Florian
^ permalink raw reply
* Re: [PATCH] net: dsa: add support for ksz9897 ethernet switch
From: Florian Fainelli @ 2018-08-16 0:24 UTC (permalink / raw)
To: Lad Prabhakar, Woojung Huh, Microchip Linux Driver Support,
Andrew Lunn, Vivien Didelot
Cc: netdev, devicetree
In-Reply-To: <1534348283-12790-1-git-send-email-prabhakar.csengg@gmail.com>
On 08/15/2018 08:51 AM, Lad Prabhakar wrote:
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> ksz9477 is superset of ksz9xx series, driver just works
> out of the box for ksz9897 chip with this patch.
net-next is currently closed, but other than that:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> ---
> Documentation/devicetree/bindings/net/dsa/ksz.txt | 4 +++-
> drivers/net/dsa/microchip/ksz_common.c | 9 +++++++++
> drivers/net/dsa/microchip/ksz_spi.c | 1 +
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/ksz.txt b/Documentation/devicetree/bindings/net/dsa/ksz.txt
> index a700943..ac145b8 100644
> --- a/Documentation/devicetree/bindings/net/dsa/ksz.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/ksz.txt
> @@ -4,7 +4,9 @@ Microchip KSZ Series Ethernet switches
> Required properties:
>
> - compatible: For external switch chips, compatible string must be exactly one
> - of: "microchip,ksz9477"
> + of the following:
> + - "microchip,ksz9477"
> + - "microchip,ksz9897"
>
> See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
> required and optional properties.
> diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
> index 7210c49..54e0ca6 100644
> --- a/drivers/net/dsa/microchip/ksz_common.c
> +++ b/drivers/net/dsa/microchip/ksz_common.c
> @@ -1102,6 +1102,15 @@ static const struct ksz_chip_data ksz_switch_chips[] = {
> .cpu_ports = 0x7F, /* can be configured as cpu port */
> .port_cnt = 7, /* total physical port count */
> },
> + {
> + .chip_id = 0x00989700,
> + .dev_name = "KSZ9897",
> + .num_vlans = 4096,
> + .num_alus = 4096,
> + .num_statics = 16,
> + .cpu_ports = 0x7F, /* can be configured as cpu port */
> + .port_cnt = 7, /* total physical port count */
> + },
> };
>
> static int ksz_switch_init(struct ksz_device *dev)
> diff --git a/drivers/net/dsa/microchip/ksz_spi.c b/drivers/net/dsa/microchip/ksz_spi.c
> index c519469..8c1778b 100644
> --- a/drivers/net/dsa/microchip/ksz_spi.c
> +++ b/drivers/net/dsa/microchip/ksz_spi.c
> @@ -195,6 +195,7 @@ static int ksz_spi_remove(struct spi_device *spi)
>
> static const struct of_device_id ksz_dt_ids[] = {
> { .compatible = "microchip,ksz9477" },
> + { .compatible = "microchip,ksz9897" },
> {},
> };
> MODULE_DEVICE_TABLE(of, ksz_dt_ids);
>
--
Florian
^ permalink raw reply
* Re: [PATCH bpf] bpf: fix a rcu usage warning in bpf_prog_array_copy_core()
From: Daniel Borkmann @ 2018-08-16 0:17 UTC (permalink / raw)
To: Roman Gushchin, Alexei Starovoitov
Cc: Yonghong Song, ast, netdev, kernel-team
In-Reply-To: <20180815000841.GA25304@castle.DHCP.thefacebook.com>
On 08/15/2018 02:08 AM, Roman Gushchin wrote:
> On Tue, Aug 14, 2018 at 04:59:45PM -0700, Alexei Starovoitov wrote:
>> On Tue, Aug 14, 2018 at 11:01:12AM -0700, Yonghong Song wrote:
>>> Commit 394e40a29788 ("bpf: extend bpf_prog_array to store pointers
>>> to the cgroup storage") refactored the bpf_prog_array_copy_core()
>>> to accommodate new structure bpf_prog_array_item which contains
>>> bpf_prog array itself.
>>>
>>> In the old code, we had
>>> perf_event_query_prog_array():
>>> mutex_lock(...)
>>> bpf_prog_array_copy_call():
>>> prog = rcu_dereference_check(array, 1)->progs
>>> bpf_prog_array_copy_core(prog, ...)
>>> mutex_unlock(...)
>>>
>>> With the above commit, we had
>>> perf_event_query_prog_array():
>>> mutex_lock(...)
>>> bpf_prog_array_copy_call():
>>> bpf_prog_array_copy_core(array, ...):
>>> item = rcu_dereference(array)->items;
>>> ...
>>> mutex_unlock(...)
>>>
>>> The new code will trigger a lockdep rcu checking warning.
>>> The fix is to change rcu_dereference() to rcu_dereference_check()
>>> to prevent such a warning.
>>>
>>> Reported-by: syzbot+6e72317008eef84a216b@syzkaller.appspotmail.com
>>> Fixes: 394e40a29788 ("bpf: extend bpf_prog_array to store pointers to the cgroup storage")
>>> Cc: Roman Gushchin <guro@fb.com>
>>> Signed-off-by: Yonghong Song <yhs@fb.com>
Applied to bpf, thanks Yonghong!
^ permalink raw reply
* Re: [bpf PATCH] samples/bpf: all XDP samples should unload xdp/bpf prog on SIGTERM
From: Song Liu @ 2018-08-16 0:13 UTC (permalink / raw)
To: Y Song
Cc: Jesper Dangaard Brouer, Daniel Borkmann, Alexei Starovoitov,
netdev, jhsiao
In-Reply-To: <CAH3MdRWXNe2-Uuut+L-qUGW52Fv-dmtcmG=ayoqKPRxNOtFqXA@mail.gmail.com>
On Wed, Aug 15, 2018 at 8:47 AM, Y Song <ys114321@gmail.com> wrote:
> On Wed, Aug 15, 2018 at 7:57 AM, Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
>> It is common XDP practice to unload/deattach the XDP bpf program,
>> when the XDP sample program is Ctrl-C interrupted (SIGINT) or
>> killed (SIGTERM).
>>
>> The samples/bpf programs xdp_redirect_cpu and xdp_rxq_info,
>> forgot to trap signal SIGTERM (which is the default signal used
>> by the kill command).
>>
>> This was discovered by Red Hat QA, which automated scripts depend
>> on killing the XDP sample program after a timeout period.
>>
>> Fixes: fad3917e361b ("samples/bpf: add cpumap sample program xdp_redirect_cpu")
>> Fixes: 0fca931a6f21 ("samples/bpf: program demonstrating access to xdp_rxq_info")
>> Reported-by: Jean-Tsung Hsiao <jhsiao@redhat.com>
>> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
>
> Acked-by: Yonghong Song <yhs@fb.com>
Reviewed-by: Song Liu <songliubraving@fb.com>
>
>> ---
>> samples/bpf/xdp_redirect_cpu_user.c | 3 ++-
>> samples/bpf/xdp_rxq_info_user.c | 3 ++-
>> 2 files changed, 4 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [bpf PATCH] samples/bpf: all XDP samples should unload xdp/bpf prog on SIGTERM
From: Daniel Borkmann @ 2018-08-16 0:12 UTC (permalink / raw)
To: Y Song, Jesper Dangaard Brouer
Cc: Daniel Borkmann, Alexei Starovoitov, netdev, jhsiao
In-Reply-To: <CAH3MdRWXNe2-Uuut+L-qUGW52Fv-dmtcmG=ayoqKPRxNOtFqXA@mail.gmail.com>
On 08/15/2018 05:47 PM, Y Song wrote:
> On Wed, Aug 15, 2018 at 7:57 AM, Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
>> It is common XDP practice to unload/deattach the XDP bpf program,
>> when the XDP sample program is Ctrl-C interrupted (SIGINT) or
>> killed (SIGTERM).
>>
>> The samples/bpf programs xdp_redirect_cpu and xdp_rxq_info,
>> forgot to trap signal SIGTERM (which is the default signal used
>> by the kill command).
>>
>> This was discovered by Red Hat QA, which automated scripts depend
>> on killing the XDP sample program after a timeout period.
>>
>> Fixes: fad3917e361b ("samples/bpf: add cpumap sample program xdp_redirect_cpu")
>> Fixes: 0fca931a6f21 ("samples/bpf: program demonstrating access to xdp_rxq_info")
>> Reported-by: Jean-Tsung Hsiao <jhsiao@redhat.com>
>> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
>
> Acked-by: Yonghong Song <yhs@fb.com>
Applied to bpf, thanks Jesper!
^ permalink raw reply
* Re: [PATCH bpf-next V3] net/xdp: Fix suspicious RCU usage warning
From: Daniel Borkmann @ 2018-08-16 0:11 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Tariq Toukan
Cc: Alexei Starovoitov, netdev, Eran Ben Elisha, Neil Brown,
Paul E. McKenney
In-Reply-To: <55d5dbee-8065-ac05-6372-c220a97b486f@iogearbox.net>
On 08/13/2018 02:22 PM, Daniel Borkmann wrote:
[...]
> I'll get the patch in once it has been pulled.
Applied to bpf, thanks Tariq!
^ permalink raw reply
* [PATCH stable 4.4 9/9] tcp: add tcp_ooo_try_coalesce() helper
From: Mao Wenan @ 2018-08-16 2:50 UTC (permalink / raw)
To: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw; +Cc: stable
In-Reply-To: <1534387810-121428-1-git-send-email-maowenan@huawei.com>
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit 58152ecbbcc6a0ce7fddd5bf5f6ee535834ece0c ]
In case skb in out_or_order_queue is the result of
multiple skbs coalescing, we would like to get a proper gso_segs
counter tracking, so that future tcp_drop() can report an accurate
number.
I chose to not implement this tracking for skbs in receive queue,
since they are not dropped, unless socket is disconnected.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
net/ipv4/tcp_input.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 96a1e0d..fdb5509 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4296,6 +4296,23 @@ static bool tcp_try_coalesce(struct sock *sk,
return true;
}
+static bool tcp_ooo_try_coalesce(struct sock *sk,
+ struct sk_buff *to,
+ struct sk_buff *from,
+ bool *fragstolen)
+{
+ bool res = tcp_try_coalesce(sk, to, from, fragstolen);
+
+ /* In case tcp_drop() is called later, update to->gso_segs */
+ if (res) {
+ u32 gso_segs = max_t(u16, 1, skb_shinfo(to)->gso_segs) +
+ max_t(u16, 1, skb_shinfo(from)->gso_segs);
+
+ skb_shinfo(to)->gso_segs = min_t(u32, gso_segs, 0xFFFF);
+ }
+ return res;
+}
+
static void tcp_drop(struct sock *sk, struct sk_buff *skb)
{
sk_drops_add(sk, skb);
@@ -4422,7 +4439,8 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
/* In the typical case, we are adding an skb to the end of the list.
* Use of ooo_last_skb avoids the O(Log(N)) rbtree lookup.
*/
- if (tcp_try_coalesce(sk, tp->ooo_last_skb, skb, &fragstolen)) {
+ if (tcp_ooo_try_coalesce(sk, tp->ooo_last_skb,
+ skb, &fragstolen)) {
coalesce_done:
tcp_grow_window(sk, skb);
kfree_skb_partial(skb, fragstolen);
@@ -4467,7 +4485,8 @@ coalesce_done:
tcp_drop(sk, skb1);
goto add_sack;
}
- } else if (tcp_try_coalesce(sk, skb1, skb, &fragstolen)) {
+ } else if (tcp_ooo_try_coalesce(sk, skb1,
+ skb, &fragstolen)) {
goto coalesce_done;
}
p = &parent->rb_right;
--
1.8.3.1
^ permalink raw reply related
* [PATCH stable 4.4 5/9] tcp: free batches of packets in tcp_prune_ofo_queue()
From: Mao Wenan @ 2018-08-16 2:50 UTC (permalink / raw)
To: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw; +Cc: stable
In-Reply-To: <1534387810-121428-1-git-send-email-maowenan@huawei.com>
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit 72cd43ba64fc172a443410ce01645895850844c8 ]
Juha-Matti Tilli reported that malicious peers could inject tiny
packets in out_of_order_queue, forcing very expensive calls
to tcp_collapse_ofo_queue() and tcp_prune_ofo_queue() for
every incoming packet. out_of_order_queue rb-tree can contain
thousands of nodes, iterating over all of them is not nice.
Before linux-4.9, we would have pruned all packets in ofo_queue
in one go, every XXXX packets. XXXX depends on sk_rcvbuf and skbs
truesize, but is about 7000 packets with tcp_rmem[2] default of 6 MB.
Since we plan to increase tcp_rmem[2] in the future to cope with
modern BDP, can not revert to the old behavior, without great pain.
Strategy taken in this patch is to purge ~12.5 % of the queue capacity.
Fixes: 36a6503fedda ("tcp: refine tcp_prune_ofo_queue() to not drop all packets")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Juha-Matti Tilli <juha-matti.tilli@iki.fi>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
net/ipv4/tcp_input.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 12edc4f..32225dc 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4893,22 +4893,26 @@ static bool tcp_prune_ofo_queue(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
struct rb_node *node, *prev;
+ int goal;
if (RB_EMPTY_ROOT(&tp->out_of_order_queue))
return false;
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_OFOPRUNED);
-
+ goal = sk->sk_rcvbuf >> 3;
node = &tp->ooo_last_skb->rbnode;
do {
prev = rb_prev(node);
rb_erase(node, &tp->out_of_order_queue);
+ goal -= rb_to_skb(node)->truesize;
__kfree_skb(rb_to_skb(node));
- sk_mem_reclaim(sk);
- if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf &&
- !tcp_under_memory_pressure(sk))
- break;
-
+ if (!prev || goal <= 0) {
+ sk_mem_reclaim(sk);
+ if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf &&
+ !tcp_under_memory_pressure(sk))
+ break;
+ goal = sk->sk_rcvbuf >> 3;
+ }
node = prev;
} while (node);
tp->ooo_last_skb = rb_entry(prev, struct sk_buff, rbnode);
--
1.8.3.1
^ permalink raw reply related
* [PATCH stable 4.4 0/9] fix SegmentSmack in stable branch (CVE-2018-5390)
From: Mao Wenan @ 2018-08-16 2:50 UTC (permalink / raw)
To: dwmw2, gregkh, netdev, eric.dumazet, edumazet, davem, ycheng, jdw; +Cc: stable
There are five patches to fix CVE-2018-5390 in latest mainline
branch, but only two patches exist in stable 4.4 and 3.18:
dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
I have tested with stable 4.4 kernel, and found the cpu usage was very high.
So I think only two patches can't fix the CVE-2018-5390.
test results:
with fix patch： 78.2% ksoftirqd
withoutfix patch： 90% ksoftirqd
Then I try to imitate 72cd43ba(tcp: free batches of packets in tcp_prune_ofo_queue())
to drop at least 12.5 % of sk_rcvbuf to avoid malicious attacks with simple queue
instead of RB tree. The result is not very well.
After analysing the codes of stable 4.4, and debuging the
system, shows that search of ofo_queue(tcp ofo using a simple queue) cost more cycles.
So I try to backport "tcp: use an RB tree for ooo receive queue" using RB tree
instead of simple queue, then backport Eric Dumazet 5 fixed patches in mainline,
good news is that ksoftirqd is turn to about 20%, which is the same with mainline now.
Stable 4.4 have already back port two patches,
f4a3313d(tcp: avoid collapses in tcp_prune_queue() if possible)
3d4bf93a(tcp: detect malicious patterns in tcp_collapse_ofo_queue())
If we want to change simple queue to RB tree to finally resolve, we should apply previous
patch 9f5afeae(tcp: use an RB tree for ooo receive queue.) firstly, but 9f5afeae have many
conflicts with 3d4bf93a and f4a3313d, which are part of patch series from Eric in
mainline to fix CVE-2018-5390, so I need revert part of patches in stable 4.4 firstly,
then apply 9f5afeae, and reapply five patches from Eric.
Eric Dumazet (6):
tcp: increment sk_drops for dropped rx packets
tcp: free batches of packets in tcp_prune_ofo_queue()
tcp: avoid collapses in tcp_prune_queue() if possible
tcp: detect malicious patterns in tcp_collapse_ofo_queue()
tcp: call tcp_drop() from tcp_data_queue_ofo()
tcp: add tcp_ooo_try_coalesce() helper
Mao Wenan (2):
Revert "tcp: detect malicious patterns in tcp_collapse_ofo_queue()"
Revert "tcp: avoid collapses in tcp_prune_queue() if possible"
Yaogong Wang (1):
tcp: use an RB tree for ooo receive queue
include/linux/skbuff.h | 8 +
include/linux/tcp.h | 7 +-
include/net/sock.h | 7 +
include/net/tcp.h | 2 +-
net/core/skbuff.c | 19 +++
net/ipv4/tcp.c | 4 +-
net/ipv4/tcp_input.c | 412 +++++++++++++++++++++++++++++------------------
net/ipv4/tcp_ipv4.c | 3 +-
net/ipv4/tcp_minisocks.c | 1 -
net/ipv6/tcp_ipv6.c | 1 +
10 files changed, 294 insertions(+), 170 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: Alexei Starovoitov @ 2018-08-16 2:49 UTC (permalink / raw)
To: Jason Wang
Cc: David Ahern, Jesper Dangaard Brouer, netdev, linux-kernel, ast,
daniel, mst, Toshiaki Makita
In-Reply-To: <0809cbab-9c91-52f1-2abe-124a255d9304@redhat.com>
On Wed, Aug 15, 2018 at 03:04:35PM +0800, Jason Wang wrote:
>
> > > 3 Deliver XDP buff to userspace through macvtap.
> > I think I'm getting what you're trying to achieve.
> > You actually don't want any bpf programs in there at all.
> > You want macvlan builtin logic to act on raw packet frames.
>
> The built-in logic is just used to find the destination macvlan device. It
> could be done by through another bpf program. Instead of inventing lots of
> generic infrastructure on kernel with specific userspace API, built-in logic
> has its own advantages:
>
> - support hundreds or even thousands of macvlans
are you saying xdp bpf program cannot handle thousands macvlans?
> - using exist tools to configure network
> - immunity to topology changes
what do you mean specifically?
>
> Besides the usage for containers, we can implement macvtap RX handler which
> allows a fast packet forwarding to userspace.
and try to reinvent af_xdp? the motivation for the patchset still escapes me.
> Actually, the idea is not limited to macvlan but for all device that is
> based on rx handler. Consider the case of bonding, this allows to set a very
> simple XDP program on slaves and keep a single main logic XDP program on the
> bond instead of duplicating it in all slaves.
I think such mixed environment of hardcoded in-kernel things like bond
mixed together with xdp programs will be difficult to manage and debug.
How admin suppose to debug it? Say something in the chain of
nic -> native xdp -> bond with your xdp rx -> veth -> xdp prog -> consumer
is dropping a packet. If all forwarding decisions are done by bpf progs
the progs will have packet tracing facility (like cilium does) to
show packet flow end-to-end. It works briliantly like traceroute within a host.
But when you have things like macvlan, bond, bridge in the middle
that can also act on packet, the admin will have a hard time.
Essentially what you're proposing is to make all kernel builtin packet
steering/forwarding facilities to understand raw xdp frames. That's a lot of code
and at the end of the chain you'd need fast xdp frame consumer otherwise
perf benefits are lost. If that consumer is xdp bpf program
why bother with xdp-fied macvlan or bond? If that consumer is tcp stack
than forwarding via xdp-fied bond is no faster than via skb-based bond.
^ permalink raw reply
* Attention: E-mail Address Owner,
From: Mr. Bernard Otti @ 2018-08-15 23:45 UTC (permalink / raw)
To: netdev
Attention: E-mail Address Owner,
According to the meeting held with Federal Bureau of Investigation, The
International Monetary Fund (IMF) is compensating all the scam victims
and some email users which your name and email address was found on
the list.
However, we have concluded to effect your own payment through Western
Union Money Transfer, $5,000 daily until the total sum of $1.5 million
your compensation fund is transferred to you.
Here is your first payment informations:
MTCN#: 730-751-7703
Sender's First Name: Samuel
Sender's Last Name: Chukwuma
Text Question: Code?
Answer: ??
Amount Programmed: $5.000
Track your first payment on-line now with the below tracking website
and confirm it available now.
( https://www.westernunion.com/global-service/track-transfer )
You are advised to get back to the contact person trough the email
below for more direction on how to be receiving your payment
Thanks,
MR. Jerry Connor
Director Western Union Money Transfer,
Head Office Tyler Texas United States
^ permalink raw reply
* [PATCH iproute2] ipmaddr: use preferred_family when given
From: Mahesh Bandewar @ 2018-08-15 23:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
When creating socket() AF_INET is used irrespective of the family
that is given at the command-line (with -4, -6, or -0). This change
will open the socket with the preferred family.
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
ip/ipmaddr.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/ip/ipmaddr.c b/ip/ipmaddr.c
index a48499029e17..abf83784d0df 100644
--- a/ip/ipmaddr.c
+++ b/ip/ipmaddr.c
@@ -289,6 +289,7 @@ static int multiaddr_list(int argc, char **argv)
static int multiaddr_modify(int cmd, int argc, char **argv)
{
struct ifreq ifr = {};
+ int family;
int fd;
if (cmd == RTM_NEWADDR)
@@ -324,7 +325,17 @@ static int multiaddr_modify(int cmd, int argc, char **argv)
exit(-1);
}
- fd = socket(AF_INET, SOCK_DGRAM, 0);
+ switch (preferred_family) {
+ case AF_INET6:
+ case AF_PACKET:
+ case AF_INET:
+ family = preferred_family;
+ break;
+ default:
+ family = AF_INET;
+ }
+
+ fd = socket(family, SOCK_DGRAM, 0);
if (fd < 0) {
perror("Cannot create socket");
exit(1);
--
2.18.0.865.gffc8e1a3cd6-goog
^ permalink raw reply related
* Re: virtio_net failover and initramfs (was: Re: [PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework)
From: Siwei Liu @ 2018-08-15 22:17 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: Jiri Pirko, initramfs, Michael S. Tsirkin, Netdev,
vijay.balakrishna, si-wei liu, liran.alon
In-Reply-To: <58f1f440-2bf9-1436-c987-95f331ce9990@intel.com>
On Wed, Aug 15, 2018 at 12:05 PM, Samudrala, Sridhar
<sridhar.samudrala@intel.com> wrote:
> On 8/14/2018 5:03 PM, Siwei Liu wrote:
>>
>> Are we sure all userspace apps skip and ignore slave interfaces by
>> just looking at "IFLA_MASTER" attribute?
>>
>> When STANDBY is enabled on virtio-net, a failover master interface
>> will appear, which automatically enslaves the virtio device. But it is
>> found out that iSCSI (or any network boot) cannot boot strap over the
>> new failover interface together with a standby virtio (without any VF
>> or PT device in place).
>>
>> Dracut (initramfs) ends up with timeout and dropping into emergency shell:
>>
>> [ 228.170425] dracut-initqueue[377]: Warning: dracut-initqueue
>> timeout - starting timeout scripts
>> [ 228.171788] dracut-initqueue[377]: Warning: Could not boot.
>> Starting Dracut Emergency Shell...
>> Generating "/run/initramfs/rdsosreport.txt"
>> Entering emergency mode. Exit the shell to continue.
>> Type "journalctl" to view system logs.
>> You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or
>> /boot
>> after mounting them and attach it to a bug report.
>> dracut:/# ip l sh
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>> mode DEFAULT group default qlen 1000
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
>> state UP mode DEFAULT group default qlen 1000
>> link/ether 9a:46:22:ae:33:54 brd ff:ff:ff:ff:ff:ff\
>> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>> master eth0 state UP mode DEFAULT group default qlen 1000
>> link/ether 9a:46:22:ae:33:54 brd ff:ff:ff:ff:ff:ff
>> dracut:/#
>>
>> If changing dracut code to ignore eth1 (with IFLA_MASTER attr),
>> network boot starts to work.
>
>
> Does dracut by default tries to use all the interfaces that are UP?
>
Yes. The specific dracut cmdline of our case is "ip=dhcp
netroot=iscsi:... ", but it's not specific to iscsi boot. And because
of same MAC address for failover and standby, while dracut tries to
run DHCP on all interfaces that are up it eventually gets same route
for each interface. Those conflict route entries kill off the network
connection.
>
>>
>> The reason is that dracut has its own means to differentiate virtual
>> interfaces for network boot: it does not look at IFLA_MASTER and
>> ignores slave interfaces. Instead, users have to provide explicit
>> option e.g. bond=eth0,eth1 in the boot line, then dracut would know
>> the config and ignore the slave interfaces.
>
>
> Isn't it possible to specify the interface that should be used for network
> boot?
As I understand it, one can only specify interface name for running
DHCP but not select interface for network boot. We want DHCP to run
on every NIC that is up (excluding the enslaved interfaces), and only
one of them can get a route entry to the network boot server (ie.g.
iSCSI target).
>
>
>>
>> However, with automatic creation of failover interface that assumption
>> is no longer true. Can we change dracut to ignore all slave interface
>> by checking IFLA_MASTER? I don't think so. It has a large impact to
>> existing configs.
>
>
> What is the issue with checking for IFLA_MASTER? I guess this is used with
> team/bonding setups.
That should be discussed within and determined by the dracut
community. But the current dracut code doesn't check IFLA_MASTER for
team or bonding specifically. I guess this change might have broader
impact to existing userspace that might be already relying on the
current behaviour.
Thanks,
-Siwei
>
>
>>
>> What's a feasible solution then? Check the driver name for failover as
>> well?
>>
>> Thanks,
>> -Siwei
>>
>>
>>
>> On Tue, May 22, 2018 at 10:38 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>
>>> Tue, May 22, 2018 at 06:52:21PM CEST, mst@redhat.com wrote:
>>>>
>>>> On Tue, May 22, 2018 at 05:45:01PM +0200, Jiri Pirko wrote:
>>>>>
>>>>> Tue, May 22, 2018 at 05:32:30PM CEST, mst@redhat.com wrote:
>>>>>>
>>>>>> On Tue, May 22, 2018 at 05:13:43PM +0200, Jiri Pirko wrote:
>>>>>>>
>>>>>>> Tue, May 22, 2018 at 03:39:33PM CEST, mst@redhat.com wrote:
>>>>>>>>
>>>>>>>> On Tue, May 22, 2018 at 03:26:26PM +0200, Jiri Pirko wrote:
>>>>>>>>>
>>>>>>>>> Tue, May 22, 2018 at 03:17:37PM CEST, mst@redhat.com wrote:
>>>>>>>>>>
>>>>>>>>>> On Tue, May 22, 2018 at 03:14:22PM +0200, Jiri Pirko wrote:
>>>>>>>>>>>
>>>>>>>>>>> Tue, May 22, 2018 at 03:12:40PM CEST, mst@redhat.com wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, May 22, 2018 at 11:08:53AM +0200, Jiri Pirko wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tue, May 22, 2018 at 11:06:37AM CEST, jiri@resnulli.us wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tue, May 22, 2018 at 04:06:18AM CEST,
>>>>>>>>>>>>>> sridhar.samudrala@intel.com wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Use the registration/notification framework supported by the
>>>>>>>>>>>>>>> generic
>>>>>>>>>>>>>>> failover infrastructure.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Sridhar Samudrala
>>>>>>>>>>>>>>> <sridhar.samudrala@intel.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In previous patchset versions, the common code did
>>>>>>>>>>>>>> netdev_rx_handler_register() and netdev_upper_dev_link() etc
>>>>>>>>>>>>>> (netvsc_vf_join()). Now, this is still done in netvsc. Why?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This should be part of the common "failover" code.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Also note that in the current patchset you use IFF_FAILOVER
>>>>>>>>>>>>> flag for
>>>>>>>>>>>>> master, yet for the slave you use IFF_SLAVE. That is wrong.
>>>>>>>>>>>>> IFF_FAILOVER_SLAVE should be used.
>>>>>>>>>>>>
>>>>>>>>>>>> Or drop IFF_FAILOVER_SLAVE and set both IFF_FAILOVER and
>>>>>>>>>>>> IFF_SLAVE?
>>>>>>>>>>>
>>>>>>>>>>> No. IFF_SLAVE is for bonding.
>>>>>>>>>>
>>>>>>>>>> What breaks if we reuse it for failover?
>>>>>>>>>
>>>>>>>>> This is exposed to userspace. IFF_SLAVE is expected for bonding
>>>>>>>>> slaves.
>>>>>>>>> And failover slave is not a bonding slave.
>>>>>>>>
>>>>>>>> That does not really answer the question. I'd claim it's
>>>>>>>> sufficiently
>>>>>>>> like a bond slave for IFF_SLAVE to make sense.
>>>>>>>>
>>>>>>>> In fact you will find that netvsc already sets IFF_SLAVE, and so
>>>>>>>
>>>>>>> netvsc does the whole failover thing in a wrong way. This patchset is
>>>>>>> trying to fix it.
>>>>>>
>>>>>> Maybe, but we don't need gratuitous changes either, especially if they
>>>>>> break userspace.
>>>>>
>>>>> What do you mean by the "break"? It was a mistake to reuse IFF_SLAVE at
>>>>> the first place, lets fix it. If some userspace depends on that flag,
>>>>> it
>>>>> is broken anyway.
>>>>>
>>>>>
>>>>>>>> does e.g. the eql driver.
>>>>>>>>
>>>>>>>> The advantage of using IFF_SLAVE is that userspace knows to skip it.
>>>>>>>> If
>>>>>>>
>>>>>>> The userspace should know how to skip other types of slaves - team,
>>>>>>> bridge, ovs, etc.
>>>>>>> The "master link" should be the one to look at.
>>>>>>>
>>>>>> How should existing userspace know which ones to skip and which one is
>>>>>> the master? Right now userspace seems to assume whatever does not
>>>>>> have
>>>>>> IFF_SLAVE should be looked at. Are you saying that's not the right
>>>>>> thing
>>>>>
>>>>> Why do you say so? What do you mean by "looked at"? Certainly not.
>>>>> IFLA_MASTER is the attribute that should be looked at, nothing else.
>>>>>
>>>>>
>>>>>> to do and userspace should be fixed? What should userspace do in
>>>>>> your opinion that will be forward compatible with future kernels?
>>>>>>
>>>>>>>> we don't set IFF_SLAVE existing userspace tries to use the lowerdev.
>>>>>>>
>>>>>>> Each master type has a IFF_ master flag and IFF_ slave flag.
>>>>>>
>>>>>> Could you give some examples please?
>>>>>
>>>>> enum netdev_priv_flags {
>>>>> IFF_EBRIDGE = 1<<1,
>>>>> IFF_BRIDGE_PORT = 1<<9,
>>>>> IFF_OPENVSWITCH = 1<<20,
>>>>> IFF_OVS_DATAPATH = 1<<10,
>>>>> IFF_L3MDEV_MASTER = 1<<18,
>>>>> IFF_L3MDEV_SLAVE = 1<<21,
>>>>> IFF_TEAM = 1<<22,
>>>>> IFF_TEAM_PORT = 1<<13,
>>>>> };
>>>>
>>>> That's not in uapi, is it? the comment above that says:
>>>
>>> Correct.
>>>
>>>
>>>> These flags are invisible to userspace
>>>>
>>>>
>>>>
>>>>>>> In private
>>>>>>> flag. I don't see no reason to break this pattern here.
>>>>>>
>>>>>> Other masters are setup from userspace, this one is set up
>>>>>> automatically
>>>>>> by kernel. So the bar is higher, we need an interface that existing
>>>>>> userspace knows about. We can't just say "oh if userspace set this up
>>>>>> it should know to skip lowerdevs".
>>>>>>
>>>>>> Otherwise multiple interfaces with same mac tend to confuse userspace.
>>>>>
>>>>> No difference, really.
>>>>> Regardless who does the setup, and independent userspace deamon should
>>>>> react accordingly.
>>>>
>>>> If the deamon does the setup itself, it's reasonable to require that it
>>>> learns about new flags each time we add a new driver. If it doesn't,
>>>> then I think it's less reasonable.
>>>
>>> No need. The "IFLA_MASTER" attr is always there to be looked at. That is
>>> enough.
>
>
^ permalink raw reply
* Re: [PATCH bpf] bpf: fix a rcu usage warning in bpf_prog_array_copy_core()
From: Roman Gushchin @ 2018-08-15 21:37 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: Yonghong Song, ast, daniel, netdev, kernel-team
In-Reply-To: <20180815213009.t2nhtoxlqpd2sgk4@ast-mbp>
On Wed, Aug 15, 2018 at 02:30:11PM -0700, Alexei Starovoitov wrote:
> On Tue, Aug 14, 2018 at 05:08:44PM -0700, Roman Gushchin wrote:
> > On Tue, Aug 14, 2018 at 04:59:45PM -0700, Alexei Starovoitov wrote:
> > > On Tue, Aug 14, 2018 at 11:01:12AM -0700, Yonghong Song wrote:
> > > > Commit 394e40a29788 ("bpf: extend bpf_prog_array to store pointers
> > > > to the cgroup storage") refactored the bpf_prog_array_copy_core()
> > > > to accommodate new structure bpf_prog_array_item which contains
> > > > bpf_prog array itself.
> > > >
> > > > In the old code, we had
> > > > perf_event_query_prog_array():
> > > > mutex_lock(...)
> > > > bpf_prog_array_copy_call():
> > > > prog = rcu_dereference_check(array, 1)->progs
> > > > bpf_prog_array_copy_core(prog, ...)
> > > > mutex_unlock(...)
> > > >
> > > > With the above commit, we had
> > > > perf_event_query_prog_array():
> > > > mutex_lock(...)
> > > > bpf_prog_array_copy_call():
> > > > bpf_prog_array_copy_core(array, ...):
> > > > item = rcu_dereference(array)->items;
> > > > ...
> > > > mutex_unlock(...)
> > > >
> > > > The new code will trigger a lockdep rcu checking warning.
> > > > The fix is to change rcu_dereference() to rcu_dereference_check()
> > > > to prevent such a warning.
> > > >
> > > > Reported-by: syzbot+6e72317008eef84a216b@syzkaller.appspotmail.com
> > > > Fixes: 394e40a29788 ("bpf: extend bpf_prog_array to store pointers to the cgroup storage")
> > > > Cc: Roman Gushchin <guro@fb.com>
> > > > Signed-off-by: Yonghong Song <yhs@fb.com>
> > >
> > > makes sense to me
> > > Acked-by: Alexei Starovoitov <ast@kernel.org>
> > >
> > > Roman, would you agree?
> > >
> >
> > rcu_dereference_check(<>, 1) always looks a bit strange to me,
> > but if it's the only reasonable way to silence the warning,
> > of course I'm fine with it.
>
> do you have better suggestion?
> This patch is a fix for the regression introduced in your earlier patch,
> so I think the only fair path forward is either to Ack it or
> to send an alternative patch asap.
>
As I said, I've nothing against.
Acked-by: Roman Gushchin <guro@fb.com>
Thanks!
^ permalink raw reply
* Re: [iproute PATCH 0/3] Fix and test ssfilter
From: Stephen Hemminger @ 2018-08-15 21:33 UTC (permalink / raw)
To: Phil Sutter; +Cc: netdev, Samuel Mannehed
In-Reply-To: <20180814121808.24774-1-phil@nwl.cc>
On Tue, 14 Aug 2018 14:18:05 +0200
Phil Sutter <phil@nwl.cc> wrote:
> This series contains a fix for ssfilter and introduces a testscript to
> verify correct functionality.
>
> Phil Sutter (3):
> ss: Review ssfilter
> testsuite: Prepare for ss tests
> testsuite: Add a first ss test validating ssfilter
>
> misc/ssfilter.y | 36 ++++++++++++++-----------
> testsuite/Makefile | 2 +-
> testsuite/lib/generic.sh | 37 ++++++++++----------------
> testsuite/tests/ss/ss1.dump | Bin 0 -> 720 bytes
> testsuite/tests/ss/ssfilter.t | 48 ++++++++++++++++++++++++++++++++++
> 5 files changed, 84 insertions(+), 39 deletions(-)
> create mode 100644 testsuite/tests/ss/ss1.dump
> create mode 100755 testsuite/tests/ss/ssfilter.t
>
Applied
^ permalink raw reply
* Re: [iproute PATCH] man: ip-route: Clarify referenced versions are Linux ones
From: Stephen Hemminger @ 2018-08-15 21:33 UTC (permalink / raw)
To: Phil Sutter; +Cc: netdev
In-Reply-To: <20180815091826.18457-1-phil@nwl.cc>
On Wed, 15 Aug 2018 11:18:26 +0200
Phil Sutter <phil@nwl.cc> wrote:
> Versioning scheme of Linux and iproute2 is similar, therefore the
> referenced kernel versions are likely to confuse readers. Clarify this
> by prefixing each kernel version by 'Linux' prefix.
>
Sure, makes sense applied.
^ permalink raw reply
* Re: [PATCH bpf] bpf: fix a rcu usage warning in bpf_prog_array_copy_core()
From: Alexei Starovoitov @ 2018-08-15 21:30 UTC (permalink / raw)
To: Roman Gushchin; +Cc: Yonghong Song, ast, daniel, netdev, kernel-team
In-Reply-To: <20180815000841.GA25304@castle.DHCP.thefacebook.com>
On Tue, Aug 14, 2018 at 05:08:44PM -0700, Roman Gushchin wrote:
> On Tue, Aug 14, 2018 at 04:59:45PM -0700, Alexei Starovoitov wrote:
> > On Tue, Aug 14, 2018 at 11:01:12AM -0700, Yonghong Song wrote:
> > > Commit 394e40a29788 ("bpf: extend bpf_prog_array to store pointers
> > > to the cgroup storage") refactored the bpf_prog_array_copy_core()
> > > to accommodate new structure bpf_prog_array_item which contains
> > > bpf_prog array itself.
> > >
> > > In the old code, we had
> > > perf_event_query_prog_array():
> > > mutex_lock(...)
> > > bpf_prog_array_copy_call():
> > > prog = rcu_dereference_check(array, 1)->progs
> > > bpf_prog_array_copy_core(prog, ...)
> > > mutex_unlock(...)
> > >
> > > With the above commit, we had
> > > perf_event_query_prog_array():
> > > mutex_lock(...)
> > > bpf_prog_array_copy_call():
> > > bpf_prog_array_copy_core(array, ...):
> > > item = rcu_dereference(array)->items;
> > > ...
> > > mutex_unlock(...)
> > >
> > > The new code will trigger a lockdep rcu checking warning.
> > > The fix is to change rcu_dereference() to rcu_dereference_check()
> > > to prevent such a warning.
> > >
> > > Reported-by: syzbot+6e72317008eef84a216b@syzkaller.appspotmail.com
> > > Fixes: 394e40a29788 ("bpf: extend bpf_prog_array to store pointers to the cgroup storage")
> > > Cc: Roman Gushchin <guro@fb.com>
> > > Signed-off-by: Yonghong Song <yhs@fb.com>
> >
> > makes sense to me
> > Acked-by: Alexei Starovoitov <ast@kernel.org>
> >
> > Roman, would you agree?
> >
>
> rcu_dereference_check(<>, 1) always looks a bit strange to me,
> but if it's the only reasonable way to silence the warning,
> of course I'm fine with it.
do you have better suggestion?
This patch is a fix for the regression introduced in your earlier patch,
so I think the only fair path forward is either to Ack it or
to send an alternative patch asap.
^ permalink raw reply
* [PATCH 2/2] ipmonitor: decode DELNETCONF message
From: Stephen Hemminger @ 2018-08-15 21:29 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, Stephen Hemminger
In-Reply-To: <20180815212942.25276-1-stephen@networkplumber.org>
From: Stephen Hemminger <sthemmin@microsoft.com>
When device is deleted DELNETCONF is sent, but ipmonitor
was unable to decode it.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
ip/ipmonitor.c | 1 +
ip/ipnetconf.c | 6 +++++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/ip/ipmonitor.c b/ip/ipmonitor.c
index 5552d98ee9e5..a93b62cd6624 100644
--- a/ip/ipmonitor.c
+++ b/ip/ipmonitor.c
@@ -133,6 +133,7 @@ static int accept_msg(const struct sockaddr_nl *who,
return 0;
case RTM_NEWNETCONF:
+ case RTM_DELNETCONF:
print_headers(fp, "[NETCONF]", ctrl);
print_netconf(who, ctrl, n, arg);
return 0;
diff --git a/ip/ipnetconf.c b/ip/ipnetconf.c
index 03f98ace9145..afce982ced37 100644
--- a/ip/ipnetconf.c
+++ b/ip/ipnetconf.c
@@ -66,7 +66,8 @@ int print_netconf(const struct sockaddr_nl *who, struct rtnl_ctrl_data *ctrl,
if (n->nlmsg_type == NLMSG_ERROR)
return -1;
- if (n->nlmsg_type != RTM_NEWNETCONF) {
+
+ if (n->nlmsg_type != RTM_NEWNETCONF && n->nlmsg_type != RTM_DELNETCONF) {
fprintf(stderr, "Not RTM_NEWNETCONF: %08x %08x %08x\n",
n->nlmsg_len, n->nlmsg_type, n->nlmsg_flags);
@@ -91,6 +92,9 @@ int print_netconf(const struct sockaddr_nl *who, struct rtnl_ctrl_data *ctrl,
return 0;
open_json_object(NULL);
+ if (n->nlmsg_type == RTM_DELNETCONF)
+ print_bool(PRINT_ANY, "deleted", "Deleted ", true);
+
print_string(PRINT_ANY, "family",
"%s ", family_name(ncm->ncm_family));
--
2.18.0
^ permalink raw reply related
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