* Re: [PATCH iproute2 1/2] devlink: Add usage help for eswitch subcommand
From: Stephen Hemminger @ 2016-11-30 3:19 UTC (permalink / raw)
To: Roi Dayan; +Cc: netdev, Or Gerlitz
In-Reply-To: <1480245663-814-2-git-send-email-roid@mellanox.com>
On Sun, 27 Nov 2016 13:21:02 +0200
Roi Dayan <roid@mellanox.com> wrote:
> Add missing usage help for devlink dev eswitch subcommand.
>
> Signed-off-by: Roi Dayan <roid@mellanox.com>
> Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Ok. Applied both, will show in next merge
^ permalink raw reply
* [PATCH v4 3/5] net: asix: Fix AX88772x resume failures
From: ASIX_Allan [Office] @ 2016-11-30 3:03 UTC (permalink / raw)
To: freddy-knRN6Y/kmf1NUHwG+Fw1Kw,
Dean_Jenkins-nmGgyN9QBj3QT0dZR+AlfA,
Mark_Craske-nmGgyN9QBj3QT0dZR+AlfA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
robert.foss-ZGY8ohtN/8qB+jHODAdFcQ,
ivecera-H+wXaHxf7aLQT0dZR+AlfA,
john.stultz-QSEj5FYQhm4dnm+yROfE0A,
vpalatin-F7+t8E8rja9g9hUCZPvPmw,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
grundler-F7+t8E8rja9g9hUCZPvPmw,
changchias-Re5JQEeQqe8AvxtiuMwx3w, allan-knRN6Y/kmf1NUHwG+Fw1Kw,
andrew-g2DYL2Zd6BY, tremyfr-Re5JQEeQqe8AvxtiuMwx3w,
colin.king-Z7WLFzj8eWMS+FvcfC7Uqw,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
vpalatin-hpIqsD4AKlfQT0dZR+AlfA
The change fixes AX88772x resume failure by
- Restore incorrect AX88772A PHY registers when resetting
- Need to stop MAC operation when suspending
- Need to restart MII when restoring PHY
Signed-off-by: Allan Chou <allan-knRN6Y/kmf1NUHwG+Fw1Kw@public.gmane.org>
Signed-off-by: Robert Foss <robert.foss-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Tested-by: Robert Foss <robert.foss-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Tested-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Tested-by: Allan Chou <allan-knRN6Y/kmf1NUHwG+Fw1Kw@public.gmane.org>
---
drivers/net/usb/asix_devices.c | 47
+++++++++++++++++++++++++++++++++++++++++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index ebeb730..083dc2e 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -35,6 +35,15 @@
#define PHY_MODE_RTL8211CL 0x000C
+#define AX88772A_PHY14H 0x14
+#define AX88772A_PHY14H_DEFAULT 0x442C
+
+#define AX88772A_PHY15H 0x15
+#define AX88772A_PHY15H_DEFAULT 0x03C8
+
+#define AX88772A_PHY16H 0x16
+#define AX88772A_PHY16H_DEFAULT 0x4044
+
struct ax88172_int_data {
__le16 res1;
u8 link;
@@ -424,7 +433,7 @@ static int ax88772a_hw_reset(struct usbnet *dev, int
in_pm) {
struct asix_data *data = (struct asix_data *)&dev->data;
int ret, embd_phy;
- u16 rx_ctl;
+ u16 rx_ctl, phy14h, phy15h, phy16h;
u8 chipcode = 0;
ret = asix_write_gpio(dev, AX_GPIO_RSE, 5, in_pm); @@ -482,6 +491,32
@@ static int ax88772a_hw_reset(struct usbnet *dev, int in_pm)
ret);
goto out;
}
+ } else if ((chipcode & AX_CHIPCODE_MASK) == AX_AX88772A_CHIPCODE) {
+ /* Check if the PHY registers have default settings */
+ phy14h = asix_mdio_read_nopm(dev->net, dev->mii.phy_id,
+ AX88772A_PHY14H);
+ phy15h = asix_mdio_read_nopm(dev->net, dev->mii.phy_id,
+ AX88772A_PHY15H);
+ phy16h = asix_mdio_read_nopm(dev->net, dev->mii.phy_id,
+ AX88772A_PHY16H);
+
+ netdev_dbg(dev->net,
+ "772a_hw_reset: MR20=0x%x MR21=0x%x MR22=0x%x\n",
+ phy14h, phy15h, phy16h);
+
+ /* Restore PHY registers default setting if not */
+ if (phy14h != AX88772A_PHY14H_DEFAULT)
+ asix_mdio_write_nopm(dev->net, dev->mii.phy_id,
+ AX88772A_PHY14H,
+ AX88772A_PHY14H_DEFAULT);
+ if (phy15h != AX88772A_PHY15H_DEFAULT)
+ asix_mdio_write_nopm(dev->net, dev->mii.phy_id,
+ AX88772A_PHY15H,
+ AX88772A_PHY15H_DEFAULT);
+ if (phy16h != AX88772A_PHY16H_DEFAULT)
+ asix_mdio_write_nopm(dev->net, dev->mii.phy_id,
+ AX88772A_PHY16H,
+ AX88772A_PHY16H_DEFAULT);
}
ret = asix_write_cmd(dev, AX_CMD_WRITE_IPG0, @@ -543,6 +578,15 @@
static const struct net_device_ops ax88772_netdev_ops = { static void
ax88772_suspend(struct usbnet *dev) {
struct asix_common_private *priv = dev->driver_priv;
+ u16 medium;
+
+ /* Stop MAC operation */
+ medium = asix_read_medium_status(dev, 1);
+ medium &= ~AX_MEDIUM_RE;
+ asix_write_medium_mode(dev, medium, 1);
+
+ netdev_dbg(dev->net, "ax88772_suspend: medium=0x%04x\n",
+ asix_read_medium_status(dev, 1));
/* Preserve BMCR for restoring */
priv->presvd_phy_bmcr =
@@ -577,6 +621,7 @@ static void ax88772_restore_phy(struct usbnet *dev)
asix_mdio_write_nopm(dev->net, dev->mii.phy_id, MII_BMCR,
priv->presvd_phy_bmcr);
+ mii_nway_restart(&dev->mii);
priv->presvd_phy_advertise = 0;
priv->presvd_phy_bmcr = 0;
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 related
* Re: The ubufs->refcount maybe be subtracted twice when tun_get_user failed
From: Jason Wang @ 2016-11-30 2:53 UTC (permalink / raw)
To: wangyunjian, mst@redhat.com, netdev@vger.kernel.org; +Cc: caihe
In-Reply-To: <34EFBCA9F01B0748BEB6B629CE643AE60B0A5826@szxeml561-mbx.china.huawei.com>
On 2016年11月29日 21:27, wangyunjian wrote:
> Sorry, I didn't describe it clearly. In fact, the second subtraction happens in the function handle_tx,
> when tun_get_user fails and zcopy_used is ture. Fllowing the steps:
I get your meaning. Thanks for the reporting. Will post patches (since
macvtap has similar issue).
>
> static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
> void *msg_control, struct iov_iter *from,
> int noblock) {
> ...
>
> if (zerocopy)
> err = zerocopy_sg_from_iter(skb, from);
> else {
> err = skb_copy_datagram_from_iter(skb, 0, from, len);
> if (!err && msg_control) {
> struct ubuf_info *uarg = msg_control;
> uarg->callback(uarg, false); --> step 1, the ubufs->refcount is subtracted frist.
> }
> }
>
> if (err) {
> this_cpu_inc(tun->pcpu_stats->rx_dropped);
> kfree_skb(skb);
> return -EFAULT;
> }
>
> err = virtio_net_hdr_to_skb(skb, &gso, tun_is_little_endian(tun));
> if (err) {
> this_cpu_inc(tun->pcpu_stats->rx_frame_errors);
> kfree_skb(skb);
> return -EINVAL; -->step 2, return err.
> }
> }
>
> static void handle_tx(struct vhost_net *net)
> {
> ...
> /* TODO: Check specific error and bomb out unless ENOBUFS? */
> err = sock->ops->sendmsg(sock, &msg, len);
> if (unlikely(err < 0)) {
> if (zcopy_used) {
> vhost_net_ubuf_put(ubufs); --> step 3, the ubufs->refcount will be subtracted twice, when sendmsg execution err.
> nvq->upend_idx = ((unsigned)nvq->upend_idx - 1)
> % UIO_MAXIOV;
> }
> vhost_discard_vq_desc(vq, 1);
> break;
> }
> ...
> }
>
> -----Original Message-----
^ permalink raw reply
* Re: [PATCH net-next v3 3/4] bpf: BPF for lightweight tunnel infrastructure
From: John Fastabend @ 2016-11-30 2:52 UTC (permalink / raw)
To: Alexei Starovoitov, Thomas Graf; +Cc: davem, netdev, daniel, tom, roopa, hannes
In-Reply-To: <20161130001504.GA28238@ast-mbp.thefacebook.com>
On 16-11-29 04:15 PM, Alexei Starovoitov wrote:
> On Tue, Nov 29, 2016 at 02:21:22PM +0100, Thomas Graf wrote:
>> Registers new BPF program types which correspond to the LWT hooks:
>> - BPF_PROG_TYPE_LWT_IN => dst_input()
>> - BPF_PROG_TYPE_LWT_OUT => dst_output()
>> - BPF_PROG_TYPE_LWT_XMIT => lwtunnel_xmit()
>>
>> The separate program types are required to differentiate between the
>> capabilities each LWT hook allows:
>>
>> * Programs attached to dst_input() or dst_output() are restricted and
>> may only read the data of an skb. This prevent modification and
>> possible invalidation of already validated packet headers on receive
>> and the construction of illegal headers while the IP headers are
>> still being assembled.
>>
>> * Programs attached to lwtunnel_xmit() are allowed to modify packet
>> content as well as prepending an L2 header via a newly introduced
>> helper bpf_skb_push(). This is safe as lwtunnel_xmit() is invoked
>> after the IP header has been assembled completely.
>>
>> All BPF programs receive an skb with L3 headers attached and may return
>> one of the following error codes:
>>
>> BPF_OK - Continue routing as per nexthop
>> BPF_DROP - Drop skb and return EPERM
>> BPF_REDIRECT - Redirect skb to device as per redirect() helper.
>> (Only valid in lwtunnel_xmit() context)
>>
>> The return codes are binary compatible with their TC_ACT_
>> relatives to ease compatibility.
>>
>> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> ...
>> +#define LWT_BPF_MAX_HEADROOM 128
>
> why 128?
> btw I'm thinking for XDP to use 256, so metadata can be stored in there.
>
hopefully not too off-topic but for XDP I would like to see this get
passed down with the program. It would be more generic and drivers could
configure the headroom on demand and more importantly verify that a
program pushing data is not going to fail at runtime.
.John
^ permalink raw reply
* Re: [net-next PATCH v3 6/6] virtio_net: xdp, add slowpath case for non contiguous buffers
From: John Fastabend @ 2016-11-30 2:50 UTC (permalink / raw)
To: Alexei Starovoitov, Michael S. Tsirkin
Cc: eric.dumazet, daniel, shm, davem, tgraf, john.r.fastabend, netdev,
bblanco, brouer
In-Reply-To: <20161130003756.GD28238@ast-mbp.thefacebook.com>
On 16-11-29 04:37 PM, Alexei Starovoitov wrote:
> On Tue, Nov 29, 2016 at 12:11:33PM -0800, John Fastabend wrote:
>> virtio_net XDP support expects receive buffers to be contiguous.
>> If this is not the case we enable a slowpath to allow connectivity
>> to continue but at a significan performance overhead associated with
>> linearizing data. To make it painfully aware to users that XDP is
>> running in a degraded mode we throw an xdp buffer error.
>>
>> To linearize packets we allocate a page and copy the segments of
>> the data, including the header, into it. After this the page can be
>> handled by XDP code flow as normal.
>>
>> Then depending on the return code the page is either freed or sent
>> to the XDP xmit path. There is no attempt to optimize this path.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ...
>> +/* The conditions to enable XDP should preclude the underlying device from
>> + * sending packets across multiple buffers (num_buf > 1). However per spec
>> + * it does not appear to be illegal to do so but rather just against convention.
>> + * So in order to avoid making a system unresponsive the packets are pushed
>> + * into a page and the XDP program is run. This will be extremely slow and we
>> + * push a warning to the user to fix this as soon as possible. Fixing this may
>> + * require resolving the underlying hardware to determine why multiple buffers
>> + * are being received or simply loading the XDP program in the ingress stack
>> + * after the skb is built because there is no advantage to running it here
>> + * anymore.
>> + */
> ...
>> if (num_buf > 1) {
>> bpf_warn_invalid_xdp_buffer();
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here is the warn once call. I made it a defined bpf warning so that we
can easily identify if needed and it can be used by other drivers as
well.
>> - goto err_xdp;
>> +
>> + /* linearize data for XDP */
>> + xdp_page = xdp_linearize_page(rq, num_buf,
>> + page, offset, &len);
>> + if (!xdp_page)
>> + goto err_xdp;
>
> in case when we're 'lucky' the performance will silently be bad.
Were you specifically worried about the alloc failing here and no
indication? I was thinking a statistic counter could be added as a
follow on series to catch this and other such cases in non XDP paths
if needed.
> Can we do warn_once here? so at least something in dmesg points out
> that performance is not as expected. Am I reading it correctly that
> you had to do a special kernel hack to trigger this situation and
> in all normal cases it's not the case?
>
Correct the only way to produce this with upstream qemu and Linux is to
write a kernel hack to build these types of buffers. AFAIK I caught all
the cases where it could happen otherwise in the setup xdp prog call and
required user to configure device driver so they can not happen e.g.
disable LRO, set MTU < PAGE_SIZE, etc.
If I missed anything, I don't see it now, I would call it a bug and fix
it. Again AFAIK everything should be covered though. As Micheal pointed
out earlier although unexpected its not strictly against virtio spec to
build such packets so we should handle it at least in a degraded mode
even though it is not expected in any qemu cases.
.John
^ permalink raw reply
* Re: [net-next] neigh: remove duplicate check for same neigh
From: David Ahern @ 2016-11-30 1:56 UTC (permalink / raw)
To: 张胜举, netdev
In-Reply-To: <000201d24aa8$f63c6500$e2b52f00$@cmss.chinamobile.com>
On 11/29/16 6:27 PM, 张胜举 wrote:
> This has less changes, but I preferred to add a new function to do the
> filter logic, this is the same as your code @rtnl_dump_ifinfo().
I'd prefer it to stay in line as it is now. You can save the cycles of filtering on already viewed entries without an overhaul of this code.
^ permalink raw reply
* Re: [PATCH net-next] hv_netvsc: remove excessive logging on MTU change
From: David Miller @ 2016-11-30 1:50 UTC (permalink / raw)
To: vkuznets; +Cc: netdev, linux-kernel, kys, haiyangz
In-Reply-To: <20161128172544.2491-1-vkuznets@redhat.com>
From: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: Mon, 28 Nov 2016 18:25:44 +0100
> When we change MTU or the number of channels on a netvsc device we get the
> following logged:
>
> hv_netvsc bf5edba8...: net device safe to remove
> hv_netvsc: hv_netvsc channel opened successfully
> hv_netvsc bf5edba8...: Send section size: 6144, Section count:2560
> hv_netvsc bf5edba8...: Device MAC 00:15:5d:1e:91:12 link state up
>
> This information is useful as debug at most.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-next 0/4] mlxsw: couple of enhancements and fixes
From: David Miller @ 2016-11-30 1:49 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz
In-Reply-To: <1480352486-18518-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 28 Nov 2016 18:01:22 +0100
> Couple of enhancements and fixes from Ido.
Series applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH 1/1] GSO: Reload iph after pskb_may_pull
From: David Miller @ 2016-11-30 1:46 UTC (permalink / raw)
To: acme; +Cc: eric.dumazet, aduyck, andreyknvl, netdev
In-Reply-To: <20161128153658.GB4778@kernel.org>
From: Arnaldo Carvalho de Melo <acme@kernel.org>
Date: Mon, 28 Nov 2016 12:36:58 -0300
> As it may get stale and lead to use after free.
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Alexander Duyck <aduyck@mirantis.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Fixes: cbc53e08a793 ("GSO: Add GSO type for fixed IPv4 ID")
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Applied and queued up for -stable, thanks Arnaldo!
^ permalink raw reply
* Re: [patch net] sched: cls_flower: remove from hashtable only in case skip sw flag is not set
From: David Miller @ 2016-11-30 1:45 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs, idosch, eladr, ogerlitz, hadarh, amir
In-Reply-To: <1480344013-4812-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 28 Nov 2016 15:40:13 +0100
> From: Jiri Pirko <jiri@mellanox.com>
>
> Be symmetric to hashtable insert and remove filter from hashtable only
> in case skip sw flag is not set.
>
> Fixes: e69985c67c33 ("net/sched: cls_flower: Introduce support in SKIP SW flag")
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH net] net/dccp: fix use-after-free in dccp_invalid_packet
From: David Miller @ 2016-11-30 1:38 UTC (permalink / raw)
To: eric.dumazet
Cc: andreyknvl, gerrit, dccp, netdev, linux-kernel, dvyukov, kcc,
edumazet, syzkaller
In-Reply-To: <1480343209.18162.50.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 28 Nov 2016 06:26:49 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> pskb_may_pull() can reallocate skb->head, we need to reload dh pointer
> in dccp_invalid_packet() or risk use after free.
>
> Bug found by Andrey Konovalov using syzkaller.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next v2] mlxsw: switchib: add MLXSW_PCI dependency
From: David Miller @ 2016-11-30 1:36 UTC (permalink / raw)
To: arnd; +Cc: jiri, idosch, vadimp, cera, eladr, netdev, linux-kernel
In-Reply-To: <20161128142622.2758614-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 28 Nov 2016 15:26:04 +0100
> The newly added switchib driver fails to link if MLXSW_PCI=m:
>
> drivers/net/ethernet/mellanox/mlxsw/mlxsw_switchib.o: In function^Cmlxsw_sib_module_exit':
> switchib.c:(.exit.text+0x8): undefined reference to `mlxsw_pci_driver_unregister'
> switchib.c:(.exit.text+0x10): undefined reference to `mlxsw_pci_driver_unregister'
> drivers/net/ethernet/mellanox/mlxsw/mlxsw_switchib.o: In function `mlxsw_sib_module_init':
> switchib.c:(.init.text+0x28): undefined reference to `mlxsw_pci_driver_register'
> switchib.c:(.init.text+0x38): undefined reference to `mlxsw_pci_driver_register'
> switchib.c:(.init.text+0x48): undefined reference to `mlxsw_pci_driver_unregister'
>
> The other two such sub-drivers have a dependency, so add the same one
> here. In theory we could allow this driver if MLXSW_PCI is disabled,
> but it's probably not worth it.
>
> Fixes: d1ba52638456 ("mlxsw: switchib: Introduce SwitchIB and SwitchIB silicon driver")
> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v2: add Fixes tag
Applied, thanks Arnd.
^ permalink raw reply
* Re: [PATCH v2] net: phy: Fix use after free in phy_detach()
From: David Miller @ 2016-11-30 1:35 UTC (permalink / raw)
To: geert+renesas
Cc: f.fainelli, josh.cartwright, nathan.sullivan, zach.brown,
woojung.huh, netdev, linux-renesas-soc, linux-kernel
In-Reply-To: <1480342711-26407-1-git-send-email-geert+renesas@glider.be>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Mon, 28 Nov 2016 15:18:31 +0100
> If device_release_driver(&phydev->mdio.dev) is called, it releases all
> resources belonging to the PHY device. Hence the subsequent call to
> phy_led_triggers_unregister() will access already freed memory when
> unregistering the LEDs.
>
> Move the call to phy_led_triggers_unregister() before the possible call
> to device_release_driver() to fix this.
>
> Fixes: 2e0bc452f4721520 ("net: phy: leds: add support for led triggers on phy link state change")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> This is v2 of "[RFC] net: phy: Fix double free in phy_detach()".
>
> v2:
> - Dropped RFC,
> - Reworded, as commit a7dac9f9c1695d74 ("phy: fix error case of
> phy_led_triggers_(un)register") fixed the double free, and thus the
> warning I was seeing during "poweroff" on sh73a0/kzm9g,
> - Verified use after free using CONFIG_DEBUG_DEVRES, log_devres = 1,
> and additional debug code printing the address of
> phy->phy_led_triggers. Adding poisoning of freed memory to
> devres_log() will cause a crash.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 1/1] net: macb: ensure ordering write to re-enable RX smoothly
From: David Miller @ 2016-11-30 1:34 UTC (permalink / raw)
To: zumeng.chen; +Cc: nicolas.ferre, netdev, linux-kernel
In-Reply-To: <1480341300-17384-1-git-send-email-zumeng.chen@windriver.com>
From: Zumeng Chen <zumeng.chen@windriver.com>
Date: Mon, 28 Nov 2016 21:55:00 +0800
> When a hardware issue happened as described by inline comments, the register
> write pattern looks like the following:
>
> <write ~MACB_BIT(RE)>
> + wmb();
> <write MACB_BIT(RE)>
>
> There might be a memory barrier between these two write operations, so add wmb
> to ensure an flip from 0 to 1 for NCR.
>
> Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
> ---
>
> V2 changes:
>
> Add the same wmb for at91ether as well based on reviewer's suggestion.
Applied, thanks.
^ permalink raw reply
* RE: [net-next] neigh: remove duplicate check for same neigh
From: 张胜举 @ 2016-11-30 1:27 UTC (permalink / raw)
To: 'David Ahern', netdev
In-Reply-To: <d641245a-8442-9238-a507-6f94184354a0@cumulusnetworks.com>
> -----Original Message-----
> From: David Ahern [mailto:dsa@cumulusnetworks.com]
> Sent: Wednesday, November 30, 2016 12:23 AM
> To: Zhang Shengju <zhangshengju@cmss.chinamobile.com>;
> netdev@vger.kernel.org
> Subject: Re: [net-next] neigh: remove duplicate check for same neigh
>
> On 11/29/16 1:22 AM, Zhang Shengju wrote:
> > @@ -2285,20 +2295,15 @@ static int neigh_dump_table(struct neigh_table
> *tbl, struct sk_buff *skb,
> > rcu_read_lock_bh();
> > nht = rcu_dereference_bh(tbl->nht);
> >
> > - for (h = s_h; h < (1 << nht->hash_shift); h++) {
> > - if (h > s_h)
> > - s_idx = 0;
> > + for (h = s_h; h < (1 << nht->hash_shift); h++, s_idx = 0) {
> > for (n = rcu_dereference_bh(nht->hash_buckets[h]), idx = 0;
> > n != NULL;
> > - n = rcu_dereference_bh(n->next)) {
> > - if (!net_eq(dev_net(n->dev), net))
> > - continue;
> > - if (neigh_ifindex_filtered(n->dev, filter_idx))
> > + n = rcu_dereference_bh(n->next), idx++) {
>
> incrementing idx here ...
>
> > + if (idx < s_idx || !net_eq(dev_net(n->dev), net))
> > continue;
> > - if (neigh_master_filtered(n->dev,
filter_master_idx))
> > + if (neigh_dump_filtered(n->dev, filter_idx,
> > + filter_master_idx))
> > continue;
> > - if (idx < s_idx)
> > - goto next;
> > if (neigh_fill_info(skb, n, NETLINK_CB(cb-
> >skb).portid,
> > cb->nlh->nlmsg_seq,
> > RTM_NEWNEIGH,
>
> ... causes a missed entry when an error happens here
>
> idx is only incremented when a neigh has been successfully added to the
skb.
If an error happens, we just goto 'out' and exit this loop, this will skip
the 'idx++'.
So no missed entry, right?
>
>
> Your intention is to save a few cycles by making idx an absolute index
within
> the hash bucket and jumping to the next entry to be dumped without
> evaluating any filters per entry.
>
> So why not keep it simple and do this:
This has less changes, but I preferred to add a new function to do the
filter logic, this is the same as your code @rtnl_dump_ifinfo().
And for the 'idx', it should be increased when neigh entry is filter out or
is successfully added to the skb. Isn't it straight-forward to put it in for
loop?
>
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c index
> 2ae929f9bd06..2e49a85e696a 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -2291,14 +2291,12 @@ static int neigh_dump_table(struct neigh_table
> *tbl, struct sk_buff *skb,
> for (n = rcu_dereference_bh(nht->hash_buckets[h]), idx =
0;
> n != NULL;
> n = rcu_dereference_bh(n->next)) {
> - if (!net_eq(dev_net(n->dev), net))
> - continue;
> - if (neigh_ifindex_filtered(n->dev, filter_idx))
> - continue;
> - if (neigh_master_filtered(n->dev,
filter_master_idx))
> - continue;
> if (idx < s_idx)
> goto next;
> + if (!net_eq(dev_net(n->dev), net) ||
> + neigh_ifindex_filtered(n->dev, filter_idx) ||
> + neigh_master_filtered(n->dev,
filter_master_idx))
> + goto next;
> if (neigh_fill_info(skb, n,
NETLINK_CB(cb->skb).portid,
> cb->nlh->nlmsg_seq,
> RTM_NEWNEIGH,
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] Fix OdroidC2 Gigabit Tx link issue
From: Florian Fainelli @ 2016-11-30 1:15 UTC (permalink / raw)
To: David Miller
Cc: jbrunet-rdvid1DuHRBWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, carlo-KA+7E9HrN00dnm+yROfE0A,
khilman-rdvid1DuHRBWk0Htik3J/w, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o,
martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg,
neolynx-Re5JQEeQqe8AvxtiuMwx3w, andrew-g2DYL2Zd6BY,
narmstrong-rdvid1DuHRBWk0Htik3J/w,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161129.201331.2207317476589573523.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 11/29/2016 05:13 PM, David Miller wrote:
> From: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Tue, 29 Nov 2016 16:43:20 -0800
>
>> On 11/29/2016 04:38 PM, David Miller wrote:
>>> From: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>> Date: Mon, 28 Nov 2016 10:46:45 +0100
>>>
>>>> This patchset fixes an issue with the OdroidC2 board (DWMAC + RTL8211F).
>>>> The platform seems to enter LPI on the Rx path too often while performing
>>>> relatively high TX transfer. This eventually break the link (both Tx and
>>>> Rx), and require to bring the interface down and up again to get the Rx
>>>> path working again.
>>>>
>>>> The root cause of this issue is not fully understood yet but disabling EEE
>>>> advertisement on the PHY prevent this feature to be negotiated.
>>>> With this change, the link is stable and reliable, with the expected
>>>> throughput performance.
>>>>
>>>> The patchset adds options in the generic phy driver to disable EEE
>>>> advertisement, through device tree. The way it is done is very similar
>>>> to the handling of the max-speed property.
>>>
>>> Patches 1-3 applied to net-next, thanks.
>>
>> Meh, there was a v4 submitted shortly after, and I objected to the whole
>> idea of using that kind of Device Tree properties to disable EEE, we can
>> send reverts though..
>
> Sorry, I lost this in all the discussion, I can revert.
Yeah, I can understand why, these freaking PHYs tend to generate a lot
of noise and discussion...
>
> Just send me a revert of the entire merge commit
> a152c91889556df17ca6d8ea134fb2cb4ac9f893 with a short
> description of why and I'll apply it.
OK, I will talk with Jerome first to make sure that we are in agreement
with the solution to deploy to fix the OdroidC2 problem first.
Thanks!
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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-next v3 0/4] Fix OdroidC2 Gigabit Tx link issue
From: David Miller @ 2016-11-30 1:13 UTC (permalink / raw)
To: f.fainelli-Re5JQEeQqe8AvxtiuMwx3w
Cc: jbrunet-rdvid1DuHRBWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, carlo-KA+7E9HrN00dnm+yROfE0A,
khilman-rdvid1DuHRBWk0Htik3J/w, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o,
martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg,
neolynx-Re5JQEeQqe8AvxtiuMwx3w, andrew-g2DYL2Zd6BY,
narmstrong-rdvid1DuHRBWk0Htik3J/w,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <e14a3b0c-dc34-be14-48b3-518a0ad0c080-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue, 29 Nov 2016 16:43:20 -0800
> On 11/29/2016 04:38 PM, David Miller wrote:
>> From: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> Date: Mon, 28 Nov 2016 10:46:45 +0100
>>
>>> This patchset fixes an issue with the OdroidC2 board (DWMAC + RTL8211F).
>>> The platform seems to enter LPI on the Rx path too often while performing
>>> relatively high TX transfer. This eventually break the link (both Tx and
>>> Rx), and require to bring the interface down and up again to get the Rx
>>> path working again.
>>>
>>> The root cause of this issue is not fully understood yet but disabling EEE
>>> advertisement on the PHY prevent this feature to be negotiated.
>>> With this change, the link is stable and reliable, with the expected
>>> throughput performance.
>>>
>>> The patchset adds options in the generic phy driver to disable EEE
>>> advertisement, through device tree. The way it is done is very similar
>>> to the handling of the max-speed property.
>>
>> Patches 1-3 applied to net-next, thanks.
>
> Meh, there was a v4 submitted shortly after, and I objected to the whole
> idea of using that kind of Device Tree properties to disable EEE, we can
> send reverts though..
Sorry, I lost this in all the discussion, I can revert.
Just send me a revert of the entire merge commit
a152c91889556df17ca6d8ea134fb2cb4ac9f893 with a short
description of why and I'll apply it.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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-next v5 2/3] bpf: Add new cgroup attach type to enable sock modifications
From: David Ahern @ 2016-11-30 1:07 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: netdev, daniel, ast, daniel, maheshb, tgraf
In-Reply-To: <20161130005906.GB29591@ast-mbp.thefacebook.com>
On 11/29/16 5:59 PM, Alexei Starovoitov wrote:
> On Tue, Nov 29, 2016 at 05:43:08PM -0700, David Ahern wrote:
>> On 11/29/16 1:01 PM, Alexei Starovoitov wrote:
>>> Could you also expose sk_protcol and sk_type as read only fields?
>>
>> Those are bitfields in struct sock, so can't use offsetof or sizeof. Any existing use cases that try to load a bitfield in a bpf that I can look at?
>
> pkt_type, vlan are also bitfileds in skb. Please see convert_skb_access()
> There is a bit of ugliness due to __BIG_ENDIAN_BITFIELD though..
>
Given the added complexity I'd prefer to defer this second use case to a follow on patch set. This one introduces the infra for sockets and I don't see anything needing to change with it to add the read of 3 more sock elements. Agree?
^ permalink raw reply
* Re: [PATCH net v2 1/1] net: macb: fix the RX queue reset in macb_rx()
From: David Miller @ 2016-11-30 1:02 UTC (permalink / raw)
To: cyrille.pitchen
Cc: nicolas.ferre, netdev, soren.brinkmann, Andrei.Pistirica,
linux-arm-kernel, linux-kernel
In-Reply-To: <80ebb550eb6155e3b882cab1fb8d78a7385f8227.1480339901.git.cyrille.pitchen@atmel.com>
From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Date: Mon, 28 Nov 2016 14:40:55 +0100
> On macb only (not gem), when a RX queue corruption was detected from
> macb_rx(), the RX queue was reset: during this process the RX ring
> buffer descriptor was initialized by macb_init_rx_ring() but we forgot
> to also set bp->rx_tail to 0.
>
> Indeed, when processing the received frames, bp->rx_tail provides the
> macb driver with the index in the RX ring buffer of the next buffer to
> process. So when the whole ring buffer is reset we must also reset
> bp->rx_tail so the driver is synchronized again with the hardware.
>
> Since macb_init_rx_ring() is called from many locations, currently from
> macb_rx() and macb_init_rings(), we'd rather add the "bp->rx_tail = 0;"
> line inside macb_init_rx_ring() than add the very same line after each
> call of this function.
>
> Without this fix, the rx queue is not reset properly to recover from
> queue corruption and connection drop may occur.
>
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> Fixes: 9ba723b081a2 ("net: macb: remove BUG_ON() and reset the queue to handle RX errors")
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next v5 2/3] bpf: Add new cgroup attach type to enable sock modifications
From: Alexei Starovoitov @ 2016-11-30 0:59 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, daniel, ast, daniel, maheshb, tgraf
In-Reply-To: <781e66b2-007c-bd56-2cd1-543c1f5dcdb7@cumulusnetworks.com>
On Tue, Nov 29, 2016 at 05:43:08PM -0700, David Ahern wrote:
> On 11/29/16 1:01 PM, Alexei Starovoitov wrote:
> > Could you also expose sk_protcol and sk_type as read only fields?
>
> Those are bitfields in struct sock, so can't use offsetof or sizeof. Any existing use cases that try to load a bitfield in a bpf that I can look at?
pkt_type, vlan are also bitfileds in skb. Please see convert_skb_access()
There is a bit of ugliness due to __BIG_ENDIAN_BITFIELD though..
^ permalink raw reply
* Re: [PATCH] stmmac: fix comments, make debug output consistent
From: David Miller @ 2016-11-30 0:53 UTC (permalink / raw)
To: pavel; +Cc: alexandre.torgue, peppe.cavallaro, netdev, linux-kernel, akpm
In-Reply-To: <20161128115559.GB15034@amd>
From: Pavel Machek <pavel@ucw.cz>
Date: Mon, 28 Nov 2016 12:55:59 +0100
> Fix comments, add some new, and make debugfs output consistent.
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] bpf: cgroup: fix documentation of __cgroup_bpf_update()
From: David Miller @ 2016-11-30 0:52 UTC (permalink / raw)
To: daniel; +Cc: ast, daniel, netdev, roszenrami, cgroups
In-Reply-To: <1480338664-22616-1-git-send-email-daniel@zonque.org>
From: Daniel Mack <daniel@zonque.org>
Date: Mon, 28 Nov 2016 14:11:04 +0100
> There's a 'not' missing in one paragraph. Add it.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> Reported-by: Rami Rosen <roszenrami@gmail.com>
> Fixes: 3007098494be ("cgroup: add support for eBPF programs")
Applied, thanks.
^ permalink raw reply
* [PATCH net-next 1/1] driver: ipvlan: Remove useless member mtu_adj of struct ipvl_dev
From: fgao @ 2016-11-30 0:48 UTC (permalink / raw)
To: davem, maheshb, edumazet, netdev, gfree.wind; +Cc: Gao Feng
From: Gao Feng <fgao@ikuai8.com>
The mtu_adj is initialized to zero when alloc mem, there is no any
assignment to mtu_adj. It is only used in ipvlan_adjust_mtu as one
right value.
So it is useless member of struct ipvl_dev, then remove it.
Signed-off-by: Gao Feng <fgao@ikuai8.com>
---
drivers/net/ipvlan/ipvlan.h | 1 -
drivers/net/ipvlan/ipvlan_main.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ipvlan/ipvlan.h b/drivers/net/ipvlan/ipvlan.h
index 7e0732f..05a62d2 100644
--- a/drivers/net/ipvlan/ipvlan.h
+++ b/drivers/net/ipvlan/ipvlan.h
@@ -73,7 +73,6 @@ struct ipvl_dev {
DECLARE_BITMAP(mac_filters, IPVLAN_MAC_FILTER_SIZE);
netdev_features_t sfeatures;
u32 msg_enable;
- u16 mtu_adj;
};
struct ipvl_addr {
diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
index ab90b22..c6aa667 100644
--- a/drivers/net/ipvlan/ipvlan_main.c
+++ b/drivers/net/ipvlan/ipvlan_main.c
@@ -32,7 +32,7 @@
static void ipvlan_adjust_mtu(struct ipvl_dev *ipvlan, struct net_device *dev)
{
- ipvlan->dev->mtu = dev->mtu - ipvlan->mtu_adj;
+ ipvlan->dev->mtu = dev->mtu;
}
static int ipvlan_register_nf_hook(void)
--
1.9.1
^ permalink raw reply related
* Re: Crash due to mutex genl_lock called from RCU context
From: David Miller @ 2016-11-30 0:49 UTC (permalink / raw)
To: herbert; +Cc: xiyou.wangcong, eric.dumazet, subashab, tgraf, netdev
In-Reply-To: <20161128112211.GA990@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 28 Nov 2016 19:22:12 +0800
> netlink: Call cb->done from a worker thread
>
> The cb->done interface expects to be called in process context.
> This was broken by the netlink RCU conversion. This patch fixes
> it by adding a worker struct to make the cb->done call where
> necessary.
>
> Fixes: 21e4902aea80 ("netlink: Lockless lookup with RCU grace...")
> Reported-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied and queued up for -stable, thanks Herbert.
^ permalink raw reply
* Re: [PATCH net V2] net/sched: pedit: make sure that offset is valid
From: David Miller @ 2016-11-30 0:46 UTC (permalink / raw)
To: amir; +Cc: netdev, xiyou.wangcong, jhs, ogerlitz, hadarh, jiri
In-Reply-To: <20161128105640.32363-1-amir@vadai.me>
From: Amir Vadai <amir@vadai.me>
Date: Mon, 28 Nov 2016 12:56:40 +0200
> Add a validation function to make sure offset is valid:
> 1. Not below skb head (could happen when offset is negative).
> 2. Validate both 'offset' and 'at'.
>
> Signed-off-by: Amir Vadai <amir@vadai.me>
Applied and queued up for -stable, 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