* [iproute PATCH v3 2/7] xfrm_state: Make sure alg_name is NULL-terminated
From: Phil Sutter @ 2017-08-21 13:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170821132341.23118-1-phil@nwl.cc>
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
ip/xfrm_state.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ip/xfrm_state.c b/ip/xfrm_state.c
index e11c93bf1c3b5..7c0389038986e 100644
--- a/ip/xfrm_state.c
+++ b/ip/xfrm_state.c
@@ -125,7 +125,8 @@ static int xfrm_algo_parse(struct xfrm_algo *alg, enum xfrm_attr_type_t type,
fprintf(stderr, "warning: ALGO-NAME/ALGO-KEYMAT values will be sent to the kernel promiscuously! (verifying them isn't implemented yet)\n");
#endif
- strncpy(alg->alg_name, name, sizeof(alg->alg_name));
+ strncpy(alg->alg_name, name, sizeof(alg->alg_name) - 1);
+ alg->alg_name[sizeof(alg->alg_name) - 1] = '\0';
if (slen > 2 && strncmp(key, "0x", 2) == 0) {
/* split two chars "0x" from the top */
--
2.13.1
^ permalink raw reply related
* [iproute PATCH v3 5/7] lnstat_util: Simplify alloc_and_open() a bit
From: Phil Sutter @ 2017-08-21 13:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170821132341.23118-1-phil@nwl.cc>
Relying upon callers and using unsafe strcpy() is probably not the best
idea. Aside from that, using snprintf() allows to format the string for
lf->path in one go.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
misc/lnstat_util.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/misc/lnstat_util.c b/misc/lnstat_util.c
index cc54598fe1bef..ec19238c24b94 100644
--- a/misc/lnstat_util.c
+++ b/misc/lnstat_util.c
@@ -180,11 +180,8 @@ static struct lnstat_file *alloc_and_open(const char *path, const char *file)
}
/* initialize */
- /* de->d_name is guaranteed to be <= NAME_MAX */
- strcpy(lf->basename, file);
- strcpy(lf->path, path);
- strcat(lf->path, "/");
- strcat(lf->path, lf->basename);
+ snprintf(lf->basename, sizeof(lf->basename), "%s", file);
+ snprintf(lf->path, sizeof(lf->path), "%s/%s", path, file);
/* initialize to default */
lf->interval.tv_sec = 1;
--
2.13.1
^ permalink raw reply related
* [iproute PATCH v3 1/7] ipntable: Avoid memory allocation for filter.name
From: Phil Sutter @ 2017-08-21 13:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170821132341.23118-1-phil@nwl.cc>
The original issue was that filter.name might end up unterminated if
user provided string was too long. But in fact it is not necessary to
copy the commandline parameter at all: just make filter.name point to it
instead.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
ip/ipntable.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ip/ipntable.c b/ip/ipntable.c
index 879626ee4f491..e0bd9b6ebd155 100644
--- a/ip/ipntable.c
+++ b/ip/ipntable.c
@@ -37,7 +37,7 @@ static struct
int family;
int index;
#define NONE_DEV (-1)
- char name[1024];
+ const char *name;
} filter;
static void usage(void) __attribute__((noreturn));
@@ -369,7 +369,7 @@ static int print_ntable(const struct sockaddr_nl *who, struct nlmsghdr *n, void
if (tb[NDTA_NAME]) {
const char *name = rta_getattr_str(tb[NDTA_NAME]);
- if (strlen(filter.name) > 0 && strcmp(filter.name, name))
+ if (filter.name && strcmp(filter.name, name))
return 0;
}
if (tb[NDTA_PARMS]) {
@@ -633,7 +633,7 @@ static int ipntable_show(int argc, char **argv)
} else if (strcmp(*argv, "name") == 0) {
NEXT_ARG();
- strncpy(filter.name, *argv, sizeof(filter.name));
+ filter.name = *argv;
} else
invarg("unknown", *argv);
--
2.13.1
^ permalink raw reply related
* [iproute PATCH v3 4/7] lib/inet_proto: Review inet_proto_{a2n,n2a}()
From: Phil Sutter @ 2017-08-21 13:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170821132341.23118-1-phil@nwl.cc>
The original intent was to make sure strings written by those functions
are NUL-terminated at all times, though it was suggested to get rid of
the 15 char protocol name limit as well which this patch accomplishes.
In addition to that, simplify inet_proto_a2n() a bit: Use the error
checking in get_u8() to find out whether passed 'buf' contains a valid
decimal number instead of checking the first character's value manually.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
lib/inet_proto.c | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/lib/inet_proto.c b/lib/inet_proto.c
index ceda082b12a2e..53c029039b6d5 100644
--- a/lib/inet_proto.c
+++ b/lib/inet_proto.c
@@ -25,7 +25,7 @@
const char *inet_proto_n2a(int proto, char *buf, int len)
{
- static char ncache[16];
+ static char *ncache;
static int icache = -1;
struct protoent *pe;
@@ -34,9 +34,12 @@ const char *inet_proto_n2a(int proto, char *buf, int len)
pe = getprotobynumber(proto);
if (pe) {
+ if (icache != -1)
+ free(ncache);
icache = proto;
- strncpy(ncache, pe->p_name, 16);
- strncpy(buf, pe->p_name, len);
+ ncache = strdup(pe->p_name);
+ strncpy(buf, pe->p_name, len - 1);
+ buf[len - 1] = '\0';
return buf;
}
snprintf(buf, len, "ipproto-%d", proto);
@@ -45,24 +48,23 @@ const char *inet_proto_n2a(int proto, char *buf, int len)
int inet_proto_a2n(const char *buf)
{
- static char ncache[16];
+ static char *ncache;
static int icache = -1;
struct protoent *pe;
+ __u8 ret;
- if (icache>=0 && strcmp(ncache, buf) == 0)
+ if (icache != -1 && strcmp(ncache, buf) == 0)
return icache;
- if (buf[0] >= '0' && buf[0] <= '9') {
- __u8 ret;
- if (get_u8(&ret, buf, 10))
- return -1;
+ if (!get_u8(&ret, buf, 10))
return ret;
- }
pe = getprotobyname(buf);
if (pe) {
+ if (icache != -1)
+ free(ncache);
icache = pe->p_proto;
- strncpy(ncache, pe->p_name, 16);
+ ncache = strdup(pe->p_name);
return pe->p_proto;
}
return -1;
--
2.13.1
^ permalink raw reply related
* [iproute PATCH v3 3/7] lib/fs: Fix format string in find_fs_mount()
From: Phil Sutter @ 2017-08-21 13:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170821132341.23118-1-phil@nwl.cc>
A field width of 4096 allows fscanf() to store that amount of characters
into the given buffer, though that doesn't include the terminating NULL
byte. Decrease the value by one to leave space for it.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
lib/fs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/fs.c b/lib/fs.c
index c59ac564581d0..1ff881ecfcd8c 100644
--- a/lib/fs.c
+++ b/lib/fs.c
@@ -45,7 +45,7 @@ static char *find_fs_mount(const char *fs_to_find)
return NULL;
}
- while (fscanf(fp, "%*s %4096s %127s %*s %*d %*d\n",
+ while (fscanf(fp, "%*s %4095s %127s %*s %*d %*d\n",
path, fstype) == 2) {
if (strcmp(fstype, fs_to_find) == 0) {
mnt = strdup(path);
--
2.13.1
^ permalink raw reply related
* Re: [PATCH net-next v2 1/2] tcp: Remove unnecessary dst check in tcp_conn_request.
From: Tonghao Zhang @ 2017-08-21 13:24 UTC (permalink / raw)
To: David Miller; +Cc: Linux Kernel Network Developers
In-Reply-To: <20170819.212524.1982304186024322688.davem@davemloft.net>
Thanks, yes this is a bug. I found this bug exists from 3.17~ 4.13.
The commit is d94e0417
One question: should I send a patch for each kernel version because
code conflicts ?
a patch for v4.12
a patch for v4.11
a patch for v4.10~v4.7
a patch for v4.6~v3.17
and
a patch for net-next, because tcp_tw_recycle has been removed.
Thanks very much.
On Sun, Aug 20, 2017 at 12:25 PM, David Miller <davem@davemloft.net> wrote:
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> Date: Wed, 16 Aug 2017 20:02:45 -0700
>
>> Because we remove the tcp_tw_recycle support in the commit
>> 4396e46187c ('tcp: remove tcp_tw_recycle') and also delete
>> the code 'af_ops->route_req' for sysctl_tw_recycle in tcp_conn_request.
>> Now when we call the 'af_ops->route_req', the dist always is
>> NULL, and we remove the unnecessay check.
>>
>> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> This is a bug actually, rather than something to paper over
> by removing the check.
>
> Code earlier in this function needs a proper 'dst' in order to operate
> properly.
>
> There is a call to tcp_peer_is_proven() which must have a proper route
> to make the determination yet it will always be NULL.
>
> Please investigate what the code is doing and how a test became
> "unnecessary" over time before blindly removing it, thank you.
^ permalink raw reply
* [PATCH] can: peak_pci: Make i2c_algo_bit_data const
From: Bhumika Goyal @ 2017-08-21 13:26 UTC (permalink / raw)
To: julia.lawall, wg, mkl, linux-can, netdev, linux-kernel; +Cc: Bhumika Goyal
Make this const as it is only used in a copy operation.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/net/can/sja1000/peak_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/sja1000/peak_pci.c b/drivers/net/can/sja1000/peak_pci.c
index 131026f..44f1e37 100644
--- a/drivers/net/can/sja1000/peak_pci.c
+++ b/drivers/net/can/sja1000/peak_pci.c
@@ -425,7 +425,7 @@ static void peak_pciec_write_reg(const struct sja1000_priv *priv,
peak_pci_write_reg(priv, port, val);
}
-static struct i2c_algo_bit_data peak_pciec_i2c_bit_ops = {
+static const struct i2c_algo_bit_data peak_pciec_i2c_bit_ops = {
.setsda = pita_setsda,
.setscl = pita_setscl,
.getsda = pita_getsda,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 2/2] vhost-net: revert vhost_exceeds_maxpend logic to its original
From: Koichiro Den @ 2017-08-21 13:30 UTC (permalink / raw)
To: Jason Wang, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <0cbc33d6-eb1e-cea4-4cdf-a8a88932da62@redhat.com>
On Mon, 2017-08-21 at 11:06 +0800, Jason Wang wrote:
>
> On 2017年08月19日 14:41, Koichiro Den wrote:
> > To depend on vq.num and the usage of VHOST_MAX_PEND is not succinct
> > and in some case unexpected, so revert its logic part only.
>
> Hi:
>
> Could you explain a little bit more on the case that is was not sufficent?
It's just because vq.num could theoretically be around VHOST_MAX_PEND, that
could lead to an unexpected situation. Plus, I thought its name and usage is not
intrinsic. Its actual functioning in normal vq.num == 256 case is I think good
enough. Thanks.
>
> Thanks
>
> >
> > Signed-off-by: Koichiro Den <den@klaipeden.com>
> > ---
> > drivers/vhost/net.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> > index 06d044862e58..99cf99b308a7 100644
> > --- a/drivers/vhost/net.c
> > +++ b/drivers/vhost/net.c
> > @@ -433,11 +433,15 @@ static int vhost_net_tx_get_vq_desc(struct vhost_net
> > *net,
> >
> > static bool vhost_exceeds_maxpend(struct vhost_net *net)
> > {
> > + int num_pends;
> > struct vhost_net_virtqueue *nvq = &net->vqs[VHOST_NET_VQ_TX];
> > struct vhost_virtqueue *vq = &nvq->vq;
> >
> > - return (nvq->upend_idx + vq->num - VHOST_MAX_PEND) % UIO_MAXIOV
> > - == nvq->done_idx;
> > + num_pends = likely(nvq->upend_idx >= nvq->done_idx) ?
> > + (nvq->upend_idx - nvq->done_idx) :
> > + (nvq->upend_idx + UIO_MAXIOV - nvq->done_idx);
> > +
> > + return num_pends > VHOST_MAX_PEND;
> > }
> >
> > /* Expects to be always run from workqueue - which acts as
>
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac
From: Maxime Ripard @ 2017-08-21 13:31 UTC (permalink / raw)
To: Andrew Lunn
Cc: Chen-Yu Tsai, Corentin Labbe, Rob Herring, Mark Rutland,
Russell King, Giuseppe Cavallaro, Alexandre Torgue, devicetree,
linux-arm-kernel, linux-kernel, netdev
In-Reply-To: <20170821132015.GB1703@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 770 bytes --]
Hi Andrew,
On Mon, Aug 21, 2017 at 03:20:15PM +0200, Andrew Lunn wrote:
> > With our hardware, and likely Rockchip's as well, the muxed connections
> > include the MDIO and MII connections
>
> Ah, i did not realise the MII was muxed as well. Then i agree, an MDIO
> mux is wrong.
>
> However, please try to make the binding not look like an mdio mux. We
> don't want people misunderstanding the binding and thinking it is an
> mdio mux.
Do you have any suggestion on what the binding would look like?
All muxes are mostly always represented the same way afaik, or do you
want to simply introduce a new compatible / property?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] vhost-net: revert vhost_exceeds_maxpend logic to its original
From: Koichiro Den @ 2017-08-21 13:32 UTC (permalink / raw)
To: Jason Wang, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <047bb207-cec6-ece5-470f-340d7c5ee7b7@redhat.com>
On Mon, 2017-08-21 at 20:40 +0800, Jason Wang wrote:
>
> On 2017年08月21日 11:06, Jason Wang wrote:
> >
> >
> > On 2017年08月19日 14:41, Koichiro Den wrote:
> > > To depend on vq.num and the usage of VHOST_MAX_PEND is not succinct
> > > and in some case unexpected, so revert its logic part only.
> >
> > Hi:
> >
> > Could you explain a little bit more on the case that is was not
> > sufficent?
> >
> > Thanks
>
> Just have another thought.
>
> I wonder whether or not just use ulimit(memlock) is better here. It
> looks more flexible.
>
> Thanks
It sounds a better approach, though at present I have got no idea how much
portion it should be.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 3/6] mpls: add VPLS entry points
From: Amine Kherbouche @ 2017-08-21 14:01 UTC (permalink / raw)
To: David Lamparter, netdev; +Cc: roopa
In-Reply-To: <20170816170202.456851-4-equinox@diac24.net>
On 08/16/2017 07:01 PM, David Lamparter wrote:
> This wires up the neccessary calls for VPLS into the MPLS forwarding
> pieces. Since CONFIG_MPLS_VPLS doesn't exist yet in Kconfig, it'll
> never be enabled, so we're on the stubs for now.
>
> Signed-off-by: David Lamparter <equinox@diac24.net>
> ---
> include/uapi/linux/rtnetlink.h | 1 +
> net/mpls/af_mpls.c | 54 ++++++++++++++++++++++++++++++++++++++++++
> net/mpls/internal.h | 29 +++++++++++++++++++++++
> 3 files changed, 84 insertions(+)
>
> diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
> index dab7dad9e01a..b7840ed94526 100644
> --- a/include/uapi/linux/rtnetlink.h
> +++ b/include/uapi/linux/rtnetlink.h
> @@ -326,6 +326,7 @@ enum rtattr_type_t {
> RTA_PAD,
> RTA_UID,
> RTA_TTL_PROPAGATE,
> + RTA_VPLS_IF,
> __RTA_MAX
> };
>
> diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
> index 0c5953e5d5bd..4d3ce007b7db 100644
> --- a/net/mpls/af_mpls.c
> +++ b/net/mpls/af_mpls.c
> @@ -299,6 +299,11 @@ static bool mpls_egress(struct net *net, struct mpls_route *rt,
> success = true;
> break;
> }
> + case MPT_VPLS:
> + /* nothing to do here, no TTL in Ethernet
> + * (and we shouldn't mess with the TTL in inner IP packets,
> + * pseudowires are supposed to be transparent) */
> + break;
> case MPT_UNSPEC:
> /* Should have decided which protocol it is by now */
> break;
> @@ -349,6 +354,8 @@ static int mpls_forward(struct sk_buff *skb, struct net_device *dev,
> goto drop;
> }
>
> + if (rt->rt_payload_type == MPT_VPLS)
> + return vpls_rcv(skb, dev, pt, rt, hdr, orig_dev);
you should get the ret value of vpls_rcv() and increment stats if error
occurs.
int ret;
ret = vpls_rc(...)
if (ret)
goto err;
return NET_RX_SUCCESS;
>
> /* Pop the label */
> skb_pull(skb, sizeof(*hdr));
> @@ -469,6 +476,7 @@ static const struct nla_policy rtm_mpls_policy[RTA_MAX+1] = {
> struct mpls_route_config {
> u32 rc_protocol;
> u32 rc_ifindex;
> + u32 rc_vpls_ifindex;
> u8 rc_via_table;
> u8 rc_via_alen;
> u8 rc_via[MAX_VIA_ALEN];
> @@ -541,6 +549,8 @@ static void mpls_route_update(struct net *net, unsigned index,
> rt = rtnl_dereference(platform_label[index]);
> rcu_assign_pointer(platform_label[index], new);
>
> + vpls_label_update(index, rt, new);
> +
> mpls_notify_route(net, index, rt, new, info);
>
> /* If we removed a route free it now */
> @@ -942,6 +952,7 @@ static int mpls_route_add(struct mpls_route_config *cfg,
> struct mpls_route __rcu **platform_label;
> struct net *net = cfg->rc_nlinfo.nl_net;
> struct mpls_route *rt, *old;
> + struct net_device *vpls_dev = NULL;
> int err = -EINVAL;
> u8 max_via_alen;
> unsigned index;
> @@ -996,6 +1007,24 @@ static int mpls_route_add(struct mpls_route_config *cfg,
> goto errout;
> }
>
> + if (cfg->rc_vpls_ifindex) {
> + vpls_dev = dev_get_by_index(net, cfg->rc_vpls_ifindex);
> + if (!vpls_dev) {
> + err = -ENODEV;
> + NL_SET_ERR_MSG(extack, "Invalid VPLS ifindex");
> + goto errout;
> + }
> + /* we're under RTNL; and we'll drop routes when we're
> + * notified the device is going away. */
> + dev_put(vpls_dev);
> +
> + if (!is_vpls_dev(vpls_dev)) {
> + err = -ENODEV;
> + NL_SET_ERR_MSG(extack, "Not a VPLS device");
> + goto errout;
> + }
> + }
> +
> err = -ENOMEM;
> rt = mpls_rt_alloc(nhs, max_via_alen, max_labels);
> if (IS_ERR(rt)) {
> @@ -1006,6 +1035,7 @@ static int mpls_route_add(struct mpls_route_config *cfg,
> rt->rt_protocol = cfg->rc_protocol;
> rt->rt_payload_type = cfg->rc_payload_type;
> rt->rt_ttl_propagate = cfg->rc_ttl_propagate;
> + rt->rt_vpls_dev = vpls_dev;
>
> if (cfg->rc_mp)
> err = mpls_nh_build_multi(cfg, rt, max_labels, extack);
> @@ -1430,6 +1460,14 @@ static void mpls_ifdown(struct net_device *dev, int event)
> if (!rt)
> continue;
>
> + if (rt->rt_vpls_dev == dev) {
> + switch (event) {
> + case NETDEV_UNREGISTER:
> + mpls_route_update(net, index, NULL, NULL);
> + continue;
> + }
> + }
> +
> alive = 0;
> deleted = 0;
> change_nexthops(rt) {
> @@ -1777,6 +1815,10 @@ static int rtm_to_route_config(struct sk_buff *skb,
> case RTA_OIF:
> cfg->rc_ifindex = nla_get_u32(nla);
> break;
> + case RTA_VPLS_IF:
> + cfg->rc_vpls_ifindex = nla_get_u32(nla);
> + cfg->rc_payload_type = MPT_VPLS;
> + break;
> case RTA_NEWDST:
> if (nla_get_labels(nla, MAX_NEW_LABELS,
> &cfg->rc_output_labels,
> @@ -1911,6 +1953,11 @@ static int mpls_dump_route(struct sk_buff *skb, u32 portid, u32 seq, int event,
> ttl_propagate))
> goto nla_put_failure;
> }
> +
> + if (rt->rt_vpls_dev)
> + if (nla_put_u32(skb, RTA_VPLS_IF, rt->rt_vpls_dev->ifindex))
> + goto nla_put_failure;
> +
> if (rt->rt_nhn == 1) {
> const struct mpls_nh *nh = rt->rt_nh;
>
> @@ -2220,6 +2267,10 @@ static int mpls_getroute(struct sk_buff *in_skb, struct nlmsghdr *in_nlh,
> if (nla_put_labels(skb, RTA_DST, 1, &in_label))
> goto nla_put_failure;
>
> + if (rt->rt_vpls_dev)
> + if (nla_put_u32(skb, RTA_VPLS_IF, rt->rt_vpls_dev->ifindex))
> + goto nla_put_failure;
> +
> if (nh->nh_labels &&
> nla_put_labels(skb, RTA_NEWDST, nh->nh_labels,
> nh->nh_label))
> @@ -2491,6 +2542,8 @@ static int __init mpls_init(void)
>
> rtnl_af_register(&mpls_af_ops);
>
> + vpls_init();
> +
> rtnl_register(PF_MPLS, RTM_NEWROUTE, mpls_rtm_newroute, NULL, 0);
> rtnl_register(PF_MPLS, RTM_DELROUTE, mpls_rtm_delroute, NULL, 0);
> rtnl_register(PF_MPLS, RTM_GETROUTE, mpls_getroute, mpls_dump_routes,
> @@ -2510,6 +2563,7 @@ module_init(mpls_init);
> static void __exit mpls_exit(void)
> {
> rtnl_unregister_all(PF_MPLS);
> + vpls_exit();
> rtnl_af_unregister(&mpls_af_ops);
> dev_remove_pack(&mpls_packet_type);
> unregister_netdevice_notifier(&mpls_dev_notifier);
> diff --git a/net/mpls/internal.h b/net/mpls/internal.h
> index b70c6663d4f3..876ae9993207 100644
> --- a/net/mpls/internal.h
> +++ b/net/mpls/internal.h
> @@ -76,6 +76,7 @@ struct sk_buff;
>
> enum mpls_payload_type {
> MPT_UNSPEC, /* IPv4 or IPv6 */
> + MPT_VPLS = 2, /* pseudowire */
> MPT_IPV4 = 4,
> MPT_IPV6 = 6,
>
> @@ -153,6 +154,8 @@ struct mpls_route { /* next hop label forwarding entry */
> u8 rt_nh_size;
> u8 rt_via_offset;
> u8 rt_reserved1;
> + struct net_device *rt_vpls_dev;
> +
> struct mpls_nh rt_nh[0];
> };
>
> @@ -214,4 +217,30 @@ struct mpls_route *mpls_route_input_rcu(struct net *net, unsigned index);
> int mpls_rt_xmit(struct sk_buff *skb, struct mpls_route *rt,
> struct mpls_entry_decoded dec);
>
> +#ifdef CONFIG_MPLS_VPLS
> +int vpls_rcv(struct sk_buff *skb, struct net_device *in_dev,
> + struct packet_type *pt, struct mpls_route *rt,
> + struct mpls_shim_hdr *hdr, struct net_device *orig_dev);
> +void vpls_label_update(unsigned label, struct mpls_route *rt_old,
> + struct mpls_route *rt_new);
> +__init int vpls_init(void);
> +__exit void vpls_exit(void);
> +int is_vpls_dev(struct net_device *dev);
> +
> +#else /* !CONFIG_MPLS_VPLS */
> +static inline int vpls_rcv(skb, in_dev, pt, rt, hdr, orig_dev)
> +{
> + kfree_skb(skb);
> + return NET_RX_DROP;
just return NET_RX_DROP;
> +}
> +static inline int is_vpls_dev(struct net_device *dev)
> +{
> + return 0;
> +}
> +
> +#define vpls_label_update(label, rt_old, rt_new) do { } while (0)
> +#define vpls_init() do { } while (0)
> +#define vpls_exit() do { } while (0)
> +#endif
s/ #endif/#endif /* CONFIG_MPLS_VPLS *//
> +
> #endif /* MPLS_INTERNAL_H */
>
^ permalink raw reply
* Re: [RFC PATCH] dt-binding: net: sfp binding documentation
From: Andrew Lunn @ 2017-08-21 14:05 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Baruch Siach, Rob Herring, Mark Rutland, Florian Fainelli,
David S . Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170821125317.GS20805-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
> The implementation that I've designed is based around the boards that
> I have access to and the various public SFP documentation. I think
> documenting the bindings suggests that they are stable - I don't think
> we're really ready to make that assertion yet - there may be things
> that have been missed which will only come up when other people start
> using this code.
Hi Russell
That was the point of merging the code. It gets it into people hands
so they can start using it. I want to add support for DSA to make use
of phylink, since i have a couple of boards with SFF connected to
switch ports. I know Cumulus have interest in the code, for their
switches and so do Westermo.
Andrew
--
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: Something hitting my total number of connections to the server
From: Neal Cardwell @ 2017-08-21 14:17 UTC (permalink / raw)
To: Akshat Kakkar; +Cc: David Laight, Eric Dumazet, netdev
In-Reply-To: <CAA5aLPhVSnJkGNtwEeswbPnhT_RdJewAKDs-pJOUzTPEpwkUAA@mail.gmail.com>
On Mon, Aug 21, 2017 at 5:56 AM, Akshat Kakkar <akshat.1984@gmail.com> wrote:
>
> The issue is with tcp timestamp. When I am disabling it, things are
> working fine but when I enable the issue re-occurs. However, I am not
> seeing tcp timestamps on packet, even when it is enabled simply
> because my client doesn't support it.
>
> But the question is, if I my client doesnt support timestamp , why
> enabling timestamp on server side is creating an issue??
To help shed light on this, you could try collecting and dumping the
nstat counters when the system is in the mode where it is not
creating/accepting new connections, e.g.:
nstat > /dev/null && sleep 10 && nstat
The sleep interval would need to be long enough to cover a failing
client connect attempt. It would also be helpful to gather a tcpdump
trace over the interval, to see if the server is sending a RST,
SYN+ACK, or nothing.
neal
^ permalink raw reply
* Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac
From: Andrew Lunn @ 2017-08-21 14:23 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Corentin Labbe, Rob Herring, Mark Rutland,
Russell King, Giuseppe Cavallaro, Alexandre Torgue, devicetree,
linux-arm-kernel, linux-kernel, netdev
In-Reply-To: <20170821133104.qvrhvwin2rdg4aqo-ZC1Zs529Oq4@public.gmane.org>
> All muxes are mostly always represented the same way afaik, or do you
> want to simply introduce a new compatible / property?
+ mdio-mux {
+ compatible = "allwinner,sun8i-h3-mdio-switch";
+ mdio-parent-bus = <&mdio_parent>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ internal_mdio: mdio@1 {
reg = <1>;
- clocks = <&ccu CLK_BUS_EPHY>;
- resets = <&ccu RST_BUS_EPHY>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_mii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ phy-is-integrated;
+ };
+ };
+ mdio: mdio@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
};
Hi Maxim
Anybody who knows the MDIO-mux code/binding, knows that it is a run
time mux. You swap the mux per MDIO transaction. You can access all
the PHY and switches on the mux'ed MDIO bus.
However here, it is effectively a boot-time MUX. You cannot change it
on the fly. What happens when somebody has a phandle to a PHY on the
internal and a phandle to a phy on the external? Does the driver at
least return -EINVAL, or -EBUSY? Is there a representation which
eliminates this possibility?
Andrew
--
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 v2 2/2] net: phy: Don't use drv when it is NULL in phy_attached_print
From: Andrew Lunn @ 2017-08-21 14:24 UTC (permalink / raw)
To: Romain Perier
Cc: Giuseppe Cavallaro, Alexandre Torgue, Florian Fainelli, netdev,
linux-kernel
In-Reply-To: <20170821114530.13706-3-romain.perier@collabora.com>
On Mon, Aug 21, 2017 at 01:45:30PM +0200, Romain Perier wrote:
> Currently, if this logging function is used prior the phy driver is
> bound to the phy device (that is usually done from .ndo_open),
> 'phydev->drv' might be NULL, resulting in a kernel crash. That is
> typically the case in the stmmac driver, info about the phy is displayed
> during the registration of the MDIO bus, and then genphy driver is bound
> to this phydev when .ndo_open is called.
>
> This commit fixes the issue by using the right genphy driver, when
> phydev->drv is NULL.
>
> Fixes: fbca164776e4 ("net: stmmac: Use the right logging functi")
> Signed-off-by: Romain Perier <romain.perier@collabora.com>
> ---
> drivers/net/phy/phy_device.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 1790f7fec125..6af6dc6dfeaf 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -864,15 +864,24 @@ EXPORT_SYMBOL(phy_attached_info);
> #define ATTACHED_FMT "attached PHY driver [%s] (mii_bus:phy_addr=%s, irq=%d)"
> void phy_attached_print(struct phy_device *phydev, const char *fmt, ...)
> {
> + struct phy_driver *drv = phydev->drv;
> +
> + if (!drv) {
> + if (phydev->is_c45)
> + drv = &genphy_10g_driver;
> + else
> + drv = &genphy_driver;
> + }
> +
As i said in my comment to v1, i don't like this.
Andrew
^ permalink raw reply
* Re: [PATCH V3 net-next] net: hns3: Add support to change MTU in HNS3 hardware
From: Andrew Lunn @ 2017-08-21 14:29 UTC (permalink / raw)
To: Salil Mehta
Cc: davem, yisen.zhuang, lipeng321, mehta.salil.lnk, netdev,
linux-kernel, linux-rdma, linuxarm
In-Reply-To: <20170821101223.111852-1-salil.mehta@huawei.com>
On Mon, Aug 21, 2017 at 11:12:23AM +0100, Salil Mehta wrote:
> This patch adds the following support to the HNS3 driver:
> 1. Support to change the Maximum Transmission Unit of a
> of a port in the HNS NIC hardware.
> 2. Initializes the supported MTU range for the netdevice.
>
> Signed-off-by: lipeng <lipeng321@huawei.com>
> Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Hi Salil
Apart from Leon comments.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* RE: [PATCH V3 net-next] net: hns3: Add support to change MTU in HNS3 hardware
From: Salil Mehta @ 2017-08-21 14:32 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
Zhuangyuzeng (Yisen), lipeng (Y),
mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linuxarm
In-Reply-To: <20170821142939.GG1703-g2DYL2Zd6BY@public.gmane.org>
Hi Andrew,
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew-g2DYL2Zd6BY@public.gmane.org]
> Sent: Monday, August 21, 2017 3:30 PM
> To: Salil Mehta
> Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org; Zhuangyuzeng (Yisen); lipeng (Y);
> mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm
> Subject: Re: [PATCH V3 net-next] net: hns3: Add support to change MTU
> in HNS3 hardware
>
> On Mon, Aug 21, 2017 at 11:12:23AM +0100, Salil Mehta wrote:
> > This patch adds the following support to the HNS3 driver:
> > 1. Support to change the Maximum Transmission Unit of a
> > of a port in the HNS NIC hardware.
> > 2. Initializes the supported MTU range for the netdevice.
> >
> > Signed-off-by: lipeng <lipeng321-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > Signed-off-by: Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>
> Hi Salil
>
> Apart from Leon comments.
>
> Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
>
> Andrew
I will incorporate Leon's comment and float V4 patch today. Thanks!
Best regards
Salil
--
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
* [PATCH V4 net-next] net: hns3: Add support to change MTU in HNS3 hardware
From: Salil Mehta @ 2017-08-21 14:40 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: salil.mehta-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
lipeng321-hv44wF8Li93QT0dZR+AlfA,
mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA
This patch adds the following support to the HNS3 driver:
1. Support to change the Maximum Transmission Unit of a
port in the HNS NIC hardware.
2. Initializes the supported MTU range for the netdevice.
Signed-off-by: lipeng <lipeng321-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Signed-off-by: Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
PATCH V4: Addressed some minor comments Leon Romanovsky
1. https://lkml.org/lkml/2017/8/21/212
PATCH V3: Addressed some minor comments Leon Romanovsky
1. https://lkml.org/lkml/2017/8/20/27
PATCH V2: Addresses comments given by Andrew Lunn
1. https://lkml.org/lkml/2017/8/18/282
PATCH V1: Initial Submit
---
.../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 34 ++++++++++++++++++++++
.../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h | 1 +
2 files changed, 35 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
index e731f87..1c3e294 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -1278,11 +1278,42 @@ static int hns3_ndo_set_vf_vlan(struct net_device *netdev, int vf, u16 vlan,
return ret;
}
+static int hns3_nic_change_mtu(struct net_device *netdev, int new_mtu)
+{
+ struct hns3_nic_priv *priv = netdev_priv(netdev);
+ struct hnae3_handle *h = priv->ae_handle;
+ bool if_running = netif_running(netdev);
+ int ret;
+
+ if (!h->ae_algo->ops->set_mtu)
+ return -EOPNOTSUPP;
+
+ /* if this was called with netdev up then bring netdevice down */
+ if (if_running) {
+ (void)hns3_nic_net_stop(netdev);
+ msleep(100);
+ }
+
+ ret = h->ae_algo->ops->set_mtu(h, new_mtu);
+ if (ret) {
+ netdev_err(netdev, "failed to change MTU in hardware %d\n",
+ ret);
+ return ret;
+ }
+
+ /* if the netdev was running earlier, bring it up again */
+ if (if_running && hns3_nic_net_open(netdev))
+ ret = -EINVAL;
+
+ return ret;
+}
+
static const struct net_device_ops hns3_nic_netdev_ops = {
.ndo_open = hns3_nic_net_open,
.ndo_stop = hns3_nic_net_stop,
.ndo_start_xmit = hns3_nic_net_xmit,
.ndo_set_mac_address = hns3_nic_net_set_mac_address,
+ .ndo_change_mtu = hns3_nic_change_mtu,
.ndo_set_features = hns3_nic_set_features,
.ndo_get_stats64 = hns3_nic_get_stats64,
.ndo_setup_tc = hns3_nic_setup_tc,
@@ -2752,6 +2783,9 @@ static int hns3_client_init(struct hnae3_handle *handle)
goto out_reg_netdev_fail;
}
+ /* MTU range: (ETH_MIN_MTU(kernel default) - 9706) */
+ netdev->max_mtu = HNS3_MAX_MTU - (ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN);
+
return ret;
out_reg_netdev_fail:
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
index a6e8f15..7e87461 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
@@ -76,6 +76,7 @@ enum hns3_nic_state {
#define HNS3_RING_NAME_LEN 16
#define HNS3_BUFFER_SIZE_2048 2048
#define HNS3_RING_MAX_PENDING 32768
+#define HNS3_MAX_MTU 9728
#define HNS3_BD_SIZE_512_TYPE 0
#define HNS3_BD_SIZE_1024_TYPE 1
--
2.7.4
--
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 related
* [iproute PATCH v2] lib/bpf: Don't leak fp in bpf_find_mntpt()
From: Phil Sutter @ 2017-08-21 14:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
If fopen() succeeded but len != PATH_MAX, the function leaks the open
FILE pointer. Fix this by checking len value before calling fopen().
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
---
No change since v1, just resubmitting - I forgot to add it to the
relevant patch chunk when splitting the big series up. Added Daniel's
ACK from his v1 review.
---
lib/bpf.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/bpf.c b/lib/bpf.c
index 4f52ad4a8f023..1dcb261dc915f 100644
--- a/lib/bpf.c
+++ b/lib/bpf.c
@@ -537,8 +537,11 @@ static const char *bpf_find_mntpt(const char *fstype, unsigned long magic,
}
}
+ if (len != PATH_MAX)
+ return NULL;
+
fp = fopen("/proc/mounts", "r");
- if (fp == NULL || len != PATH_MAX)
+ if (fp == NULL)
return NULL;
while (fscanf(fp, "%*s %" textify(PATH_MAX) "s %99s %*s %*d %*d\n",
--
2.13.1
^ permalink raw reply related
* Re: [PATCH V3 net-next] net: hns3: Add support to change MTU in HNS3 hardware
From: Leon Romanovsky @ 2017-08-21 14:47 UTC (permalink / raw)
To: Salil Mehta
Cc: Andrew Lunn, davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
Zhuangyuzeng (Yisen), lipeng (Y),
mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linuxarm
In-Reply-To: <F4CC6FACFEB3C54C9141D49AD221F7F93B875655-WFPaWmAhWqtUuCJht5byYAK1hpo4iccwjNknBlVQO8k@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]
On Mon, Aug 21, 2017 at 02:32:40PM +0000, Salil Mehta wrote:
> Hi Andrew,
>
> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew-g2DYL2Zd6BY@public.gmane.org]
> > Sent: Monday, August 21, 2017 3:30 PM
> > To: Salil Mehta
> > Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org; Zhuangyuzeng (Yisen); lipeng (Y);
> > mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> > kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm
> > Subject: Re: [PATCH V3 net-next] net: hns3: Add support to change MTU
> > in HNS3 hardware
> >
> > On Mon, Aug 21, 2017 at 11:12:23AM +0100, Salil Mehta wrote:
> > > This patch adds the following support to the HNS3 driver:
> > > 1. Support to change the Maximum Transmission Unit of a
> > > of a port in the HNS NIC hardware.
> > > 2. Initializes the supported MTU range for the netdevice.
> > >
> > > Signed-off-by: lipeng <lipeng321-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > Signed-off-by: Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >
> > Hi Salil
> >
> > Apart from Leon comments.
> >
> > Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> >
> > Andrew
>
> I will incorporate Leon's comment and float V4 patch today. Thanks!
>
Salil,
I had two comment there and not one. Please don't miss it :)
Thanks
> Best regards
> Salil
> --
> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH V4 net-next] net: hns3: Add support to change MTU in HNS3 hardware
From: Leon Romanovsky @ 2017-08-21 14:48 UTC (permalink / raw)
To: Salil Mehta
Cc: davem, yisen.zhuang, lipeng321, mehta.salil.lnk, netdev,
linux-kernel, linux-rdma, linuxarm
In-Reply-To: <20170821144003.49436-1-salil.mehta@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]
On Mon, Aug 21, 2017 at 03:40:03PM +0100, Salil Mehta wrote:
> This patch adds the following support to the HNS3 driver:
> 1. Support to change the Maximum Transmission Unit of a
> port in the HNS NIC hardware.
> 2. Initializes the supported MTU range for the netdevice.
>
> Signed-off-by: lipeng <lipeng321@huawei.com>
> Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> ---
> PATCH V4: Addressed some minor comments Leon Romanovsky
> 1. https://lkml.org/lkml/2017/8/21/212
> PATCH V3: Addressed some minor comments Leon Romanovsky
> 1. https://lkml.org/lkml/2017/8/20/27
> PATCH V2: Addresses comments given by Andrew Lunn
> 1. https://lkml.org/lkml/2017/8/18/282
> PATCH V1: Initial Submit
> ---
> .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 34 ++++++++++++++++++++++
> .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h | 1 +
> 2 files changed, 35 insertions(+)
>
Wrong error code is not "minor" comment.
Thanks,
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [PATCH V4 net-next] net: hns3: Add support to change MTU in HNS3 hardware
From: Salil Mehta @ 2017-08-21 14:49 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
Cc: Zhuangyuzeng (Yisen), lipeng (Y),
mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linuxarm
In-Reply-To: <20170821144003.49436-1-salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Sorry, Please ignore this mail.
I forgot to add the Andrew Lunn signed-off-by Tag will this patch.
I will add the tag and send the updated version of V4 again.
Sorry again.
> -----Original Message-----
> From: Salil Mehta
> Sent: Monday, August 21, 2017 3:40 PM
> To: davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
> Cc: Salil Mehta; Zhuangyuzeng (Yisen); lipeng (Y);
> mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm
> Subject: [PATCH V4 net-next] net: hns3: Add support to change MTU in
> HNS3 hardware
>
> This patch adds the following support to the HNS3 driver:
> 1. Support to change the Maximum Transmission Unit of a
> port in the HNS NIC hardware.
> 2. Initializes the supported MTU range for the netdevice.
>
> Signed-off-by: lipeng <lipeng321-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> ---
> PATCH V4: Addressed some minor comments Leon Romanovsky
> 1. https://lkml.org/lkml/2017/8/21/212
> PATCH V3: Addressed some minor comments Leon Romanovsky
> 1. https://lkml.org/lkml/2017/8/20/27
> PATCH V2: Addresses comments given by Andrew Lunn
> 1. https://lkml.org/lkml/2017/8/18/282
> PATCH V1: Initial Submit
> ---
> .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 34
> ++++++++++++++++++++++
> .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h | 1 +
> 2 files changed, 35 insertions(+)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
> index e731f87..1c3e294 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
> @@ -1278,11 +1278,42 @@ static int hns3_ndo_set_vf_vlan(struct
> net_device *netdev, int vf, u16 vlan,
> return ret;
> }
>
> +static int hns3_nic_change_mtu(struct net_device *netdev, int new_mtu)
> +{
> + struct hns3_nic_priv *priv = netdev_priv(netdev);
> + struct hnae3_handle *h = priv->ae_handle;
> + bool if_running = netif_running(netdev);
> + int ret;
> +
> + if (!h->ae_algo->ops->set_mtu)
> + return -EOPNOTSUPP;
> +
> + /* if this was called with netdev up then bring netdevice down */
> + if (if_running) {
> + (void)hns3_nic_net_stop(netdev);
> + msleep(100);
> + }
> +
> + ret = h->ae_algo->ops->set_mtu(h, new_mtu);
> + if (ret) {
> + netdev_err(netdev, "failed to change MTU in hardware %d\n",
> + ret);
> + return ret;
> + }
> +
> + /* if the netdev was running earlier, bring it up again */
> + if (if_running && hns3_nic_net_open(netdev))
> + ret = -EINVAL;
> +
> + return ret;
> +}
> +
> static const struct net_device_ops hns3_nic_netdev_ops = {
> .ndo_open = hns3_nic_net_open,
> .ndo_stop = hns3_nic_net_stop,
> .ndo_start_xmit = hns3_nic_net_xmit,
> .ndo_set_mac_address = hns3_nic_net_set_mac_address,
> + .ndo_change_mtu = hns3_nic_change_mtu,
> .ndo_set_features = hns3_nic_set_features,
> .ndo_get_stats64 = hns3_nic_get_stats64,
> .ndo_setup_tc = hns3_nic_setup_tc,
> @@ -2752,6 +2783,9 @@ static int hns3_client_init(struct hnae3_handle
> *handle)
> goto out_reg_netdev_fail;
> }
>
> + /* MTU range: (ETH_MIN_MTU(kernel default) - 9706) */
> + netdev->max_mtu = HNS3_MAX_MTU - (ETH_HLEN + ETH_FCS_LEN +
> VLAN_HLEN);
> +
> return ret;
>
> out_reg_netdev_fail:
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
> index a6e8f15..7e87461 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h
> @@ -76,6 +76,7 @@ enum hns3_nic_state {
> #define HNS3_RING_NAME_LEN 16
> #define HNS3_BUFFER_SIZE_2048 2048
> #define HNS3_RING_MAX_PENDING 32768
> +#define HNS3_MAX_MTU 9728
>
> #define HNS3_BD_SIZE_512_TYPE 0
> #define HNS3_BD_SIZE_1024_TYPE 1
> --
> 2.7.4
>
--
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] ethernet: xircom: small clean up in setup_xirc2ps_cs()
From: David Laight @ 2017-08-21 14:52 UTC (permalink / raw)
To: 'Dan Carpenter', Jarod Wilson
Cc: David S. Miller, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org, Ilya Matveychikov, Baoquan He,
Andrew Morton, Ingo Molnar, linux-kernel@vger.kernel.org
In-Reply-To: <20170821094730.ydm2xwsqbkyadybi@mwanda>
From: Dan Carpenter
> Sent: 21 August 2017 10:48
> The get_options() function takes the whole ARRAY_SIZE(). It doesn't
> matter here because we don't use more than 7 elements.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/net/ethernet/xircom/xirc2ps_cs.c b/drivers/net/ethernet/xircom/xirc2ps_cs.c
> index f71883264cc0..fd5288ff53b5 100644
> --- a/drivers/net/ethernet/xircom/xirc2ps_cs.c
> +++ b/drivers/net/ethernet/xircom/xirc2ps_cs.c
> @@ -1781,7 +1781,7 @@ static int __init setup_xirc2ps_cs(char *str)
> */
> int ints[10] = { -1 };
>
> - str = get_options(str, 9, ints);
> + str = get_options(str, ARRAY_SIZE(ints), ints);
>
> #define MAYBE_SET(X,Y) if (ints[0] >= Y && ints[Y] != -1) { X = ints[Y]; }
> MAYBE_SET(if_port, 3);
That code looks very dubious to me.
It looks as though it expects all of the ints[] array to be initialised
to -1, not just the first element.
David
^ permalink raw reply
* Re: Re: [PATCH 2/4] dt-bindings: add binding for RTL8211E Ethernet PHY
From: icenowy-h8G6r0blFSE @ 2017-08-21 14:53 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Rob Herring, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <068f1323-3864-620c-0deb-6c5e04a9e498-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
在 2017-05-05 02:29，Florian Fainelli 写道：
> On 05/04/2017 11:26 AM, Icenowy Zheng wrote:
>>
>>
>> 于 2017年5月5日 GMT+08:00 上午2:21:29, Florian Fainelli
>> <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 写到:
>>> On 05/04/2017 11:10 AM, icenowy-h8G6r0blFSE@public.gmane.org wrote:
>>>> 在 2017-04-22 08:22，Florian Fainelli 写道：
>>>>> On 04/21/2017 04:24 PM, Icenowy Zheng wrote:
>>>>>> From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>>>>>
>>>>>> Some RTL8211E Ethernet PHY have an issue that needs a workaround
>>>>>> indicated with device tree.
>>>>>>
>>>>>> Add the binding for a property that indicates this workaround.
>>>>>>
>>>>>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>>>>> ---
>>>>>> .../devicetree/bindings/net/realtek,rtl8211e.txt | 22
>>>>>> ++++++++++++++++++++++
>>>>>> 1 file changed, 22 insertions(+)
>>>>>> create mode 100644
>>>>>> Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>>>>>>
>>>>>> diff --git
>>>>>> a/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>>>>>> b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>>>>>> new file mode 100644
>>>>>> index 000000000000..c1913301bfe8
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>>>>>> @@ -0,0 +1,22 @@
>>>>>> +Realtek RTL8211E Ethernet PHY
>>>>>> +
>>>>>> +One batch of RTL8211E is slight broken, that needs some special
>>> (and
>>>>>> +full of magic numbers) tweaking in order to make GbE to operate
>>>>>> properly.
>>>>>> +The only well-known board that used the broken batch is Pine64+.
>>>>>> +Configure it through an Ethernet OF device node.
>>>>>> +
>>>>>> +Optional properties:
>>>>>> +
>>>>>> +- realtek,disable-rx-delay:
>>>>>> + If set, RX delay will be completely disabled (according to
>>>>>> Realtek). This
>>>>>> + will affect the performance on non-broken boards.
>>>>>> + default: do not disable RX delay.
>>>>>
>>>>> Please don't introduce custom properties to do that, instead
>>>>> correct
>>>>> specify the "phy-mode" such that it is e.g: "rgmii-txid" which
>>> indicates
>>>>> that there should be no RX internal delay, but a TX internal delay
>>> added
>>>>> by the PHY.
>>>>
>>>> Checked the document, the meaning of "rgmii-txid" is not correct
>>> here.
>>>>
>>>> This doesn't effect the MAC, and the MAC should still add TX delay.
>>>>
>>>> The definition of "rgmii-txid" in
>>>> Documentation/devicetree/binding/net/ethernet.txt is "RGMII with
>>>> internal TX delay provided by the PHY, the MAC should not add an TX
>>> delay
>>>> in this case". However, this do not indicate that the MAC doesn't
>>>> add
>>> TX
>>>> delay; in fact that just totally disabled the PHY to provide the RX
>>> delay.
>>>> MAC still should to add delay on both TX/RX, which is the semantic
>>>> of
>>>> standard "rgmii".
>>>>
>>>> So I cannot used "rgmii-txid" here, but should continue to use this
>>>> custom property.
Sorry for replying an old email, but it's because the driver of the MAC
I
used is merged (dwmac-sun8i).
The driver of the MAC currently only supports "mii", "rmii", and
"rgmii",
and according to the SoC's user manual, the MAC cannot has its delays
disabled.
How should it handle this "rgmii-txid" here? Just treat it as "rgmii"?
>>>
>>> This is absolutely not a correct understanding. The 'phy-mode'
>>> property
>>> defines the contract between the MAC and PHY. It is defined from the
>>> PHY's perspective of the delay, which means that the MAC has to
>>> either
>>> also provide an adequate delay (RX or TX) or not (RX or TX). So if
>>> you
>>> specified 'phy-mode' = "rgmii" this means that the MAC needs to adds
>>> the
>>> TX and RX delay, so implcitly this means that your MAC operates in
>>
>> The MAC doesn't lose its responsibility to tweak RX/TX delays with
>> this property set.
>
> No it does not but now there is no contract binding the MAC and the PHY
> together was to what an appropriate delay configuration there should
> be.
> This is why using phydev->interface (directly inherited from
> 'phy-mode')
> is important because it binds the PHY and MAC on a contract.
>
>>
>> This situation is that, the PHY's RX delay tweaking function is
>> broken. But it doesn't mean that the PHY can take over *all*
>> responsibility to tweak TX, it still needs MAC to tweak TX.
>
> Correct, so what part of my answer was not clear in that sense?
>
>>
>>> "rgmii-id", if the property was defined from the perspective of the
>>> MAC,
>>> which it is not.
>>>
>>> Both the Ethernet PHY driver and the MAC driver need to take care of
>>> adjusting the delays based on the phydev->interface value.
>>>
>>> The property you are introducing here is absolutely not appropriate
>>> because it is entirely redundant with what 'phy-mode' already
>>> defines,
>>> except the latter also covers a lot more cases.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* RE: [iproute PATCH v3 4/5] tc/tc_filter: Make sure filter name is not empty
From: David Laight @ 2017-08-21 14:53 UTC (permalink / raw)
To: 'Phil Sutter', Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20170821100308.24854-5-phil@nwl.cc>
From: Phil Sutter
> Sent: 21 August 2017 11:03
> To: Stephen Hemminger
> Cc: netdev@vger.kernel.org
> Subject: [iproute PATCH v3 4/5] tc/tc_filter: Make sure filter name is not empty
>
> The later check for 'k[0] != 0' requires a non-empty filter name,
> otherwise NULL pointer dereference in 'q' might happen.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
> Changes since v2:
> - Instead of calling strlen(), just make sure **argv is not 0.
> ---
> tc/tc_filter.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tc/tc_filter.c b/tc/tc_filter.c
> index b13fb9185d4fd..cf290ae8e252c 100644
> --- a/tc/tc_filter.c
> +++ b/tc/tc_filter.c
> @@ -412,6 +412,9 @@ static int tc_filter_get(int cmd, unsigned int flags, int argc, char **argv)
> usage();
> return 0;
> } else {
> + if (!**argv)
> + invarg("invalid filter name", *argv);
> +
The error message won't make sense...
David
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox