* [PATCH V2] netlink: Add netns check on taps
From: Kevin Cernekee @ 2017-12-06 20:12 UTC (permalink / raw)
To: davem; +Cc: johannes.berg, netdev, linux-kernel, daniel, dsahern
Currently, a nlmon link inside a child namespace can observe systemwide
netlink activity. Filter the traffic so that nlmon can only sniff
netlink messages from its own netns.
Test case:
vpnns -- bash -c "ip link add nlmon0 type nlmon; \
ip link set nlmon0 up; \
tcpdump -i nlmon0 -q -w /tmp/nlmon.pcap -U" &
sudo ip xfrm state add src 10.1.1.1 dst 10.1.1.2 proto esp \
spi 0x1 mode transport \
auth sha1 0x6162633132330000000000000000000000000000 \
enc aes 0x00000000000000000000000000000000
grep --binary abc123 /tmp/nlmon.pcap
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
---
net/netlink/af_netlink.c | 3 +++
1 file changed, 3 insertions(+)
V1->V2: Drop the special exception for init_net.
Compile-tested only, will retest later today.
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index b9e0ee4..79cc1bf 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -253,6 +253,9 @@ static int __netlink_deliver_tap_skb(struct sk_buff *skb,
struct sock *sk = skb->sk;
int ret = -ENOMEM;
+ if (!net_eq(dev_net(dev), sock_net(sk)))
+ return 0;
+
dev_hold(dev);
if (is_vmalloc_addr(skb->head))
--
2.7.4
^ permalink raw reply related
* Re: [patch net-next] mlxsw: spectrum: handle NETIF_F_HW_TC changes correctly
From: David Miller @ 2017-12-06 20:11 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, mlxsw
In-Reply-To: <20171206084112.2727-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 6 Dec 2017 09:41:12 +0100
> From: Jiri Pirko <jiri@mellanox.com>
>
> Currently, whenever the NETIF_F_HW_TC feature changes, we silently
> always allow it, but we actually do not disable the flows in HW
> on disable. That breaks user's expectations. So just forbid
> the feature disable in case there are any filters offloaded.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH] xen-netback: Fix logging message with spurious period after newline
From: David Miller @ 2017-12-06 20:10 UTC (permalink / raw)
To: joe; +Cc: wei.liu2, paul.durrant, xen-devel, netdev, linux-kernel
In-Reply-To: <7884b866cbeba808b63d9de871ace53970561f41.1512542267.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Tue, 5 Dec 2017 22:40:25 -0800
> Using a period after a newline causes bad output.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tun: avoid unnecessary READ_ONCE in tun_net_xmit
From: David Miller @ 2017-12-06 20:09 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, jasowang, willemb
In-Reply-To: <20171206031117.86588-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Tue, 5 Dec 2017 22:11:17 -0500
> From: Willem de Bruijn <willemb@google.com>
>
> The statement no longer serves a purpose.
>
> Commit fa35864e0bb7 ("tuntap: Fix for a race in accessing numqueues")
> added the ACCESS_ONCE to avoid a race condition with skb_queue_len.
>
> Commit 436accebb530 ("tuntap: remove unnecessary sk_receive_queue
> length check during xmit") removed the affected skb_queue_len check.
>
> Commit 96f84061620c ("tun: add eBPF based queue selection method")
> split the function, reading the field a second time in the callee.
> The temp variable is now only read once, so just remove it.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied, thanks Willem.
^ permalink raw reply
* Re: [PATCH/RFC v2] leds: trigger: Introduce a NETDEV trigger
From: Ben Whitten @ 2017-12-06 20:07 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: rpurdie, pavel, linux-leds, linux-kernel, netdev
In-Reply-To: <6cad314f-3cef-ec74-b55e-cccae28da4ab@gmail.com>
Hi Jacek,
On 5 December 2017 at 20:38, Jacek Anaszewski
<jacek.anaszewski@gmail.com> wrote:
> Hi Ben,
>
> On 12/05/2017 12:19 PM, Ben Whitten wrote:
>> From: Ben Whitten <ben.whitten@gmail.com>
>>
>> The patch was converted to led_blink_oneshot, in doing so we find that the
>> behaviour has changed. As I dont want to break 'userspace' led behaviour this
>> patch shouldn't be merged as is. Open to suggestions.
>>
>> Given an interval of 50ms and heavy throughput, the previous implementation
>> produced a blink with 100ms period and 50% dutycycle. The led_blink_oneshot
>> version produces a blink with 140ms period and 57% dutycycle.
>
> Please check if the LED class driver you're testing the trigger with
> implements blink_set op. If yes it would be good to check if it doesn't
> align the delay intervals to the hardware capabilities instead of
> failing and relying on a LED core software blink fallback.
The led are using gpio-led set from device tree on an embedded system, sama5
based. So as far as I can tell blink_op is NULL in this case and it
then relies on
software for the blink in the form of timers.
I assume its the jiffies playing a part here, taking a jiffy or two to
queue up a flash
may add 10ms to the desired 50ms delay_on/delay_off that I am seeing. Then the
extra time may be due to the stats workqueue not aligning with the
blink timer to
kick it off again.
Best regards,
Ben
^ permalink raw reply
* Re: [PATCH] ARM64: dts: meson-axg: add ethernet mac controller
From: Kevin Hilman @ 2017-12-06 20:07 UTC (permalink / raw)
To: Yixun Lan
Cc: devicetree, Neil Armstrong, Jerome Brunet, Giuseppe Cavallaro,
Alexandre Torgue, Carlo Caione, linux-amlogic, linux-arm-kernel,
linux-kernel, netdev
In-Reply-To: <20171113080155.2463-1-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> Add DT info for the stmmac ethernet MAC which found in
> the Amlogic's Meson-AXG SoC, also describe the ethernet
> pinctrl & clock information here.
>
> This is tested in the S400 dev board which use a RTL8211F PHY,
> and the pins connect to the 'eth_rgmii_y_pins' group.
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
This doesn't apply cleanly to mainline. Are there some dependencies
here that I'm not aware of?
Also...
> ---
> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 ++++
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 53 ++++++++++++++++++++++++++
> 2 files changed, 60 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index 9eb6aaee155d..7b39a9fe2b0f 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> @@ -21,3 +21,10 @@
> status = "okay";
> };
>
> +ðmac {
> + status = "okay";
> + phy-mode = "rgmii";
> +
> + pinctrl-0 = <ð_rgmii_y_pins>;
> + pinctrl-names = "default";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index 65945c6c8b65..57faaa9d8013 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -157,6 +157,19 @@
> #address-cells = <0>;
> };
>
> + ethmac: ethernet@ff3f0000 {
> + compatible = "amlogic,meson-axg-dwmac", "amlogic,meson-gxbb-dwmac", "snps,dwmac";
The new "meson-axg-dwmac" is not documented in the binding. Can you add
that?
Kevin
^ permalink raw reply
* Re: [PATCH net-next] rds: debug: fix null check on static array
From: David Miller @ 2017-12-06 20:03 UTC (permalink / raw)
To: bhole_prashant_q7-Zyj7fXuS5i5L9jVzuh4AOg
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g
In-Reply-To: <20171206014704.3796-1-bhole_prashant_q7-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
From: Prashant Bhole <bhole_prashant_q7-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
Date: Wed, 6 Dec 2017 10:47:04 +0900
> t_name cannot be NULL since it is an array field of a struct.
> Replacing null check on static array with string length check using
> strnlen()
>
> Signed-off-by: Prashant Bhole <bhole_prashant_q7-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
Applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] tcp: use current time in tcp_rcv_space_adjust()
From: Neal Cardwell @ 2017-12-06 19:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Wei Wang, Yuchung Cheng
In-Reply-To: <1512587299.25033.11.camel@gmail.com>
On Wed, Dec 6, 2017 at 2:08 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> When I switched rcv_rtt_est to high resolution timestamps, I forgot
> that tp->tcp_mstamp needed to be refreshed in tcp_rcv_space_adjust()
>
> Using an old timestamp leads to autotuning lags.
>
> Fixes: 645f4c6f2ebd ("tcp: switch rcv_rtt_est and rcvq_space to high resolution timestamps")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Wei Wang <weiwan@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> ---
Acked-by: Neal Cardwell <ncardwell@google.com>
neal
^ permalink raw reply
* Re: [Patch net-next v2] act_mirred: get rid of tcfm_ifindex from struct tcf_mirred
From: David Miller @ 2017-12-06 19:51 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, jiri, jhs
In-Reply-To: <20171206001727.25731-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 5 Dec 2017 16:17:26 -0800
> tcfm_dev always points to the correct netdev and we already
> hold a refcnt, so no need to use tcfm_ifindex to lookup again.
>
> If we would support moving target netdev across netns, using
> pointer would be better than ifindex.
>
> This also fixes dumping obsolete ifindex, now after the
> target device is gone we just dump 0 as ifindex.
>
> Cc: Jiri Pirko <jiri@mellanox.com>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Both act_mirred patches applied, thanks Cong.
^ permalink raw reply
* Re: [PATCH net-next 0/2] add ip6erspan collect_md mode
From: David Miller @ 2017-12-06 19:45 UTC (permalink / raw)
To: u9012063; +Cc: netdev
In-Reply-To: <1512515745-21003-1-git-send-email-u9012063@gmail.com>
From: William Tu <u9012063@gmail.com>
Date: Tue, 5 Dec 2017 15:15:43 -0800
> Similar to erspan collect_md mode in ipv4, the first patch adds
> support for ip6erspan collect metadata mode. The second patch
> adds the test case using bpf_skb_[gs]et_tunnel_key helpers.
>
> The corresponding iproute2 patch:
> https://marc.info/?l=linux-netdev&m=151251545410047&w=2
Series applied, thanks William.
^ permalink raw reply
* Re: [PATCH net] net: thunderx: Fix TCP/UDP checksum offload for IPv4 pkts
From: David Miller @ 2017-12-06 19:44 UTC (permalink / raw)
To: fw; +Cc: netdev, sgoutham, aleksey.makarov, edumazet
In-Reply-To: <20171206000450.20729-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 6 Dec 2017 01:04:50 +0100
> Offload IP header checksum to NIC.
>
> This fixes a previous patch which disabled checksum offloading
> for both IPv4 and IPv6 packets. So L3 checksum offload was
> getting disabled for IPv4 pkts. And HW is dropping these pkts
> for some reason.
>
> Without this patch, IPv4 TSO appears to be broken:
>
> WIthout this patch I get ~16kbyte/s, with patch close to 2mbyte/s
> when copying files via scp from test box to my home workstation.
>
> Looking at tcpdump on sender it looks like hardware drops IPv4 TSO skbs.
> This patch restores performance for me, ipv6 looks good too.
>
> Fixes: fa6d7cb5d76c ("net: thunderx: Fix TCP/UDP checksum offload for IPv6 pkts")
> Cc: Sunil Goutham <sgoutham@cavium.com>
> Cc: Aleksey Makarov <aleksey.makarov@auriga.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied and queued up for -stable, thanks Florian.
^ permalink raw reply
* Re: [PATCH] netlink: Add netns check on taps
From: David Miller @ 2017-12-06 19:40 UTC (permalink / raw)
To: cernekee; +Cc: johannes.berg, netdev, linux-kernel, daniel
In-Reply-To: <1512513982-20407-1-git-send-email-cernekee@chromium.org>
From: Kevin Cernekee <cernekee@chromium.org>
Date: Tue, 5 Dec 2017 14:46:22 -0800
> Currently, a nlmon link inside a child namespace can observe systemwide
> netlink activity. Filter the traffic so that in a non-init netns,
> nlmon can only sniff netlink messages from its own netns.
>
> Test case:
>
> vpnns -- bash -c "ip link add nlmon0 type nlmon; \
> ip link set nlmon0 up; \
> tcpdump -i nlmon0 -q -w /tmp/nlmon.pcap -U" &
> sudo ip xfrm state add src 10.1.1.1 dst 10.1.1.2 proto esp \
> spi 0x1 mode transport \
> auth sha1 0x6162633132330000000000000000000000000000 \
> enc aes 0x00000000000000000000000000000000
> grep abc123 /tmp/nlmon.pcap
>
> Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Daniel, what behavior did you intend this to have?
Taps can see their own namespace only, or init_net is special
and can see all netlink activity.
I think letting init_net see everything could be confusing,
because there is no way to distinguish netlink events by
namespace just by looking at the messages that arrive at
the tap right?
So maybe own-namespace-only is the way to go.
Thanks.
^ permalink raw reply
* RE: dsa: dsa_slave_port_obj_del calls multiple times with SWITCHDEV_OBJ_ID_HOST_MDB obj id
From: Tristram.Ha @ 2017-12-06 19:31 UTC (permalink / raw)
To: andrew; +Cc: f.fainelli, netdev, UNGLinuxDriver
In-Reply-To: <20171206135619.GE27063@lunn.ch>
> SWITCHDEV_OBJ_ID_HOST_MDB is used, when there is a join/leave on the
> bridge interface. It happens for each interface in the bridge, and it
> means, packets which match the group that ingress on that interface
> should be forwarded to the CPU.
>
> > As the base driver cannot find an entry with that host port, it returns an
> error
> > and so users will see a lot of failures from the DSA switch.
>
> You have a few options:
>
> 1) Just forward all multicast traffic to the cpu, and ignore
> SWITCHDEV_OBJ_ID_HOST_MDB.
>
> 2) Implement SWITCHDEV_OBJ_ID_HOST_MDB so you setup your tables to
> just forward the requested multicast to the cpu.
>
> 3) You can also forward a bit too much, e.g. if you cannot set filters
> per ingress port, just send all the traffic for the group from any
> port.
>
>
> The bridge will discard whatever it does not need.
>
> > Is this a new behavior and the driver needs to handle that? In previous
> versions
> > I do not think I saw that.
>
> SWITCHDEV_OBJ_ID_HOST_MDB is new. However,
> dsa_slave_port_obj_del()
> can be called for all sorts of objects, and you should only be
> reacting on those your support. So adding a new object should not of
> changed anything.
>
> > Typical operation is a PC connected to a port in a switch wants to send
> multicast
> > packets. It broadcasts an IGMP membership join message. Function
> > dsa_slave_port_obj_add is called to setup an entry in the lookup table.
> When
> > IGMP membership leave message is received dsa_slave_port_obj_del will
> be
> > called after a delay. But then it is called for each port with host port as the
> > parameter.
>
> Correct. switchdev is a generic API. It also needs to work for Top of
> Rack switches, which generally have a match/action architecture. I can
> imagine that this match/action happens per port, so we need to call
> switchdev per port. However, switches supported by DSA tend to have
> central management of all ports, so one call would be sufficient. With
> a DSA driver, you just need to expect redundant calls, and do the
> right thing.
The base DSA driver only knows about port_mdb_add and port_mdb_del.
It does not really know about SWITCHDEV_OBJ_ID_HOST_MDB.
It is fine to use port_mdb_add and port_mdb_del for
SWITCHDEV_OBJ_ID_HOST_MDB as hardware can program an entry for
the host port, but receiving many port_mdb_del calls with the same
parameter makes it difficult to handle. Example:
port_mdb_add 2 xx:xx:xx:xx:xx:xx
port_mdb_del 2 xx:xx:xx:xx:xx:xx
port_mdb_del 4 xx:xx:xx:xx:xx:xx; lan1
port_mdb_del 4 xx:xx:xx:xx:xx:xx; lan2
port_mdb_del 4 xx:xx:xx:xx:xx:xx; lan3
There is no indication in the port_mdb_del call to show this call is for
port 1, 2, and so on.
port_mdb_add can be used to add an entry for the host. Again it is
called as many times as number of ports. I think the port_mdb_* call
needs an extra parameter to make it useful in this situation.
An easy fix is not to return any error in port_mdb_del, or ignore host port.
It seems port_mdb_prepare is used to indicate an entry can be added
before the actual port_mdb_add call, which returns void and so cannot
indicate failure to add. Currently there is no implementation for that
port_mdb_prepare call and the Marvell driver just displays a warning
inside its port_mdb_add function.
^ permalink raw reply
* Re: [PATCH net-next] bnxt: Don't print message, if DAC isn't connected on both ends
From: Michael Chan @ 2017-12-06 19:27 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: Netdev, open list
In-Reply-To: <20171205123340.3307-1-tbogendoerfer@suse.de>
On Tue, Dec 5, 2017 at 4:33 AM, Thomas Bogendoerfer
<tbogendoerfer@suse.de> wrote:
> bnxt driver spams logfiles with
>
> [ 541.003065] bnxt_en 0000:5d:00.1 eth5: Link speed -1 no longer supported
>
> if a direct attached cable (DAC) is plugged into the bnxt card and is
> unplugged on the other side. This patch removes the code printing this
> message, since it doesn't provide any useful information.
>
> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
> ---
> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> index 8c1dd60eab6f..8a2319ed79dc 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> @@ -1701,18 +1701,9 @@ static int bnxt_async_event_process(struct bnxt *bp,
> /* TODO CHIMP_FW: Define event id's for link change, error etc */
> switch (event_id) {
> case ASYNC_EVENT_CMPL_EVENT_ID_LINK_SPEED_CFG_CHANGE: {
> - u32 data1 = le32_to_cpu(cmpl->event_data1);
> - struct bnxt_link_info *link_info = &bp->link_info;
> -
> if (BNXT_VF(bp))
> goto async_event_process_exit;
> - if (data1 & 0x20000) {
> - u16 fw_speed = link_info->force_link_speed;
> - u32 speed = bnxt_fw_to_ethtool_speed(fw_speed);
>
> - netdev_warn(bp->dev, "Link speed %d no longer supported\n",
> - speed);
> - }
This is supposed to provide useful information to the user under some
conditions. In your particular situation, it is not useful since the
speed is -1. Let me try to modify this code a bit to reduce the spam.
I will post a revised patch in the next 2 hours.
Thanks.
> set_bit(BNXT_LINK_SPEED_CHNG_SP_EVENT, &bp->sp_event);
> /* fall thru */
> }
> --
> 2.12.3
>
^ permalink raw reply
* Re: Waiting for the PHY to complete auto-negotiation
From: Mason @ 2017-12-06 19:25 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli, David Miller
In-Reply-To: <20171206190728.GC28774@lunn.ch>
On 06/12/2017 20:07, Andrew Lunn wrote:
> By chip, you mean the Ethernet controller? Not the whole SoC?
Doh! Yes. Let me rephrase.
When we detect link down, we put the ethernet HW block in reset,
and repeat initialization when the link comes back up.
Hmmm, however, at the moment, I only reset on an administrative
(user-requested) link down, i.e. through ndo_stop. I would probably
have to handle cable unplug/replug events as well.
Or just consider the quirk to make flow control too complicated
to implement correctly...
Regards.
^ permalink raw reply
* Re: [PATCH] bnxt_en: Uninitialized variable in bnxt_tc_parse_actions()
From: David Miller @ 2017-12-06 19:25 UTC (permalink / raw)
To: michael.chan; +Cc: dan.carpenter, sathya.perla, netdev, kernel-janitors
In-Reply-To: <CACKFLinE9vWuooML4RhZHN0Xo2yr4cB90hEwizdEP3U6DLaoFA@mail.gmail.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Wed, 6 Dec 2017 11:16:55 -0800
> On Tue, Dec 5, 2017 at 6:37 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
>> Smatch warns that:
>>
>> drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c:160 bnxt_tc_parse_actions()
>> error: uninitialized symbol 'rc'.
>>
>> "rc" is either uninitialized or set to zero here so we can just remove
>> the check.
>>
>> Fixes: 8c95f773b4a3 ("bnxt_en: add support for Flower based vxlan encap/decap offload")
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> Thanks.
>
> Acked-by: Michael Chan <michael.chan@broadcom.com>
Applied to net-next, thanks everyone.
^ permalink raw reply
* [PATCH] usbnet: fix alignment for frames with no ethernet header
From: Bjørn Mork @ 2017-12-06 19:21 UTC (permalink / raw)
To: netdev; +Cc: Jay Foster, linux-usb, Oliver Neukum, Bjørn Mork
The qmi_wwan minidriver support a 'raw-ip' mode where frames are
received without any ethernet header. This causes alignment issues
because the skbs allocated by usbnet are "IP aligned".
Fix by allowing minidrivers to disable the additional alignment
offset. This is implemented using a per-device flag, since the same
minidriver also supports 'ethernet' mode.
Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode")
Reported-and-tested-by: Jay Foster <jay@systech.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/usb/qmi_wwan.c | 2 ++
drivers/net/usb/usbnet.c | 5 ++++-
include/linux/usb/usbnet.h | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index c750cf7c042b..304ec6555cd8 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -261,9 +261,11 @@ static void qmi_wwan_netdev_setup(struct net_device *net)
net->hard_header_len = 0;
net->addr_len = 0;
net->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
+ set_bit(EVENT_NO_IP_ALIGN, &dev->flags);
netdev_dbg(net, "mode: raw IP\n");
} else if (!net->header_ops) { /* don't bother if already set */
ether_setup(net);
+ clear_bit(EVENT_NO_IP_ALIGN, &dev->flags);
netdev_dbg(net, "mode: Ethernet\n");
}
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 80348b6a8646..d56fe32bf48d 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -484,7 +484,10 @@ static int rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
return -ENOLINK;
}
- skb = __netdev_alloc_skb_ip_align(dev->net, size, flags);
+ if (test_bit(EVENT_NO_IP_ALIGN, &dev->flags))
+ skb = __netdev_alloc_skb(dev->net, size, flags);
+ else
+ skb = __netdev_alloc_skb_ip_align(dev->net, size, flags);
if (!skb) {
netif_dbg(dev, rx_err, dev->net, "no rx skb\n");
usbnet_defer_kevent (dev, EVENT_RX_MEMORY);
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index a69877734c4e..e2ec3582e549 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -82,6 +82,7 @@ struct usbnet {
# define EVENT_RX_KILL 10
# define EVENT_LINK_CHANGE 11
# define EVENT_SET_RX_MODE 12
+# define EVENT_NO_IP_ALIGN 13
};
static inline struct usb_driver *driver_of(struct usb_interface *intf)
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] bnxt_en: Uninitialized variable in bnxt_tc_parse_actions()
From: Michael Chan @ 2017-12-06 19:16 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Sathya Perla, Netdev, kernel-janitors
In-Reply-To: <20171205143752.cymsw7fzlqn6ejeq@mwanda>
On Tue, Dec 5, 2017 at 6:37 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Smatch warns that:
>
> drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c:160 bnxt_tc_parse_actions()
> error: uninitialized symbol 'rc'.
>
> "rc" is either uninitialized or set to zero here so we can just remove
> the check.
>
> Fixes: 8c95f773b4a3 ("bnxt_en: add support for Flower based vxlan encap/decap offload")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Thanks.
Acked-by: Michael Chan <michael.chan@broadcom.com>
^ permalink raw reply
* Re: [PATCH net] netlink: Relax attr validation for fixed length types
From: David Miller @ 2017-12-06 19:12 UTC (permalink / raw)
To: dsahern; +Cc: netdev
In-Reply-To: <20171205195540.41822-1-dsahern@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Tue, 5 Dec 2017 12:55:40 -0700
> Commit 28033ae4e0f5 ("net: netlink: Update attr validation to require
> exact length for some types") requires attributes using types NLA_U* and
> NLA_S* to have an exact length. This change is exposing bugs in various
> userspace commands that are sending attributes with an invalid length
> (e.g., attribute has type NLA_U8 and userspace sends NLA_U32). While
> the commands are clearly broken and need to be fixed, users are arguing
> that the sudden change in enforcement is breaking older commands on
> newer kernels for use cases that otherwise "worked".
>
> Relax the validation to print a warning mesage similar to what is done
> for messages containing extra bytes after parsing.
>
> Fixes: 28033ae4e0f5 ("net: netlink: Update attr validation to require exact length for some types")
> Signed-off-by: David Ahern <dsahern@gmail.com>
David, please address Johannes's feedback and I'll apply this.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/6] net: sched: sch: introduce extack support
From: Cong Wang @ 2017-12-06 19:10 UTC (permalink / raw)
To: Alexander Aring
Cc: David Miller, Jamal Hadi Salim, Jiri Pirko,
Linux Kernel Network Developers, kernel, David Ahern
In-Reply-To: <20171206160845.6646-1-aring@mojatatu.com>
On Wed, Dec 6, 2017 at 8:08 AM, Alexander Aring <aring@mojatatu.com> wrote:
> Hi,
>
> this patch series basically add support for extack in common qdisc handling.
> Additional it adds extack pointer to common qdisc callback handling this
> offers per qdisc implementation to setting the extack message for each
> failure over netlink.
>
> The extack message will be set deeper in qdisc functions but going not
> deeper as net core api. For qdisc module callback handling, the extack
> will not be set. This will be part of per qdisc extack handling.
>
> I also want to prepare patches to handle extack per qdisc module...
> so there will come a lot of more patches, just cut them down to make
> it reviewable.
>
> There are some above 80-chars width warnings, which I ignore because
> it looks more ugly otherwise.
>
> This patch-series based on patches by David Ahren which gave me some
> hints how to deal with extack support.
>
> Cc: David Ahern <dsahern@gmail.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
^ permalink raw reply
* Re: [PATCH net] enic: add wq clean up budget
From: David Miller @ 2017-12-06 19:09 UTC (permalink / raw)
To: gvaradar; +Cc: netdev, govindarajulu90, benve
In-Reply-To: <20171205191441.7288-1-gvaradar@cisco.com>
From: Govindarajulu Varadarajan <gvaradar@cisco.com>
Date: Tue, 5 Dec 2017 11:14:41 -0800
> In case of tx clean up, we set '-1' as budget. This means clean up until
> wq is empty or till (1 << 32) pkts are cleaned. Under heavy load this
> will run for long time and cause
> "watchdog: BUG: soft lockup - CPU#25 stuck for 21s!" warning.
>
> This patch sets wq clean up budget to 256.
>
> Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com>
This driver with all of it's indirection and layers upon layers of
macros for queue processing is so difficult to read, and this can't
be generating nice optimal code either...
Anyways, I was walking over the driver to see if the logic is
contributing to this.
The limit you are proposing sounds unnecessary, nobody else I can
see needs this, and that includes all of the most heavily used
drivers under load.
If I had to guess I'd say that the problem is that the queue loop
keeps sampling the head and tail pointers, where as it should just
do that _once_ and only process that TX entries found in that
snapshot and return to the poll() routine immedately afterwards.
Thanks.
^ permalink raw reply
* [PATCH net] tcp: use current time in tcp_rcv_space_adjust()
From: Eric Dumazet @ 2017-12-06 19:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Wei Wang, Neal Cardwell, Yuchung Cheng
From: Eric Dumazet <edumazet@google.com>
When I switched rcv_rtt_est to high resolution timestamps, I forgot
that tp->tcp_mstamp needed to be refreshed in tcp_rcv_space_adjust()
Using an old timestamp leads to autotuning lags.
Fixes: 645f4c6f2ebd ("tcp: switch rcv_rtt_est and rcvq_space to high resolution timestamps")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Wei Wang <weiwan@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
---
net/ipv4/tcp_input.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 734cfc8ff76edf3453921b50620be2986bfcfdb9..514c00732988b7e71f121953dabf88911b2324d6 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -579,6 +579,7 @@ void tcp_rcv_space_adjust(struct sock *sk)
int time;
int copied;
+ tcp_mstamp_refresh(tp);
time = tcp_stamp_us_delta(tp->tcp_mstamp, tp->rcvq_space.time);
if (time < (tp->rcv_rtt_est.rtt_us >> 3) || tp->rcv_rtt_est.rtt_us == 0)
return;
^ permalink raw reply related
* Re: Waiting for the PHY to complete auto-negotiation
From: Andrew Lunn @ 2017-12-06 19:07 UTC (permalink / raw)
To: Mason; +Cc: netdev, Florian Fainelli, David Miller
In-Reply-To: <f17b7d20-db9e-10eb-9cb1-f3fe1922e1e7@free.fr>
> When we detect link down, we put the chip in reset, so that we will
> repeat initialization when the link comes back up.
By chip, you mean the Ethernet controller? Not the whole SoC?
Andrew
^ permalink raw reply
* Re: Waiting for the PHY to complete auto-negotiation
From: Mason @ 2017-12-06 19:00 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli, David Miller
In-Reply-To: <20171206182633.GP27063@lunn.ch>
On 06/12/2017 19:26, Andrew Lunn wrote:
> On 06/12/2017 19:03, Mason wrote:
>
>> The problem with this is the following mind-boggling quirk of
>> the hardware: once RX DMA is enabled, there is no supported
>> way to disable it! Thus, I'm trying to find a clean way to set
>> the control flow parameter BEFORE enabling the MAC.
>
> There is no solution. I can pull the cable out, and plug it into a
> different computer. The first could use flow control, the second not.
>
> If you cannot disable RX DMA, you should probably disable unloading of
> the module. Also kexec.
It is not possible to /selectively/ disable RX DMA, but after a reset,
DMA is disabled. So the solution I propose is this:
When we detect link down, we put the chip in reset, so that we will
repeat initialization when the link comes back up.
Mans has been reluctant to adopt this approach, but this is what
I implemented in my forked version. I'm trying to push my changes
upstream, to minimize the differences.
Regards.
^ permalink raw reply
* Re: [PATCH] bnxt_en: Uninitialized variable in bnxt_tc_parse_actions()
From: David Miller @ 2017-12-06 19:00 UTC (permalink / raw)
To: dan.carpenter; +Cc: michael.chan, sathya.perla, netdev, kernel-janitors
In-Reply-To: <20171205143752.cymsw7fzlqn6ejeq@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 5 Dec 2017 17:37:52 +0300
> Smatch warns that:
>
> drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c:160 bnxt_tc_parse_actions()
> error: uninitialized symbol 'rc'.
>
> "rc" is either uninitialized or set to zero here so we can just remove
> the check.
>
> Fixes: 8c95f773b4a3 ("bnxt_en: add support for Flower based vxlan encap/decap offload")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Michael, please review.
Thanks.
^ 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