* Re: [PATCH 2/2] sh_eth: Do not print an error message for probe deferral
From: David Miller @ 2017-05-18 15:21 UTC (permalink / raw)
To: geert+renesas
Cc: sergei.shtylyov, laurent.pinchart+renesas, netdev,
linux-renesas-soc
In-Reply-To: <1495112495-25086-2-git-send-email-geert+renesas@glider.be>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Thu, 18 May 2017 15:01:35 +0200
> EPROBE_DEFER is not an error, hence printing an error message like
>
> sh-eth ee700000.ethernet: failed to initialise MDIO
>
> may confuse the user.
>
> To fix this, suppress the error message in case of probe deferral.
> While at it, shorten the message, and add the actual error code.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] sh_eth: Use platform device for printing before register_netdev()
From: David Miller @ 2017-05-18 15:21 UTC (permalink / raw)
To: geert+renesas
Cc: sergei.shtylyov, laurent.pinchart+renesas, netdev,
linux-renesas-soc
In-Reply-To: <1495112495-25086-1-git-send-email-geert+renesas@glider.be>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Thu, 18 May 2017 15:01:34 +0200
> The MDIO initialization failure message is printed using the network
> device, before it has been registered, leading to:
>
> (null): failed to initialise MDIO
>
> Use the platform device instead to fix this:
>
> sh-eth ee700000.ethernet: failed to initialise MDIO
>
> Fixes: daacf03f0bbfefee ("sh_eth: Register MDIO bus before registering the network device")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ieee802154: fix net_device reference release too early
From: Stefan Schmidt @ 2017-05-18 15:14 UTC (permalink / raw)
To: Stefan Schmidt; +Cc: linzhang, aar, davem, linux-wpan, netdev, linux-kernel
In-Reply-To: <20170518131359.GA3311@work>
Hello.
On Thu, 2017-05-18 at 15:14, Stefan Schmidt wrote:
> Hello.
>
> On Thu, 2017-05-18 at 15:50, linzhang wrote:
> > This patch fixes the kernel oops when release net_device reference in
> > advance. In function raw_sendmsg(i think the dgram_sendmsg has the same
> > problem), there is a race condition between dev_put and dev_queue_xmit
> > when the device is gong that maybe lead to dev_queue_ximt to see
> > an illegal net_device pointer.
> >
>
> You have a test case to reproduce this oops? I fear I have not seen
> one.
If you have a test case handy adding it to the commit would be handy. If you do
not have one around we can do without.
> > So i think that dev_put should be behind of the dev_queue_xmit.
> >
> > Also, explicit set skb->sk is needless, sock_alloc_send_skb is
> > already set it.
>
> You could have put this fixup in a different patch.
I actually would request you to split this into two patches. One for the
removal of the sk setting and one for the race condition fix.
> > Signed-off-by: linzhang <xiaolou4617@gmail.com>
>
> This looks more like a username instead of a real name. If you have Lin
> Zhang as you English real name that would be better here. :)
This would be also appreciated.
> > ---
> > net/ieee802154/socket.c | 10 ++++------
> > 1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
> > index eedba76..a60658c 100644
> > --- a/net/ieee802154/socket.c
> > +++ b/net/ieee802154/socket.c
> > @@ -301,15 +301,14 @@ static int raw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
> > goto out_skb;
> >
> > skb->dev = dev;
> > - skb->sk = sk;
> > skb->protocol = htons(ETH_P_IEEE802154);
> >
> > - dev_put(dev);
> > -
> > err = dev_queue_xmit(skb);
> > if (err > 0)
> > err = net_xmit_errno(err);
> >
> > + dev_put(dev);
> > +
> > return err ?: size;
> >
> > out_skb:
> > @@ -690,15 +689,14 @@ static int dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
> > goto out_skb;
> >
> > skb->dev = dev;
> > - skb->sk = sk;
> > skb->protocol = htons(ETH_P_IEEE802154);
> >
> > - dev_put(dev);
> > -
> > err = dev_queue_xmit(skb);
> > if (err > 0)
> > err = net_xmit_errno(err);
> >
> > + dev_put(dev);
> > +
> > return err ?: size;
>
> Going to give this a test ride here now.
I gave it a ride in my testbed and I encountered no problems. While I have never
seen the race and oops myself doing the dev_put before the xmit can surely lead to
such a race and the fix is valid.
Once you have done the changes requested above and re-submit your two patches you can
add my
Acked-by: Stefan Schmidt <stefan@osg.samsung.com>
to both of them.
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH net-next] geneve: add rtnl changelink support
From: Girish Moodalbail @ 2017-05-18 15:15 UTC (permalink / raw)
To: Pravin Shelar
Cc: Linux Kernel Network Developers, David S. Miller, Joe Stringer,
Jiri Benc
In-Reply-To: <CAOrHB_CRBWb2odpyFBaZS0sJ=zK=ve4d8LRp0iVNJehghmsBGQ@mail.gmail.com>
TL DR; There is indeed a race between geneve_changelink() and geneve transmit
path w.r.t attributes being changed and the old value of those attributes being
used in the transmit patch. I will resubmit V2 of the patch with those issues
addressed. Thanks!
Please see in-line for my other comments..
>
>> Signed-off-by: Girish Moodalbail <girish.moodalbail@oracle.com>
>> ---
>> drivers/net/geneve.c | 149 ++++++++++++++++++++++++++++++++++++++++-----------
>> 1 file changed, 117 insertions(+), 32 deletions(-)
>>
> ...
>> @@ -1169,45 +1181,58 @@ static void init_tnl_info(struct ip_tunnel_info *info, __u16 dst_port)
>> info->key.tp_dst = htons(dst_port);
>> }
>>
>> -static int geneve_newlink(struct net *net, struct net_device *dev,
>> - struct nlattr *tb[], struct nlattr *data[])
>> +static int geneve_nl2info(struct net_device *dev, struct nlattr *tb[],
>> + struct nlattr *data[], struct ip_tunnel_info *info,
>> + bool *metadata, bool *use_udp6_rx_checksums,
>> + bool changelink)
>> {
>> - bool use_udp6_rx_checksums = false;
>> - struct ip_tunnel_info info;
>> - bool metadata = false;
>> + struct geneve_dev *geneve = netdev_priv(dev);
>>
>> - init_tnl_info(&info, GENEVE_UDP_PORT);
>> + if (changelink) {
>> + /* if changelink operation, start with old existing info */
>> + memcpy(info, &geneve->info, sizeof(*info));
>> + *metadata = geneve->collect_md;
>> + *use_udp6_rx_checksums = geneve->use_udp6_rx_checksums;
>> + } else {
>> + init_tnl_info(info, GENEVE_UDP_PORT);
>> + }
>>
>> if (data[IFLA_GENEVE_REMOTE] && data[IFLA_GENEVE_REMOTE6])
>> return -EINVAL;
>>
>> if (data[IFLA_GENEVE_REMOTE]) {
>> - info.key.u.ipv4.dst =
>> + info->key.u.ipv4.dst =
>> nla_get_in_addr(data[IFLA_GENEVE_REMOTE]);
>>
>> - if (IN_MULTICAST(ntohl(info.key.u.ipv4.dst))) {
>> + if (IN_MULTICAST(ntohl(info->key.u.ipv4.dst))) {
>> netdev_dbg(dev, "multicast remote is unsupported\n");
>> return -EINVAL;
>> }
>> + if (changelink &&
>> + ip_tunnel_info_af(&geneve->info) == AF_INET6) {
>> + info->mode &= ~IP_TUNNEL_INFO_IPV6;
>> + info->key.tun_flags &= ~TUNNEL_CSUM;
>> + *use_udp6_rx_checksums = false;
>> + }
> This allows changelink to change ipv4 address but there are no changes
> made to the geneve tunnel port hash table after this update.
The following code in geneve_changelink() does what you are asking for
+ if (!geneve_dst_addr_equal(&geneve->info, &info))
+ dst_cache_reset(&info.dst_cache);
geneve_nl2info() accrues all the allowed changes to be made and captures it in
ip_tunnel_info structure and then the above code in geneve_changelink() ensures
that all the route cache associated with the old remote address are released
when the next lookup occurs.
> We also
> need to check to see if there is any conflicts with existing ports.
This is not needed since we don't support changing the remote port.
>
> What is the barrier between the rx/tx threads and changelink process?
There is an issue here like you pointed out (thanks!). Will fix that issue.
>
>> }
>>
>> if (data[IFLA_GENEVE_REMOTE6]) {
>> #if IS_ENABLED(CONFIG_IPV6)
>> - info.mode = IP_TUNNEL_INFO_IPV6;
>> - info.key.u.ipv6.dst =
>> + info->mode = IP_TUNNEL_INFO_IPV6;
>> + info->key.u.ipv6.dst =
>> nla_get_in6_addr(data[IFLA_GENEVE_REMOTE6]);
>>
>> - if (ipv6_addr_type(&info.key.u.ipv6.dst) &
>> + if (ipv6_addr_type(&info->key.u.ipv6.dst) &
>> IPV6_ADDR_LINKLOCAL) {
>> netdev_dbg(dev, "link-local remote is unsupported\n");
>> return -EINVAL;
>> }
>> - if (ipv6_addr_is_multicast(&info.key.u.ipv6.dst)) {
>> + if (ipv6_addr_is_multicast(&info->key.u.ipv6.dst)) {
>> netdev_dbg(dev, "multicast remote is unsupported\n");
>> return -EINVAL;
>> }
>> - info.key.tun_flags |= TUNNEL_CSUM;
>> - use_udp6_rx_checksums = true;
>> + info->key.tun_flags |= TUNNEL_CSUM;
>> + *use_udp6_rx_checksums = true;
> Same here. We need to check/fix the geneve tunnel hash table according
> to new IP address.
This is taken care by the call to dst_cache_reset() whenever the remote address
changes. This function already takes care of races and contentions....
------------8<-----------------8<------
/**
* dst_cache_reset - invalidate the cache contents
* @dst_cache: the cache
*
* This do not free the cached dst to avoid races and contentions.
* the dst will be freed on later cache lookup.
*/
static inline void dst_cache_reset(struct dst_cache *dst_cache)
{
dst_cache->reset_ts = jiffies;
}
------------8<-----------------8<------
.... by setting reset_ts to current value of jiffies. After this, when we call
dst_cache_get_ip4() to get a route entry for geneve packet we ensure that cache
is old/obsolete/invalid/incorrect through the following check in that function
------------8<-----------------8<------
if (unlikely(!time_after(idst->refresh_ts, dst_cache->reset_ts) ||
(dst->obsolete && !dst->ops->check(dst, idst->cookie)))) {
dst_cache_per_cpu_dst_set(idst, NULL, 0);
dst_release(dst);
goto fail;
}
------------8<-----------------8<------
>
>> #else
>> return -EPFNOSUPPORT;
>> #endif
>> @@ -1216,48 +1241,107 @@ static int geneve_newlink(struct net *net, struct net_device *dev,
> ...
>>
>> - if (data[IFLA_GENEVE_PORT])
>> - info.key.tp_dst = nla_get_be16(data[IFLA_GENEVE_PORT]);
>> + if (data[IFLA_GENEVE_PORT]) {
>> + if (changelink)
>> + return -EOPNOTSUPP;
>> + info->key.tp_dst = nla_get_be16(data[IFLA_GENEVE_PORT]);
>> + }
>> +
>> + if (data[IFLA_GENEVE_COLLECT_METADATA]) {
>> + if (changelink)
>> + return -EOPNOTSUPP;
> Rather than blindly returning error here it should check if the
> changelink is changing existing configuration.
I would like to start by saying that I have kept the same semantic as
vxlan_changelink() here to keep the operations consistent across geneve and
vxlan links.
Furthermore, will this not give a semantic that we do support changing metadata
to an user? For example: Assume that there already existed geneve datalink with
metadata enabled, now if I do
# ip link set gen0 type geneve id 100 metadata
it will return success giving an idea that '[no]metadata' attribute is
modifiable. So, when they try to do
# ip link set gen0 type geneve id 100 nometadata
it will fail.
>
>> + *metadata = true;
>> + }
>> +
>> + if (data[IFLA_GENEVE_UDP_CSUM]) {
>> + if (changelink)
>> + return -EOPNOTSUPP;
>> + if (nla_get_u8(data[IFLA_GENEVE_UDP_CSUM]))
>> + info->key.tun_flags |= TUNNEL_CSUM;
>> + }
>> +
> same here.
please see above
>
>> + if (data[IFLA_GENEVE_UDP_ZERO_CSUM6_TX]) {
>> + if (changelink)
>> + return -EOPNOTSUPP;
>> + if (nla_get_u8(data[IFLA_GENEVE_UDP_ZERO_CSUM6_TX]))
>> + info->key.tun_flags &= ~TUNNEL_CSUM;
> same here.
please see above
>
>> + }
>>
>> - if (data[IFLA_GENEVE_COLLECT_METADATA])
>> - metadata = true;
>> + if (data[IFLA_GENEVE_UDP_ZERO_CSUM6_RX]) {
>> + if (changelink)
>> + return -EOPNOTSUPP;
>> + if (nla_get_u8(data[IFLA_GENEVE_UDP_ZERO_CSUM6_RX]))
>> + *use_udp6_rx_checksums = false;
>> + }
>>
>> - if (data[IFLA_GENEVE_UDP_CSUM] &&
>> - nla_get_u8(data[IFLA_GENEVE_UDP_CSUM]))
>> - info.key.tun_flags |= TUNNEL_CSUM;
>> + return 0;
>> +}
>>
>> - if (data[IFLA_GENEVE_UDP_ZERO_CSUM6_TX] &&
>> - nla_get_u8(data[IFLA_GENEVE_UDP_ZERO_CSUM6_TX]))
>> - info.key.tun_flags &= ~TUNNEL_CSUM;
>> +static int geneve_newlink(struct net *net, struct net_device *dev,
>> + struct nlattr *tb[], struct nlattr *data[])
>> +{
>> + bool use_udp6_rx_checksums = false;
>> + struct ip_tunnel_info info;
>> + bool metadata = false;
>> + int err;
>>
>> - if (data[IFLA_GENEVE_UDP_ZERO_CSUM6_RX] &&
>> - nla_get_u8(data[IFLA_GENEVE_UDP_ZERO_CSUM6_RX]))
>> - use_udp6_rx_checksums = false;
>> + err = geneve_nl2info(dev, tb, data, &info, &metadata,
>> + &use_udp6_rx_checksums, false);
>> + if (err)
>> + return err;
>>
>> return geneve_configure(net, dev, &info, metadata, use_udp6_rx_checksums);
>> }
>>
>> +static int geneve_changelink(struct net_device *dev, struct nlattr *tb[],
>> + struct nlattr *data[])
>> +{
>> + struct geneve_dev *geneve = netdev_priv(dev);
>> + struct ip_tunnel_info info;
>> + bool metadata = false;
>> + bool use_udp6_rx_checksums = false;
>> + int err;
>> +
>> + err = geneve_nl2info(dev, tb, data, &info, &metadata,
>> + &use_udp6_rx_checksums, true);
>> + if (err)
>> + return err;
>> +
>> + if (!geneve_dst_addr_equal(&geneve->info, &info))
>> + dst_cache_reset(&info.dst_cache);
>> + geneve->info = info;
> This would just overwrite dst-cache, which could leak the percpu
> cached dst-entry objects.
It will not. The ip_tunnel_info`dst_cache is a struct with a pointer to per_cpu
struct and reset_ts. We copy this structure at the beginning of
geneve_changelink() and this is done under rtnl_lock(). That
ip_tunnel_info`dst_cache`per_cpu struct doesn't change throughout the operation
but only reset_ts is set to 'jiffies' if the remote address changes.
Thanks,
~Girish
^ permalink raw reply
* Re: [Patch RFC net-next] net: usb: r8152: Fix rx_bytes/tx_bytes to include FCS
From: Andrew Lunn @ 2017-05-18 15:09 UTC (permalink / raw)
To: Florian Fainelli; +Cc: David Miller, netdev, hayeswang, Mario Limonciello
In-Reply-To: <286d107e-2380-f8e9-3edf-c949707ea235@gmail.com>
> I am afraid that we won't be able to enforce a consistent behavior,
> because the HW itself is not consistent, both on the NIC and on the
> switch side.
Hi Florian
I agree with that, for MIB counters. They tend to come direct from the
hardware.
However, rx_bytes and tx_bytes are not from the hardware. They are
software stats, kept by the drivers. Just grep in driver/net/ethernet
and you see:
broadcom/bcmsysport.c: ndev->stats.rx_bytes += len;
broadcom/sb1250-mac.c: dev->stats.rx_bytes += len;
mellanox/mlx5/core/en_main.c: s->rx_bytes += rq_stats->bytes;
microchip/encx24j600.c: dev->stats.rx_bytes += rsv->len;
neterion/vxge/vxge-main.c: net_stats->rx_bytes += bytes;
nuvoton/w90p910_ether.c: dev->stats.rx_bytes += length;
etc.
Since these are software counters, they can be consistent. From a
practical point of view, i doubt they ever will all be consistent,
there are simply too many drivers to test and change if
needed. However, for the ones somebody cares about, they can be made
consistent.
I care about r8152, and would like to make it consistent with asix,
dsa, e1000e.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 3/6] net: bridge: break if __br_mdb_del fails
From: Vivien Didelot @ 2017-05-18 15:08 UTC (permalink / raw)
To: Nikolay Aleksandrov, netdev
Cc: moderated list:ETHERNET BRIDGE, kernel, linux-kernel,
David S. Miller
In-Reply-To: <5d8f53ea-a9de-7c76-f088-48c5357cb2a2@cumulusnetworks.com>
Hi Nikolay,
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> writes:
>> err = __br_mdb_del(br, entry);
>> - if (!err)
>> - __br_mdb_notify(dev, p, entry, RTM_DELMDB);
>> + if (err)
>> + break;
>> + __br_mdb_notify(dev, p, entry, RTM_DELMDB);
>> }
>> } else {
>> err = __br_mdb_del(br, entry);
>>
>
> This can potentially break user-space scripts that rely on the best-effort
> behaviour, this is the normal "delete without vid & enabled vlan filtering".
> You can check the fdb delete code which does the same, this was intentional.
>
> You can add an mdb entry without a vid to all vlans, add a vlan and then try
> to remove it from all vlans where it is present - with this patch obviously
> that will fail at the new vlan.
OK good to know. That intention wasn't obvious. I can make __br_mdb_del
return void instead? What about the rest of the patchset if I do so?
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH net 3/3] virtio-net: enable TSO/checksum offloads for Q-in-Q vlans
From: Michael S. Tsirkin @ 2017-05-18 15:06 UTC (permalink / raw)
To: Vladislav Yasevich; +Cc: netdev, Vladislav Yasevich, Jason Wang, virtualization
In-Reply-To: <1495114265-23368-4-git-send-email-vyasevic@redhat.com>
On Thu, May 18, 2017 at 09:31:05AM -0400, Vladislav Yasevich wrote:
> Since virtio does not provide it's own ndo_features_check handler,
> TSO, and now checksum offload, are disabled for stacked vlans.
> Re-enable the support and let the host take care of it. This
> restores/improves Guest-to-Guest performance over Q-in-Q vlans.
>
> CC: "Michael S. Tsirkin" <mst@redhat.com>
> CC: Jason Wang <jasowang@redhat.com>
> CC: virtualization@lists.linux-foundation.org
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/virtio_net.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 8324a5e..341fb96 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2028,6 +2028,7 @@ static const struct net_device_ops virtnet_netdev = {
> .ndo_poll_controller = virtnet_netpoll,
> #endif
> .ndo_xdp = virtnet_xdp,
> + .ndo_features_check = passthru_features_check,
> };
>
> static void virtnet_config_changed_work(struct work_struct *work)
> --
> 2.7.4
^ permalink raw reply
* Re: [patch net-next] mlxsw: spectrum_dpipe: Fix sparse warnings
From: David Miller @ 2017-05-18 15:06 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, arkadis, mlxsw
In-Reply-To: <20170518072245.12494-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 18 May 2017 09:22:45 +0200
> From: Arkadi Sharshevsky <arkadis@mellanox.com>
>
> drivers/net/ethernet/mellanox/mlxsw//spectrum_dpipe.c:221:52: warning:
> Using plain integer as NULL pointer
> drivers/net/ethernet/mellanox/mlxsw//spectrum_dpipe.c:221:74: warning:
> Using plain integer as NULL pointer
>
> Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied.
^ permalink raw reply
* Re: [patch net 0/2] mlxsw: couple of fixes
From: David Miller @ 2017-05-18 15:05 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, arkadis, mlxsw
In-Reply-To: <20170518071853.12279-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 18 May 2017 09:18:51 +0200
> Couple of fixes from Arkadi
Series applied.
^ permalink raw reply
* Re: [PATCH v3] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: David Miller @ 2017-05-18 15:02 UTC (permalink / raw)
To: eric-WhKQ6XTQaPysTnJN9+BGXg
Cc: f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
andrew-g2DYL2Zd6BY, netdev-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
rjui-dY08KVG/lbpWk0Htik3J/w, sbranden-dY08KVG/lbpWk0Htik3J/w,
jonmason-dY08KVG/lbpWk0Htik3J/w
In-Reply-To: <20170518003212.4028-1-eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
From: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
Date: Wed, 17 May 2017 17:32:12 -0700
> Cygnus is a small family of SoCs, of which we currently have
> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
> same as 58xx, just requiring a tiny bit of setup that was previously
> missing.
>
> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
> Reviewed-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Applied to net-next, 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: [RFC] iproute: Add support for extended ack to rtnl_talk
From: Stephen Hemminger @ 2017-05-18 14:55 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: David Ahern, Phil Sutter, David Miller, netdev
In-Reply-To: <591D711F.1000906@iogearbox.net>
On Thu, 18 May 2017 12:02:07 +0200
Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 05/16/2017 06:36 PM, Stephen Hemminger wrote:
> > On Sat, 13 May 2017 19:29:57 -0600
> > David Ahern <dsahern@gmail.com> wrote:
> >
> >> On 5/4/17 2:43 PM, Phil Sutter wrote:
> >>> So in summary, given that very little change happens to iproute2's
> >>> internal libnetlink, I don't see much urge to make it use libmnl as
> >>> backend. In my opinion it just adds another potential source of errors.
> >>>
> >>> Eventually this should be a maintainer level decision, though. :)
> >>
> >> What is the decision on this?
> >
> > I am waiting for a longer before committing anything. This was to allow
> > for a wider range of distribution maintainer feedback.
> >
> > The most likely outcome is that for 4.12 is to use libmnl for extended ack.
> > And continue to support building without mnl with loss of functionality.
> >
> > As far as conversion of all of iproute2 to libmnl. I have better things
> > to do... But for new functionality like extended ack, devlink, tipc, using
> > libmnl is easy, safe and it works well. I will continue to not accept
> > new code that depends on the other library (libnl). That has come up
> > a couple of times.
>
> So effectively this means libmnl has to be used for new stuff, noone
> has time to do the work to convert the existing tooling over (which
> by itself might be a challenge in testing everything to make sure
> there are no regressions) given there's not much activity around
> lib/libnetlink.c anyway, and existing users not using libmnl today
> won't see/notice new improvements on netlink side when they do an
> upgrade. So we'll be stuck with that dual library mess pretty much
> for a very long time. :(
>
> If there's such high desire to use libmnl (?), can't there be a
> one time effort wrapping the core netlink code over, making a hard
> cut for everyone where from one release to another the dependency
> becomes really mandatory rather than optional? That's more work
> initially, but still seems a lot better than growing a wild mix
> of both over time where users see different behavior of the tools
> depending on their setup. (This could perhaps also make actual
> conversion much harder later on.)
If nothing else it would be simple experiment to do libnetlink
to libmnl wrappers in libnetlink.h
> Can't you add that lib conversion as a Google summer of code project,
> so that someone is actively taking care of that initial work?
Agreed
^ permalink raw reply
* admin
From: administrador @ 2017-05-18 11:57 UTC (permalink / raw)
To: Recipients
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:
nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:
Si usted no puede revalidar su buzón, el buzón se deshabilitará!
Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico © 2017
¡gracias
Sistemas administrador
^ permalink raw reply
* Fw: [Bug 195807] New: general protection fault in ping_v4_sendmsg
From: Stephen Hemminger @ 2017-05-18 14:51 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Thu, 18 May 2017 03:36:33 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 195807] New: general protection fault in ping_v4_sendmsg
https://bugzilla.kernel.org/show_bug.cgi?id=195807
Bug ID: 195807
Summary: general protection fault in ping_v4_sendmsg
Product: Networking
Version: 2.5
Kernel Version: 4.4 to 4.10-rc7
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: youwei@ruc.edu.cn
Regression: No
Created attachment 256607
--> https://bugzilla.kernel.org/attachment.cgi?id=256607&action=edit
poc and kernel config
I got a general protection fault (use after free) when fuzzing the bpf system
call.
Attached is the PoC that can reproduce this issue in kernel version from 4.4 to
4.10-rc7.
Following is the dmesg output when executing the PoC on kernel version 4.10-rc7
[ 32.949367] kasan: CONFIG_KASAN_INLINE enabled
[ 32.949915] kasan: GPF could be caused by NULL-ptr deref or user memory
access
[ 32.950602] general protection fault: 0000 [#1] SMP KASAN
[ 32.951089] Dumping ftrace buffer:
[ 32.951396] (ftrace buffer empty)
[ 32.951579] Modules linked in:
[ 32.951579] CPU: 0 PID: 4145 Comm: poc-NB1 Not tainted 4.10.0-rc7 #1
[ 32.951579] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
[ 32.951579] task: ffff880064f51bc0 task.stack: ffff880056568000
[ 32.951579] RIP: 0010:ping_v4_sendmsg+0xcbd/0x1240
[ 32.951579] RSP: 0018:ffff88005656f9b8 EFLAGS: 00010206
[ 32.951579] RAX: dffffc0000000000 RBX: ffff88005656fc20 RCX:
1ffff1000a9ad033
[ 32.951579] RDX: 0000000000000018 RSI: 0000000000000008 RDI:
00000000000000c2
[ 32.951579] RBP: ffff88005656fc48 R08: 0000000000000008 R09:
0000000000000000
[ 32.951579] R10: 000000000100007f R11: 0000000000000000 R12:
ffff880054d68040
[ 32.951579] R13: 0000000000000000 R14: ffff88005656fb40 R15:
ffff88005656fac0
[ 32.951579] FS: 00007fc22df907c0(0000) GS:ffff88006ca00000(0000)
knlGS:0000000000000000
[ 32.951579] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 32.951579] CR2: 0000000020007000 CR3: 00000000656e0000 CR4:
00000000000006f0
[ 32.951579] Call Trace:
[ 32.951579] ? ping_queue_rcv_skb+0x60/0x60
[ 32.951579] ? depot_save_stack+0x133/0x4a0
[ 32.951579] ? save_stack+0xb1/0xd0
[ 32.951579] ? save_stack_trace+0x16/0x20
[ 32.951579] ? save_stack+0x46/0xd0
[ 32.951579] ? __anon_vma_prepare+0x30e/0x570
[ 32.951579] ? handle_mm_fault+0xdb0/0x1e30
[ 32.951579] ? __do_page_fault+0x5b9/0xc50
[ 32.951579] ? do_page_fault+0x2a/0x30
[ 32.951579] ? page_fault+0x22/0x30
[ 32.951579] ? ip4_datagram_release_cb+0xf3/0x6e0
[ 32.951579] ? _raw_write_unlock_bh+0x3c/0x50
[ 32.951579] ? ping_get_port+0x37d/0x5e0
[ 32.951579] ? _raw_spin_unlock_bh+0x3c/0x50
[ 32.951579] ? release_sock+0x194/0x1d0
[ 32.951579] inet_sendmsg+0x141/0x3e0
[ 32.951579] ? inet_recvmsg+0x430/0x430
[ 32.951579] sock_sendmsg+0xde/0x120
[ 32.951579] SYSC_sendto+0x23f/0x3a0
[ 32.951579] ? SYSC_connect+0x320/0x320
[ 32.951579] ? __page_set_anon_rmap+0x1cc/0x2b0
[ 32.951579] ? __lru_cache_add+0x114/0x1a0
[ 32.951579] ? handle_mm_fault+0x6ff/0x1e30
[ 32.951579] ? get_unused_fd_flags+0xd0/0xd0
[ 32.951579] ? find_vma+0x3f/0x190
[ 32.951579] ? __do_page_fault+0x3ae/0xc50
[ 32.951579] SyS_sendto+0x4a/0x60
[ 32.951579] entry_SYSCALL_64_fastpath+0x13/0x94
[ 32.951579] RIP: 0033:0x7fc22dac6b79
[ 32.951579] RSP: 002b:00007ffc4ecef988 EFLAGS: 00000206 ORIG_RAX:
000000000000002c
[ 32.951579] RAX: ffffffffffffffda RBX: 0000000000000000 RCX:
00007fc22dac6b79
[ 32.951579] RDX: 0000000000000008 RSI: 0000000020004ff5 RDI:
0000000000000003
[ 32.951579] RBP: 00007ffc4ecefa00 R08: 0000000020007000 R09:
0000000000000010
[ 32.951579] R10: 400000000000083c R11: 0000000000000206 R12:
0000000000400b20
[ 32.951579] R13: 00007ffc4ecefb30 R14: 0000000000000000 R15:
0000000000000000
[ 32.951579] Code: ff c1 e2 10 66 31 c0 01 d0 15 ff ff 00 00 f7 d0 48 89 fa
c1 e8 10 48 c1 ea 03 66 89 83 a2 fe ff ff 48 b8 00 00 00 00 00 fc ff df <0f> b6
14 02 48 89 f8 83 e0 07 83 c0 01 38 d0 7c 08 84 d2 0f 85
[ 32.951579] RIP: ping_v4_sendmsg+0xcbd/0x1240 RSP: ffff88005656f9b8
[ 32.978078] ---[ end trace 3d206c2ba5fde6a4 ]---
[ 32.978505] Kernel panic - not syncing: Fatal exception
[ 32.979052] Dumping ftrace buffer:
[ 32.979052] (ftrace buffer empty)
[ 32.979052] Kernel Offset: disabled
[ 32.979052] Rebooting in 86400 seconds..
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH v2 1/3] bpf: Use 1<<16 as ceiling for immediate alignment in verifier.
From: Edward Cree @ 2017-05-18 14:49 UTC (permalink / raw)
To: Alexei Starovoitov, David Miller, Daniel Borkmann
Cc: alexei.starovoitov, netdev
In-Reply-To: <97910214-213c-c5c6-4a02-adc16cd836aa@fb.com>
On 18/05/17 03:48, Alexei Starovoitov wrote:
> Would it be easier to represent this logic via (mask_of_unknown, value)
> instead of (mask0, mask1) ?
Yes, I like this.
> As far as upper bits we can tweak the algorithm to eat into
> one or more bits of known bits due to carry.
> Like
> 00xx11 + 00xx11 = 0xxx10
> we will eat only one bit (second from left) and the highest bit
> is known to stay zero, since carry can only compromise 2nd from left.
> Such logic should work for sparse representation of unknown bits too
> Like:
> 10xx01xx10 +
> 01xx01xx00 =
> xxxx1xxx10
> both upper two bits would be unknown, but only one middle bit becomes
> unknown.
Yes, that is the behaviour we want. But it's unclear how to efficiently
compute it, without just iterating over the bits and computing carry
possibilities.
Here's one idea that seemed to work when I did a couple of experiments:
let A = (a;am), B = (b;bm) where the m are the masks
Σ = am + bm + a + b
χ = Σ ^ (a + b) /* unknown carries */
μ = χ | am | bm /* mask of result */
then A + B = ((a + b) & ~μ; μ)
The idea is that we find which bits change between the case "all x are
1" and "all x are 0", and those become xs too. But I'm not certain
that that's always going to cover all possible values in between.
It worked on the tests I came up with, and also your example above, but
I can't quite prove it'll always work.
-Ed
^ permalink raw reply
* Re: [PATCH] net1080: Mark nc_dump_ttl() as __maybe_unused
From: David Miller @ 2017-05-18 14:48 UTC (permalink / raw)
To: mka; +Cc: linux-usb, netdev, linux-kernel
In-Reply-To: <20170517221708.183212-1-mka@chromium.org>
From: Matthias Kaehlcke <mka@chromium.org>
Date: Wed, 17 May 2017 15:17:08 -0700
> The function is not used, but it looks useful for debugging. Adding the
> attribute fixes the following clang warning:
>
> drivers/net/usb/net1080.c:271:20: error: unused function
> 'nc_dump_ttl' [-Werror,-Wunused-function]
>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
For this and the r8152 patch, I definitely prefer that the function is
removed.
If someone needs them, they can pull it out of the GIT history.
^ permalink raw reply
* Re: [PATCH v2] e1000e: Don't return uninitialized stats
From: David Miller @ 2017-05-18 14:46 UTC (permalink / raw)
To: bpoirier
Cc: jeffrey.t.kirsher, s.priebe, intel-wired-lan, netdev, pmenzel,
sasha.neftin, aaron.f.brown, stephen
In-Reply-To: <20170517202413.18321-1-bpoirier@suse.com>
From: Benjamin Poirier <bpoirier@suse.com>
Date: Wed, 17 May 2017 16:24:13 -0400
> Some statistics passed to ethtool are garbage because e1000e_get_stats64()
> doesn't write them, for example: tx_heartbeat_errors. This leaks kernel
> memory to userspace and confuses users.
>
> Do like ixgbe and use dev_get_stats() which first zeroes out
> rtnl_link_stats64.
>
> Fixes: 5944701df90d ("net: remove useless memset's in drivers get_stats64")
> Reported-by: Stefan Priebe <s.priebe@profihost.ag>
> Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
Jeff, please be sure to pick this up, thanks.
^ permalink raw reply
* Re: [PATCH net-next] qed: Utilize FW 8.20.0.0
From: David Miller @ 2017-05-18 14:43 UTC (permalink / raw)
To: Yuval.Mintz
Cc: netdev, linux-scsi, Chad.Dupuis, Ram.Amrani, Tomer.Tayar,
Manish.Rangankar
In-Reply-To: <20170518.103428.1194147893495615244.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 18 May 2017 10:34:28 -0400 (EDT)
> From: Yuval Mintz <Yuval.Mintz@cavium.com>
> Date: Wed, 17 May 2017 22:38:40 +0300
>
>> This pushes qed [and as result, all qed* drivers] into using 8.20.0.0
>> firmware. The changes are mostly contained in qed with minor changes
>> to qedi due to some HSI changes.
>>
>> Content-wise, the firmware contains fixes to various issues exposed
>> since the release of the previous firmware, including:
>> - Corrects iSCSI fast retransmit when data digest is enabled.
>> - Stop draining packets when receiving several consecutive PFCs.
>> - Prevent possible assertion when consecutively opening/closing
>> many connections.
>> - Prevent possible assertion due to too long BDQ fetch time.
>>
>> In addition, the new firmware would allow us to later add iWARP support
>> in qed and qedr.
>>
>> Signed-off-by: Chad Dupuis <Chad.Dupuis@cavium.com>
>> Signed-off-by: Ram Amrani <Ram.Amrani@cavium.com>
>> Signed-off-by: Tomer Tayar <Tomer.Tayar@cavium.com>
>> Signed-off-by: Manish Rangankar <Manish.Rangankar@cavium.com>
>> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
>
> Applied.
Actually I had to revert. Please look at the compiler output before
submitting changes:
drivers/net/ethernet/qlogic/qed/qed_debug.c: In function ‘qed_grc_dump’:
drivers/net/ethernet/qlogic/qed/qed_debug.c:2425:6: warning: ‘addr’ may be used uninitialized in this function [-Wmaybe-uninitialized]
u32 byte_addr = DWORDS_TO_BYTES(addr), offset = 0, i;
^
drivers/net/ethernet/qlogic/qed/qed_debug.c:3534:7: note: ‘addr’ was declared here
u32 addr, size = RSS_REG_RSS_RAM_DATA_SIZE;
^
'addr' is never, ever, assigned a value, yet it is passed into a function as an
argument.
^ permalink raw reply
* [PATCH] xfrm: fix state migration replay sequence numbers
From: Antony Antony @ 2017-05-18 14:39 UTC (permalink / raw)
To: netdev, Herbert Xu, Steffen Klassert; +Cc: Richard Guy Briggs, Antony Antony
[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]
During xfrm migration replay and preplay sequence numbers are not
copied from the previous state.
Here is tcpdump output showing the problem.
10.0.10.46 is running vanilla kernel, IKE/IPsec responder.
After the migration it sent wrong sequence number, reset to 1.
The migration is from 10.0.0.52 to 10.0.0.53.
IP 10.0.0.52.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7cf), length 136
IP 10.0.10.46.4500 > 10.0.0.52.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x7cf), length 136
IP 10.0.0.52.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7d0), length 136
IP 10.0.10.46.4500 > 10.0.0.52.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x7d0), length 136
IP 10.0.0.53.4500 > 10.0.10.46.4500: NONESP-encap: isakmp: child_sa inf2[I]
IP 10.0.10.46.4500 > 10.0.0.53.4500: NONESP-encap: isakmp: child_sa inf2[R]
IP 10.0.0.53.4500 > 10.0.10.46.4500: NONESP-encap: isakmp: child_sa inf2[I]
IP 10.0.10.46.4500 > 10.0.0.53.4500: NONESP-encap: isakmp: child_sa inf2[R]
IP 10.0.0.53.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7d1), length 136
NOTE: next sequence is wrong 0x1
IP 10.0.10.46.4500 > 10.0.0.53.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x1), length 136
IP 10.0.0.53.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7d2), length 136
IP 10.0.10.46.4500 > 10.0.0.53.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x2), length 136
The attached patch fix it by copying replay and preplay.
regards,
-antony
Antony Antony (1):
xfrm: fix state migration replay sequence numbers
net/xfrm/xfrm_state.c | 2 ++
1 file changed, 2 insertions(+)
--
2.9.3
[-- Attachment #2: 0001-xfrm-fix-state-migration.patch --]
[-- Type: text/plain, Size: 1017 bytes --]
>From 1241e8b4c38ad2bf7399599165f763af38aba8d9 Mon Sep 17 00:00:00 2001
From: Antony Antony <antony@phenome.org>
Date: Thu, 18 May 2017 12:19:32 +0200
Subject: [PATCH] xfrm: fix state migration copy replay sequence numbers
To: netdev@vger.kernel.org, Herbert Xu <herbert@gondor.apana.org.au>, Steffen Klassert <steffen.klassert@secunet.com>
Cc: Richard Guy Briggs <rgb@tricolour.ca>
During xfrm migration copy replay and preplay sequence numbers
from the previous state.
Signed-off-by: Antony Antony <antony@phenome.org>
---
net/xfrm/xfrm_state.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index fc3c5aa..2e291bc 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1383,6 +1383,8 @@ static struct xfrm_state *xfrm_state_clone(struct xfrm_state *orig)
x->curlft.add_time = orig->curlft.add_time;
x->km.state = orig->km.state;
x->km.seq = orig->km.seq;
+ x->replay = orig->replay;
+ x->preplay = orig->preplay;
return x;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next 0/3] net: dsa: headers cleanup
From: David Miller @ 2017-05-18 14:36 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20170517194605.31639-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Wed, 17 May 2017 15:46:02 -0400
> The DSA core files share a common private header file. Include the DSA
> public header there instead of independently in each core source file.
>
> DSA core and its drivers use switchdev, thus include switchdev.h in the
> public DSA header. This allows us to get rid of the forward declaration
> and use typedef defined by switchdev.
This looks fine, series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] qed: Utilize FW 8.20.0.0
From: David Miller @ 2017-05-18 14:34 UTC (permalink / raw)
To: Yuval.Mintz
Cc: netdev, linux-scsi, Chad.Dupuis, Ram.Amrani, Tomer.Tayar,
Manish.Rangankar
In-Reply-To: <1495049920-22782-1-git-send-email-Yuval.Mintz@cavium.com>
From: Yuval Mintz <Yuval.Mintz@cavium.com>
Date: Wed, 17 May 2017 22:38:40 +0300
> This pushes qed [and as result, all qed* drivers] into using 8.20.0.0
> firmware. The changes are mostly contained in qed with minor changes
> to qedi due to some HSI changes.
>
> Content-wise, the firmware contains fixes to various issues exposed
> since the release of the previous firmware, including:
> - Corrects iSCSI fast retransmit when data digest is enabled.
> - Stop draining packets when receiving several consecutive PFCs.
> - Prevent possible assertion when consecutively opening/closing
> many connections.
> - Prevent possible assertion due to too long BDQ fetch time.
>
> In addition, the new firmware would allow us to later add iWARP support
> in qed and qedr.
>
> Signed-off-by: Chad Dupuis <Chad.Dupuis@cavium.com>
> Signed-off-by: Ram Amrani <Ram.Amrani@cavium.com>
> Signed-off-by: Tomer Tayar <Tomer.Tayar@cavium.com>
> Signed-off-by: Manish Rangankar <Manish.Rangankar@cavium.com>
> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2] net: fix __skb_try_recv_from_queue to return the old behavior
From: David Miller @ 2017-05-18 14:33 UTC (permalink / raw)
To: avagin; +Cc: netdev, pabeni, edumazet
In-Reply-To: <20170517183905.10971-1-avagin@openvz.org>
From: Andrei Vagin <avagin@openvz.org>
Date: Wed, 17 May 2017 11:39:05 -0700
> This function has to return NULL on a error case, because there is a
> separate error variable.
>
> The offset has to be changed only if skb is returned
>
> v2: fix udp code to not use an extra variable
>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: David S. Miller <davem@davemloft.net>
> Fixes: 65101aeca522 ("net/sock: factor out dequeue/peek with offset cod")
> Signed-off-by: Andrei Vagin <avagin@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH net] cxgb4: update latest firmware version supported
From: David Miller @ 2017-05-18 14:32 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil
In-Reply-To: <1495046296-9009-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Thu, 18 May 2017 00:08:16 +0530
> Change t4fw_version.h to update latest firmware version
> number to 1.16.43.0.
>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: make struct dst_entry::dev first member
From: David Miller @ 2017-05-18 14:30 UTC (permalink / raw)
To: adobriyan; +Cc: netdev
In-Reply-To: <20170517163138.GA5269@avx2>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Wed, 17 May 2017 19:31:39 +0300
> struct dst_entry::dev is used most often. Move it so it can be
> accessed without imm8 offset on x86_64.
...
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 7/8] net/wan/fsl_ucc_hdlc: add hdlc-bus support
From: David Miller @ 2017-05-18 14:29 UTC (permalink / raw)
To: holger.brunck; +Cc: netdev, qiang.zhao
In-Reply-To: <20170517152439.8817-7-holger.brunck@keymile.com>
From: Holger Brunck <holger.brunck@keymile.com>
Date: Wed, 17 May 2017 17:24:38 +0200
> This adds support for hdlc-bus mode to the fsl_ucc_hdlc driver. This can
> be enabled with the "fsl,hdlc-bus" property in the DTS node of the
> corresponding ucc.
>
> This aligns the configuration of the UPSMR and GUMR registers to what is
> done in our ucc_hdlc driver (that only support hdlc-bus mode) and with
> the QuickEngine's documentation for hdlc-bus mode.
>
> GUMR/SYNL is set to AUTO for the busmode as in this case the CD signal
> is ignored. The brkpt_support is enabled to set the HBM1 bit in the
> CMXUCR register to configure an open-drain connected HDLC bus.
>
> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 8/8] powerpc/85xx/kmcent2: use hdlc busmode for UCC1
From: David Miller @ 2017-05-18 14:29 UTC (permalink / raw)
To: holger.brunck; +Cc: netdev
In-Reply-To: <20170517152439.8817-8-holger.brunck@keymile.com>
From: Holger Brunck <holger.brunck@keymile.com>
Date: Wed, 17 May 2017 17:24:39 +0200
> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Applied.
^ 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