* Re: [PATCH net-next] net: fix double-free in bpf_lwt_xmit_reroute
From: David Miller @ 2019-02-25 6:25 UTC (permalink / raw)
To: posk; +Cc: netdev, posk
In-Reply-To: <20190224022501.71889-1-posk@google.com>
From: Peter Oskolkov <posk@google.com>
Date: Sat, 23 Feb 2019 18:25:01 -0800
> dst_output() frees skb when it fails (see, for example,
> ip_finish_output2), so it must not be freed in this case.
>
> Fixes: 3bd0b15281af ("bpf: add handling of BPF_LWT_REROUTE to lwt_bpf.c")
> Signed-off-by: Peter Oskolkov <posk@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ip_tunnel: Add ip tunnel tunnel_info dst_cache in ip_tunnel_xmit
From: Dan Carpenter @ 2019-02-25 6:27 UTC (permalink / raw)
To: kbuild, wenxu; +Cc: kbuild-all, netdev, davem
In-Reply-To: <1550750930-27138-1-git-send-email-wenxu@ucloud.cn>
Hi wenxu,
Thank you for the patch! Perhaps something to improve:
url: https://github.com/0day-ci/linux/commits/wenxu-ucloud-cn/ip_tunnel-Add-ip-tunnel-tunnel_info-dst_cache-in-ip_tunnel_xmit/20190224-065214
smatch warnings:
net/ipv4/ip_tunnel.c:734 ip_tunnel_xmit() error: uninitialized symbol 'rt'.
# https://github.com/0day-ci/linux/commit/fb0c8c40052c62033bf5f92559eabe4e7a98851e
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout fb0c8c40052c62033bf5f92559eabe4e7a98851e
vim +/rt +734 net/ipv4/ip_tunnel.c
7d442fab0 Tom Herbert 2014-01-02 717
b0066da52 Petr Machata 2018-02-27 718 ip_tunnel_init_flow(&fl4, protocol, dst, tnl_params->saddr,
9830ad4c6 Craig Gallek 2017-04-19 719 tunnel->parms.o_key, RT_TOS(tos), tunnel->parms.link,
9830ad4c6 Craig Gallek 2017-04-19 720 tunnel->fwmark);
7d442fab0 Tom Herbert 2014-01-02 721
563284865 Tom Herbert 2014-09-17 722 if (ip_tunnel_encap(skb, tunnel, &protocol, &fl4) < 0)
563284865 Tom Herbert 2014-09-17 723 goto tx_error;
563284865 Tom Herbert 2014-09-17 724
fb0c8c400 wenxu 2019-02-21 725 if (connected && md) {
fb0c8c400 wenxu 2019-02-21 726 use_cache = ip_tunnel_dst_cache_usable(skb, tun_info);
fb0c8c400 wenxu 2019-02-21 727 if (use_cache)
fb0c8c400 wenxu 2019-02-21 728 rt = dst_cache_get_ip4(&tun_info->dst_cache, &fl4.saddr);
What about if "use_cache" is false? "rt" is potentially not set.
fb0c8c400 wenxu 2019-02-21 729 } else {
e09acddf8 Paolo Abeni 2016-02-12 730 rt = connected ? dst_cache_get_ip4(&tunnel->dst_cache, &fl4.saddr) :
e09acddf8 Paolo Abeni 2016-02-12 731 NULL;
fb0c8c400 wenxu 2019-02-21 732 }
7d442fab0 Tom Herbert 2014-01-02 733
7d442fab0 Tom Herbert 2014-01-02 @734 if (!rt) {
^^^
7d442fab0 Tom Herbert 2014-01-02 735 rt = ip_route_output_key(tunnel->net, &fl4);
c54419321 Pravin B Shelar 2013-03-25 736
c54419321 Pravin B Shelar 2013-03-25 737 if (IS_ERR(rt)) {
c54419321 Pravin B Shelar 2013-03-25 738 dev->stats.tx_carrier_errors++;
c54419321 Pravin B Shelar 2013-03-25 739 goto tx_error;
c54419321 Pravin B Shelar 2013-03-25 740 }
fb0c8c400 wenxu 2019-02-21 741 if (use_cache)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: pull request: bluetooth-next 2019-02-24
From: David Miller @ 2019-02-25 6:27 UTC (permalink / raw)
To: johan.hedberg; +Cc: netdev, linux-bluetooth
In-Reply-To: <20190224083634.GA82295@jhedberg-mac01.home>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Sun, 24 Feb 2019 10:36:34 +0200
> Here's the main bluetooth-next pull request for the 5.1 kernel.
>
> - Fixes & improvements to mediatek, hci_qca, btrtl, and btmrvl HCI drivers
> - Fixes to parsing invalid L2CAP config option sizes
> - Locking fix to bt_accept_enqueue()
> - Add support for new Marvel sd8977 chipset
> - Various other smaller fixes & cleanups
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thanks Johan.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: improve auto-neg emulation in swphy
From: David Miller @ 2019-02-25 6:28 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, linux, netdev
In-Reply-To: <a290442f-fdae-26da-6073-3675bf635af1@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 24 Feb 2019 17:41:47 +0100
> Auto-neg emulation currently doesn't set bit BMCR_ANENABLE in BMCR,
> add this. Users will ignore speed and duplex settings in BMCR because
> we're emulating auto-neg, therefore we can remove related code.
> See also following discussion [0].
>
> [0] https://marc.info/?t=155041784900002&r=1&w=2
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied, thanks Heiner.
^ permalink raw reply
* Re: [PATCH net] net: phy: fix reading fixed phy status
From: David Miller @ 2019-02-25 6:29 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <7ab8732d-bcc1-cc49-4bc8-34826e78038b@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 24 Feb 2019 18:01:18 +0100
> With the switch to phy_resolve_aneg_linkmode() we don't read from the
> chip any longer what is advertised but use phydev->advertising directly.
> For a fixed phy however this bitmap is empty so far, what results in
> no common mode being found. This breaks DSA. Fix this by advertising
> everything that is supported. For a normal phy this done by phy_probe().
>
> Fixes: 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied to net-next.
Let me know if I got this wrong.
^ permalink raw reply
* Re: [PATCH net-next] dsa: Remove phydev parameter from disable_port call
From: David Miller @ 2019-02-25 6:30 UTC (permalink / raw)
To: andrew
Cc: netdev, f.fainelli, vivien.didelot, hauke, Woojung.Huh, sean.wang,
linus.walleij
In-Reply-To: <20190224194443.20693-1-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sun, 24 Feb 2019 20:44:43 +0100
> No current DSA driver makes use of the phydev parameter passed to the
> disable_port call. Remove it.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied to net-next, with some fuzz...
^ permalink raw reply
* Re: [PATCH net-next] switchdev: Complete removal of switchdev_port_attr_get()
From: David Miller @ 2019-02-25 6:32 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, idosch, jiri, ivecera, linux-kernel
In-Reply-To: <20190225023902.18894-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sun, 24 Feb 2019 18:39:02 -0800
> We have no more in tree users of switchdev_port_attr_get() after
> d0e698d57a94 ("Merge branch 'net-Get-rid-of-switchdev_port_attr_get'")
> so completely remove the function signature and body.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, thanks.
^ permalink raw reply
* [PATCH mlx5-next] net/mlx5: ODP support for XRC transport is not enabled by default in FW
From: Leon Romanovsky @ 2019-02-25 6:54 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Moni Shoua, RDMA mailing list, Saeed Mahameed, linux-netdev,
Leon Romanovsky
From: Moni Shoua <monis@mellanox.com>
ODP support for XRC transport is not enabled by default in FW,
so we need separate ODP checks to enable/disable it.
While that, rewrite the set of ODP SRQ support capabilities in way
that tests each field separately for clearness, which is not needed
for current FW, but better to have it separated.
Signed-off-by: Moni Shoua <monis@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
.../net/ethernet/mellanox/mlx5/core/main.c | 38 +++++++++++--------
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index af67c3f3b165..58b48474147f 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -465,6 +465,7 @@ static int handle_hca_cap_odp(struct mlx5_core_dev *dev)
void *set_hca_cap;
void *set_ctx;
int set_sz;
+ bool do_set = false;
int err;
if (!IS_ENABLED(CONFIG_INFINIBAND_ON_DEMAND_PAGING) ||
@@ -475,11 +476,6 @@ static int handle_hca_cap_odp(struct mlx5_core_dev *dev)
if (err)
return err;
- if (!(MLX5_CAP_ODP_MAX(dev, ud_odp_caps.srq_receive) ||
- MLX5_CAP_ODP_MAX(dev, rc_odp_caps.srq_receive) ||
- MLX5_CAP_ODP_MAX(dev, xrc_odp_caps.srq_receive)))
- return 0;
-
set_sz = MLX5_ST_SZ_BYTES(set_hca_cap_in);
set_ctx = kzalloc(set_sz, GFP_KERNEL);
if (!set_ctx)
@@ -489,19 +485,29 @@ static int handle_hca_cap_odp(struct mlx5_core_dev *dev)
memcpy(set_hca_cap, dev->caps.hca_cur[MLX5_CAP_ODP],
MLX5_ST_SZ_BYTES(odp_cap));
- /* set ODP SRQ support for RC/UD and XRC transports */
- MLX5_SET(odp_cap, set_hca_cap, ud_odp_caps.srq_receive,
- MLX5_CAP_ODP_MAX(dev, ud_odp_caps.srq_receive));
-
- MLX5_SET(odp_cap, set_hca_cap, rc_odp_caps.srq_receive,
- MLX5_CAP_ODP_MAX(dev, rc_odp_caps.srq_receive));
-
- MLX5_SET(odp_cap, set_hca_cap, xrc_odp_caps.srq_receive,
- MLX5_CAP_ODP_MAX(dev, xrc_odp_caps.srq_receive));
-
- err = set_caps(dev, set_ctx, set_sz, MLX5_SET_HCA_CAP_OP_MOD_ODP);
+#define ODP_CAP_SET_MAX(dev, field) do { \
+ u32 _res = MLX5_CAP_ODP_MAX(dev, field); \
+ if (_res) { \
+ do_set = true; \
+ MLX5_SET(odp_cap, set_hca_cap, field, _res); \
+ } \
+} while (0)
+
+ ODP_CAP_SET_MAX(dev, ud_odp_caps.srq_receive);
+ ODP_CAP_SET_MAX(dev, rc_odp_caps.srq_receive);
+ ODP_CAP_SET_MAX(dev, xrc_odp_caps.srq_receive);
+ ODP_CAP_SET_MAX(dev, xrc_odp_caps.send);
+ ODP_CAP_SET_MAX(dev, xrc_odp_caps.receive);
+ ODP_CAP_SET_MAX(dev, xrc_odp_caps.write);
+ ODP_CAP_SET_MAX(dev, xrc_odp_caps.read);
+ ODP_CAP_SET_MAX(dev, xrc_odp_caps.atomic);
+
+ if (do_set)
+ err = set_caps(dev, set_ctx, set_sz,
+ MLX5_SET_HCA_CAP_OP_MOD_ODP);
kfree(set_ctx);
+
return err;
}
--
2.19.1
^ permalink raw reply related
* RE: [PATCH 0/3] soc: fsl: dpio: enable and configure cache stashing
From: Ioana Ciornei @ 2019-02-25 7:00 UTC (permalink / raw)
To: David Miller
Cc: Leo Li, Roy Pledge, Ioana Ciocoi Radulescu, Laurentiu Tudor,
Horia Geanta, brouer@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190224.220653.256212672271785631.davem@davemloft.net>
> Subject: Re: [PATCH 0/3] soc: fsl: dpio: enable and configure cache stashing
>
> From: Ioana Ciornei <ioana.ciornei@nxp.com>
> Date: Sat, 23 Feb 2019 08:48:42 +0000
>
> > The first two patches enable cache stashing and configure the core
> > cluster destination per software portal while the third patch is the
> > one configuring the amount of stashing on a queue.
>
> Should I merge this series in via my networking tree?
Even though it would be really good to have this on the networking tree as soon as possible, I am afraid that patch 2/3 is not going to apply cleanly because it touches the same areas of code that some other patches on Leo's tree are.
Thanks,
Ioana C
^ permalink raw reply
* [PATCH v2] net: dsa: fix a leaked reference by adding missing of_node_put
From: Wen Yang @ 2019-02-25 7:22 UTC (permalink / raw)
To: andrew
Cc: vivien.didelot, f.fainelli, davem, netdev, linux-kernel,
wang.yi59, Wen Yang
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./net/dsa/port.c:294:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 284, but without a corresponding object release within this function.
./net/dsa/dsa2.c:627:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 618, but without a corresponding object release within this function.
./net/dsa/dsa2.c:630:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 618, but without a corresponding object release within this function.
./net/dsa/dsa2.c:636:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 618, but without a corresponding object release within this function.
./net/dsa/dsa2.c:639:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 618, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
Reviewed-by: "David S. Miller" <davem@davemloft.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Vivien Didelot <vivien.didelot@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Vivien Didelot <vivien.didelot@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
v2->v1: preserve the reverse christmas tree ordering of variables.
net/dsa/dsa2.c | 16 ++++++++++------
net/dsa/port.c | 1 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 8c431e0..c00ee464 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -612,8 +612,8 @@ static int dsa_switch_parse_ports_of(struct dsa_switch *ds,
{
struct device_node *ports, *port;
struct dsa_port *dp;
+ int err = 0;
u32 reg;
- int err;
ports = of_get_child_by_name(dn, "ports");
if (!ports) {
@@ -624,19 +624,23 @@ static int dsa_switch_parse_ports_of(struct dsa_switch *ds,
for_each_available_child_of_node(ports, port) {
err = of_property_read_u32(port, "reg", ®);
if (err)
- return err;
+ goto out_put_node;
- if (reg >= ds->num_ports)
- return -EINVAL;
+ if (reg >= ds->num_ports) {
+ err = -EINVAL;
+ goto out_put_node;
+ }
dp = &ds->ports[reg];
err = dsa_port_parse_of(dp, port);
if (err)
- return err;
+ goto out_put_node;
}
- return 0;
+out_put_node:
+ of_node_put(ports);
+ return err;
}
static int dsa_switch_parse_member_of(struct dsa_switch *ds,
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 2d7e01b..a6d9a04 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -291,6 +291,7 @@ static struct phy_device *dsa_port_get_phy_device(struct dsa_port *dp)
return ERR_PTR(-EPROBE_DEFER);
}
+ of_node_put(phy_dn);
return phydev;
}
--
2.9.5
^ permalink raw reply related
* Re: [PATCH net-next v2 2/2] net: phy: aquantia: add hwmon support
From: Heiner Kallweit @ 2019-02-25 7:34 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <5e9c1d9f-4c9f-10fd-439e-26f7f2cc467e@gmail.com>
On 25.02.2019 03:17, Florian Fainelli wrote:
> Le 2/24/19 à 1:36 PM, Heiner Kallweit a écrit :
>> This adds HWMON support for the temperature sensor and the related
>> alarms on the 107/108/109 chips. This patch is based on work from
>> Nikita and Andrew. I added:
>> - support for changing alarm thresholds via sysfs
>> - move HWMON code to a separate source file to improve maintainability
>> - smaller changes like using IS_REACHABLE instead of ifdef
>> (avoids problems if PHY driver is built in and HWMON is a module)
>>
>> v2:
>> - remove struct aqr_priv
>> - rename header file to aquantia.h
>>
>> Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
>
> Should not Nikita be the author for that patch? Some minor nits below:
>
>> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>> drivers/net/phy/Makefile | 2 +-
>> drivers/net/phy/aquantia.h | 16 ++
>> drivers/net/phy/aquantia_hwmon.c | 245 +++++++++++++++++++++++++++++++
>> drivers/net/phy/aquantia_main.c | 4 +
>> 4 files changed, 266 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/net/phy/aquantia.h
>> create mode 100644 drivers/net/phy/aquantia_hwmon.c
>>
>> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
>> index b0845adaf..c48596626 100644
>> --- a/drivers/net/phy/Makefile
>> +++ b/drivers/net/phy/Makefile
>> @@ -45,7 +45,7 @@ sfp-obj-$(CONFIG_SFP) += sfp-bus.o
>> obj-y += $(sfp-obj-y) $(sfp-obj-m)
>>
>> obj-$(CONFIG_AMD_PHY) += amd.o
>> -aquantia-objs += aquantia_main.o
>> +aquantia-objs += aquantia_main.o aquantia_hwmon.o
>
> Since you are adding a stub if CONFIG_HWMON is not reachable, does not
> that mean you would want to do something like:
>
> ifdef CONFIG_HWMON
> aquanti-objs += aquantia_hwmon.o
> endif
>
> in this makefile?
>
Yepp, this should be changed as suggested by you.
> [snip]
>
>> +static int aqr_hwmon_get(struct phy_device *phydev, int reg, long *value)
>> +{
>> + int temp = phy_read_mmd(phydev, MDIO_MMD_VEND1, reg);
>> +
>> + if (temp < 0)
>> + return temp;
>> +
>> + /* register value is 2's complement with LSB = 1/256th degree Celsius */
>> + if (temp > 0x8000)
>> + temp -= 0x10000;
>
> Would decimal or BIT() notation be easier to use/read here?
>
For the comparison I agree, we can write it as: if (temp & BIT(15))
And yes, the offset we could write decimal.
An alternative could be to write: temp = (s16)temp;
I tested it and it works, but I'm not sure whether this is covered
by C standard and works with all supported compilers.
>> +
>> + *value = temp * 1000 / 256;
>> +
>> + return 0;
>> +}
>> +
>> +static int aqr_hwmon_set(struct phy_device *phydev, int reg, long value)
>> +{
>> + int temp;
>> +
>> + if (value >= 128000 || value < -128000)
>> + return -ERANGE;
>> +
>> + temp = value * 256 / 1000;
>> +
>> + if (temp < 0)
>> + temp += 0x10000;
>
> Likewise
>
>> +
>> + return phy_write_mmd(phydev, MDIO_MMD_VEND1, reg, temp);
>> +}
>> +
>> +static int aqr_hwmon_status1(struct phy_device *phydev, int bit, long *value)
>> +{
>> + int reg = phy_read_mmd(phydev, MDIO_MMD_VEND1, VEND1_GENERAL_STAT1);
>> +
>> + if (reg < 0)
>> + return reg;
>> +
>> + *value = !!(reg & bit);
>> +
>> + return 0;
>> +}
>
> Can you also make this function take a register offset as parameter such
> that you can eliminate open coding that in the case hwmon_temp_input below?
>
OK
>> +
>> +static int aqr_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
>> + u32 attr, int channel, long *value)
>> +{
>> + struct phy_device *phydev = dev_get_drvdata(dev);
>> + int reg;
>> +
>> + if (type != hwmon_temp)
>> + return -EOPNOTSUPP;
>> +
>> + switch (attr) {
>> + case hwmon_temp_input:
>> + reg = phy_read_mmd(phydev, MDIO_MMD_VEND1,
>> + VEND1_THERMAL_STAT2);
>> + if (reg < 0)
>> + return reg;
>> + if (!(reg & VEND1_THERMAL_STAT2_VALID))
>> + return -EIO;
>
> And use that helper here.
>
>> +
>> + return aqr_hwmon_get(phydev, VEND1_THERMAL_STAT1, value);
>> +
>
> [snip]
>
>> + hwmon_name = devm_kstrdup(dev, dev_name(dev), GFP_KERNEL);
>> + if (!hwmon_name)
>> + return -ENOMEM;
>> +
>> + for (i = j = 0; hwmon_name[i]; i++) {
>> + if (isalnum(hwmon_name[i])) {
>> + if (i != j)
>> + hwmon_name[j] = hwmon_name[i];
>> + j++;
>> + }
>> + }
>> + hwmon_name[j] = '\0';
>
> I am always baffled that drivers need to take care of these details...
> but that seems to be the way to go.
>
IIRC we still have a similar construction site in phylib.
If a PHY driver name includes e.g. a slash then sysfs is broken.
There should be a general helper e.g. in lib/string.c, because we have
this across subsystems wherever a device name is used in a sysfs path.
^ permalink raw reply
* [PATCH net] ipv4: Add ICMPv6 support when parse route ipproto
From: Hangbin Liu @ 2019-02-25 7:47 UTC (permalink / raw)
To: netdev; +Cc: Roopa Prabhu, David S . Miller, Hangbin Liu
For ip rules, we need to use 'ipproto ipv6-icmp' to match ICMPv6 headers.
But for ip -6 route, currently we only support tcp, udp and icmp.
Add ICMPv6 support so we can match ipv6-icmp rules for route lookup.
Reported-by: Jianlin Shi <jishi@redhat.com>
Fixes: eacb9384a3fe ("ipv6: support sport, dport and ip_proto in RTM_GETROUTE")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/ipv4/netlink.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/netlink.c b/net/ipv4/netlink.c
index f86bb4f06609..95601237521f 100644
--- a/net/ipv4/netlink.c
+++ b/net/ipv4/netlink.c
@@ -3,6 +3,7 @@
#include <linux/types.h>
#include <net/net_namespace.h>
#include <net/netlink.h>
+#include <linux/in6.h>
#include <net/ip.h>
int rtm_getroute_parse_ip_proto(struct nlattr *attr, u8 *ip_proto,
@@ -14,6 +15,7 @@ int rtm_getroute_parse_ip_proto(struct nlattr *attr, u8 *ip_proto,
case IPPROTO_TCP:
case IPPROTO_UDP:
case IPPROTO_ICMP:
+ case IPPROTO_ICMPV6:
return 0;
default:
NL_SET_ERR_MSG(extack, "Unsupported ip proto");
--
2.19.2
^ permalink raw reply related
* linux-next: Fixes tag needs some work in the net-next tree
From: Stephen Rothwell @ 2019-02-25 8:00 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Jian Shen,
Peng Li, Huazhong Tan
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
Hi all,
In commit
a638b1d8cc87 ("net: hns3: fix get VF RSS issue")
Fixes tag
Fixes: 374ad291762a ("net: hns3: net: hns3: Add RSS general configuration support for VF")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h (%s)'
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net] sit: use ipv6_mod_enabled to check if ipv6 is disabled
From: Hangbin Liu @ 2019-02-25 8:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Stefano Brivio, David S . Miller, David Ahern
In-Reply-To: <7c0f5c9c-d918-de27-643d-416509576be4@gmail.com>
On Sun, Feb 24, 2019 at 08:24:51PM -0800, Eric Dumazet wrote:
>
>
> On 02/24/2019 08:12 PM, Hangbin Liu wrote:
> > ipv6_mod_enabled() is more safe and gentle to check if ipv6 is disabled
> > at running time.
> >
>
>
> Why is it better exactly ?
>
> IPv6 can be enabled on the host, but disabled per device
>
> /proc/sys/net/ipv6/conf/{name}/disable_ipv6
Sorry, it looks I didn't make it clear in the commit description.
This issue only occurs when IPv6 is disabled at boot time as there is
no IPv6 route entry. Disable ipv6 on specific interface is not affected.
So check ipv6_mod_enabled() is enough and we don't need to worry about
the rcu_read_lock or the dev status.
Should I update the commit description?
Thanks
Hangbin
>
>
> > Fixes: 173656accaf5 ("sit: check if IPv6 enabled before calling ip6_err_gen_icmpv6_unreach()")
> > Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> > ---
> > net/ipv6/sit.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
> > index e8a1dabef803..eea1f19985a7 100644
> > --- a/net/ipv6/sit.c
> > +++ b/net/ipv6/sit.c
> > @@ -546,7 +546,7 @@ static int ipip6_err(struct sk_buff *skb, u32 info)
> > }
> >
> > err = 0;
> > - if (__in6_dev_get(skb->dev) &&
> > + if (ipv6_mod_enabled() &&
> > !ip6_err_gen_icmpv6_unreach(skb, iph->ihl * 4, type, data_len))
> > goto out;
> >
> >
^ permalink raw reply
* RE: [PATCH 2/3] net: ethernet: add c45 PHY support in MDIO read/write functions.
From: Parshuram Raju Thombare @ 2019-02-25 8:18 UTC (permalink / raw)
To: Andrew Lunn
Cc: nicolas.ferre@microchip.com, davem@davemloft.net,
netdev@vger.kernel.org, f.fainelli@gmail.com,
hkallweit1@gmail.com, linux-kernel@vger.kernel.org,
Rafal Ciepiela, Piotr Sroka, Jan Kotas
In-Reply-To: <20190223152304.GD10693@lunn.ch>
>> >On Fri, Feb 22, 2019 at 08:12:42PM +0000, Parshuram Thombare wrote:
>> >> This patch modify MDIO read/write functions to support
>> >> communication with C45 PHY in Cadence ethernet controller driver.
>> >
>> >Hi Parshuram
>> >
>> >Are all versions of the MDIO controller capable of doing C45?
>> >
>> > Andrew
>> Now driver support c22 and c45 PHY.
>> Are you suggesting to add check for C45 PHY using is_c45 in phydev ?
>
>You are unconditionally supporting C45. Are there versions of the hardware which
>don't actually support C45? You have this endless loop:
There is controller which don't support C45. I will add check for that using is_c45.
>
>+ /* wait for end of transfer */
>+ while (!MACB_BFEXT(IDLE, macb_readl(bp, NSR)))
>+ cpu_relax();
>
>If there is hardware which does not support C45, will this loop forever?
>
> Andrew
Yes, this bit is supposed to be set. I will add timeout here.
Regards,
Parshuram Thombare
^ permalink raw reply
* RE: [PATCH 2/3] net: ethernet: add c45 PHY support in MDIO read/write functions.
From: Parshuram Raju Thombare @ 2019-02-25 8:19 UTC (permalink / raw)
To: Andrew Lunn
Cc: nicolas.ferre@microchip.com, davem@davemloft.net,
netdev@vger.kernel.org, f.fainelli@gmail.com,
hkallweit1@gmail.com, linux-kernel@vger.kernel.org,
Rafal Ciepiela, Piotr Sroka, Jan Kotas
In-Reply-To: <20190223152540.GE10693@lunn.ch>
>On Fri, Feb 22, 2019 at 08:12:42PM +0000, Parshuram Thombare wrote:
>> This patch modify MDIO read/write functions to support communication
>> with C45 PHY in Cadence ethernet controller driver.
>>
>> Signed-off-by: Parshuram Thombare <pthombar@cadence.com>
>> ---
>> drivers/net/ethernet/cadence/macb.h | 15 +++++--
>> drivers/net/ethernet/cadence/macb_main.c | 61
>++++++++++++++++++++++++-----
>> 2 files changed, 61 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/cadence/macb.h
>> b/drivers/net/ethernet/cadence/macb.h
>> index bed4ded..59c23e0 100644
>> --- a/drivers/net/ethernet/cadence/macb.h
>> +++ b/drivers/net/ethernet/cadence/macb.h
>> @@ -636,10 +636,17 @@
>> #define GEM_CLK_DIV96 5
>>
>> /* Constants for MAN register */
>> -#define MACB_MAN_SOF 1
>> -#define MACB_MAN_WRITE 1
>> -#define MACB_MAN_READ 2
>> -#define MACB_MAN_CODE 2
>> +#define MACB_MAN_C22_SOF 1
>> +#define MACB_MAN_C22_WRITE 1
>> +#define MACB_MAN_C22_READ 2
>> +#define MACB_MAN_C22_CODE 2
>> +
>> +#define MACB_MAN_C45_SOF 0
>> +#define MACB_MAN_C45_ADDR 0
>> +#define MACB_MAN_C45_WRITE 1
>> +#define MACB_MAN_C45_POST_READ_INCR 2
>> +#define MACB_MAN_C45_READ 3
>> +#define MACB_MAN_C45_CODE 2
>>
>> /* Capability mask bits */
>> #define MACB_CAPS_ISR_CLEAR_ON_WRITE 0x00000001
>> diff --git a/drivers/net/ethernet/cadence/macb_main.c
>> b/drivers/net/ethernet/cadence/macb_main.c
>> index 4f4f8e5..2494abf 100644
>> --- a/drivers/net/ethernet/cadence/macb_main.c
>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>> @@ -323,11 +323,30 @@ static int macb_mdio_read(struct mii_bus *bus, int
>mii_id, int regnum)
>> struct macb *bp = bus->priv;
>> int value;
>>
>> - macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_SOF)
>> - | MACB_BF(RW, MACB_MAN_READ)
>> - | MACB_BF(PHYA, mii_id)
>> - | MACB_BF(REGA, regnum)
>> - | MACB_BF(CODE, MACB_MAN_CODE)));
>> + if (regnum & MII_ADDR_C45) {
>> + macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C45_SOF)
>> + | MACB_BF(RW, MACB_MAN_C45_ADDR)
>> + | MACB_BF(PHYA, mii_id)
>> + | MACB_BF(REGA, (regnum >> 16) & 0x1F)
>> + | MACB_BF(DATA, regnum & 0xFFFF)
>> + | MACB_BF(CODE, MACB_MAN_C45_CODE)));
>> +
>> + /* wait for end of transfer */
>> + while (!MACB_BFEXT(IDLE, macb_readl(bp, NSR)))
>> + cpu_relax();
>
>You need a timeout here, and anywhere you wait for the hardware to complete.
>Try to make use of readx_poll_timeout() variants.
>
> Andrew
Yes, I will add timeout here.
Regards,
Parshuram Thombare
^ permalink raw reply
* RE: [PATCH 0/3] Cover letter: Add support for high speed MAC in Cadence controller driver
From: Parshuram Raju Thombare @ 2019-02-25 8:22 UTC (permalink / raw)
To: Florian Fainelli, nicolas.ferre@microchip.com,
davem@davemloft.net, netdev@vger.kernel.org, andrew@lunn.ch,
hkallweit1@gmail.com, linux-kernel@vger.kernel.org,
Rafal Ciepiela, Piotr Sroka, Jan Kotas
In-Reply-To: <a64e8266-a235-9999-708d-1a80051b5d4e@gmail.com>
>Hi,
>
>Le 2/22/19 à 12:11 PM, Parshuram Thombare a écrit :
>> Hello !
>>
>> This patch series contain changes to support high speed MAC and PCS in
>> Cadence ethernet controller driver.
>
>From patch submission perspective, your cover letter and individual patches do
>not appear as a reply to this cover letter which makes the threading broken in
>most mail clients. If you used git format-patch --cover-letter, this is handled
>transparently for you by git send-email.
>
Hi Florian,
I will make sure to do it correctly from next patch set.
>>
>> Here is the list of patches.
>> [PATCH 1/3] net: ethernet: add support for PCS and 2.5G speed
>> This patch add support for PCS (for SGMII interface) and 2.5Gbps
>> MAC in Cadence ethernet controller driver.
>> [PATCH 2/3] net: ethernet: add c45 PHY support in MDIO read/write functions.
>> This patch modify MDIO read/write functions to support
>> communication with C45 PHY in Cadence ethernet controller driver.
>> [PATCH 3/3] net: ethernet: add support for high speed mac and usxgmii pcs
>> This patch add support for (10G) high speed mac, usxgmii pcs
>> and usxgmii interface in Cadence ethernet controller driver.
>>
>> Regards,
>> Parshuram Thombare
>>
>> Parshuram Thombare (3):
>> net: ethernet: add support for PCS and 2.5G speed
>> net: ethernet: add c45 PHY support in MDIO read/write functions.
>> net: ethernet: add support for high speed mac and usxgmii pcs
>>
>> drivers/net/ethernet/cadence/macb.h | 68 ++++++-
>> drivers/net/ethernet/cadence/macb_main.c | 309
>+++++++++++++++++++++++++----
>> include/linux/phy.h | 3 +
>> 3 files changed, 333 insertions(+), 47 deletions(-)
>>
>
>
>--
>Florian
Regards,
Parshuram Thombare
^ permalink raw reply
* Re: INFO: task hung in rtnetlink_rcv_msg
From: Jesper Dangaard Brouer @ 2019-02-25 8:39 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jakub Kicinski, Joe Perches, syzbot, ast, christian, davem,
dsahern, hawk, idosch, john.fastabend, kafai, ktkhai,
linux-kernel, netdev, petrm, roopa, songliubraving,
syzkaller-bugs, xdp-newbies, yhs, brouer
In-Reply-To: <279c5bae-0b18-b03a-2858-4749e18afa26@iogearbox.net>
On Sat, 23 Feb 2019 01:47:00 +0100
Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 02/22/2019 10:45 PM, Jakub Kicinski wrote:
> > On Fri, 22 Feb 2019 12:14:57 -0800, Joe Perches wrote:
> >> On Fri, 2019-02-22 at 12:01 -0800, Jakub Kicinski wrote:
> >>> Hi!
> >>>
> >>> Seems like something funny is going on with get_maintainer.pl since XDP
> >>> entry got added. We seem to have been CCed on:
> >>
> >> I suggest removing the MAINTAINERS line with
> >>
> >> K: xdp
> >>
> >> as xdp is a pretty generic file/patch content
> >> regex match for the K: type
> >>
> >> $ git grep --name-only xdp | wc -l
> >> 236
I'm unsure how K: works, but you grep definitely selects some wrong files.
I tried with "xdp_":
git grep --name-only xdp_
That does catch all the driver that have XDP support, which is the
point of the exercise (to catch drivers).
It does contain a couple of false-positives:
drivers/net/ethernet/neterion/vxge/vxge-traffic.c
drivers/thunderbolt/tb_msgs.h
drivers/thunderbolt/xdomain.c
sound/soc/codecs/rt5670.c
Via the pattern '[^a-z]xdp_' I'm only left with the thunderbolt
false-positive, as it have a data struct's called tb_xdp_*.
> >> Rather more files than desired.
> >>
> >> The N: match is dubious too.
> >>
> >> It's generally better to have specific lists of
> >> maintained file patterns rather than using the
> >> K: and N: pattern matches.
> >>
> >> ---
> >> MAINTAINERS | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index d7ad97b235ec..aa703e2cb882 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -16970,7 +16970,6 @@ F: include/net/xdp.h
> >> F: kernel/bpf/devmap.c
> >> F: kernel/bpf/cpumap.c
> >> F: include/trace/events/xdp.h
> >> -K: xdp
> >> N: xdp
> >>
> >> XDP SOCKETS (AF_XDP)
> >
> > Thanks for the explanation, at least now I know why it happens! :)
> > I'll leave it to Daniel to decide if we really need it removed,
> > so far the false positives weren't overwhelming, just surprising.
>
> No strong opinion. I've seen this K+N pattern in a number of places
> in the maintainers file. I'm fine either way if it gets too noisy. :)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net v2] af_packet: fix raw sockets over 6in4 tunnel
From: Nicolas Dichtel @ 2019-02-25 8:55 UTC (permalink / raw)
To: Willem de Bruijn, David Miller
Cc: Sasha Levin, Network Development, Willem de Bruijn,
Maxim Mikityanskiy
In-Reply-To: <CAF=yD-LDWfdOZoGzZmTUSNVeKVzcWf9KGbiW4yHV0S0gR_bPzA@mail.gmail.com>
Le 23/02/2019 à 00:53, Willem de Bruijn a écrit :
> On Fri, Feb 22, 2019 at 2:50 PM David Miller <davem@davemloft.net> wrote:
>>
>> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
>> Date: Wed, 20 Feb 2019 13:39:23 -0500
>>
>>> On Mon, Feb 18, 2019 at 1:50 PM Sasha Levin <sashal@kernel.org> wrote:
>>>> Should this go to -stable as well? The patch it fixes is in 4.20.
>>>
>>> I believe so. It was also backported to 4.19 stable.
>>
>> It's queued up now.
>
> Thanks David!
>
Thanks all and sorry for the late reply, I was off last week.
Regards,
Nicolas
^ permalink raw reply
* RE: [PATCH 1/3] net: ethernet: add support for PCS and 2.5G speed
From: Parshuram Raju Thombare @ 2019-02-25 9:11 UTC (permalink / raw)
To: Florian Fainelli, nicolas.ferre@microchip.com,
davem@davemloft.net, netdev@vger.kernel.org, andrew@lunn.ch,
hkallweit1@gmail.com, linux-kernel@vger.kernel.org,
Rafal Ciepiela, Piotr Sroka, Jan Kotas
In-Reply-To: <673edcd1-9ea5-9efe-1f66-3f8ea8d3f092@gmail.com>
>Le 2/22/19 à 12:12 PM, Parshuram Thombare a écrit :
>> This patch add support for PCS (for SGMII interface) and 2.5Gbps MAC
>> in Cadence ethernet controller driver.
>
>At a high level you don't seem to be making use of PHYLINK so which 2.5Gbps
>interfaces do you actually support?
>
New ethernet controller have MAC which support 2.5G speed.
Also there is addition of PCS and SGMII interface.
>>
>> Signed-off-by: Parshuram Thombare <pthombar@cadence.com>
>> ---
>
>[snip]
>
>> @@ -361,26 +361,50 @@ static int macb_mdio_write(struct mii_bus *bus, int
>mii_id, int regnum,
>> * macb_set_tx_clk() - Set a clock to a new frequency
>> * @clk Pointer to the clock to change
>> * @rate New frequency in Hz
>> + * @interafce Phy interface
>
>Typo: @interface and this is an unrelated change.
>
>> * @dev Pointer to the struct net_device
>> */
>> -static void macb_set_tx_clk(struct clk *clk, int speed, struct
>> net_device *dev)
>> +static void macb_set_tx_clk(struct clk *clk, int speed,
>> + phy_interface_t interface, struct net_device *dev)
>> {
>> long ferr, rate, rate_rounded;
>>
>> if (!clk)
>> return;
>>
>> - switch (speed) {
>> - case SPEED_10:
>> + if (interface == PHY_INTERFACE_MODE_GMII ||
>> + interface == PHY_INTERFACE_MODE_MII) {
>> + switch (speed) {
>> + case SPEED_10:> rate = 2500000;
>
>You need to add one tab to align rate and break.
Do you mean a tab each for rate and break lines ?
All switch statements are aligned at a tab. I am not sure how does case and rate got on same line.
>
>> break;
>> - case SPEED_100:
>> + case SPEED_100:
>> rate = 25000000;
>> break;
>> - case SPEED_1000:
>> + case SPEED_1000:
>> rate = 125000000;
>> break;
>> - default:
>> + default:
>> + return;
>> + }
>> + } else if (interface == PHY_INTERFACE_MODE_SGMII) {
>> + switch (speed) {
>> + case SPEED_10:
>> + rate = 1250000;
>> + break;
>> + case SPEED_100:
>> + rate = 12500000;
>> + break;
>> + case SPEED_1000:
>> + rate = 125000000;
>> + break;
>> + case SPEED_2500:
>> + rate = 312500000;
>> + break;
>> + default:
>> + return;
>
>The indentation is broken here and you can greatly simplify this with a simple
>function that returns speed * 1250 and does an initial check for unsupported
>speeds.
>
I ran checkpatch.pl and all indentation issues were cleared. But I think having function
is better option, I will make that change.
>> + }
>> + } else {
>> return;
>> }
>>
>> @@ -410,30 +434,49 @@ static void macb_handle_link_change(struct
>> net_device *dev)
>>
>> spin_lock_irqsave(&bp->lock, flags);
>>
>> - if (phydev->link) {
>> - if ((bp->speed != phydev->speed) ||
>> - (bp->duplex != phydev->duplex)) {
>> - u32 reg;
>> -
>> - reg = macb_readl(bp, NCFGR);
>> - reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
>> - if (macb_is_gem(bp))
>> - reg &= ~GEM_BIT(GBE);
>> + if (phydev->link && (bp->speed != phydev->speed ||
>> + bp->duplex != phydev->duplex)) {
>> + u32 reg;
>>
>> - if (phydev->duplex)
>> - reg |= MACB_BIT(FD);
>> + reg = macb_readl(bp, NCFGR);
>> + reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
>> + if (macb_is_gem(bp))
>> + reg &= ~GEM_BIT(GBE);
>> + if (phydev->duplex)
>> + reg |= MACB_BIT(FD);
>> + macb_or_gem_writel(bp, NCFGR, reg);
>> +
>> + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII &&
>> + (phydev->speed == SPEED_1000 ||
>> + phydev->speed == SPEED_2500)) {
>> + if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED) {
>> + reg = gem_readl(bp, NCR) &
>> + ~GEM_BIT(TWO_PT_FIVE_GIG);
>> + gem_writel(bp, NCR, reg);
>> + }
>
>If you are making correct use of the capabilities then there is no point in re-
>checking them here. If you allowed the MAC to advertise 2.5Gbps then it is de-
>facto SGMII capable.
PHY_INTERFACE_MODE_SGMII is selected only on the basis of presence of PCS.
This additional check is to make sure PHY also support 1G/2.5G.
>> + gem_writel(bp, NCFGR, GEM_BIT(GBE) |
>> + gem_readl(bp, NCFGR));
>> + if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED
>&&
>> + phydev->speed == SPEED_2500)
>> + gem_writel(bp, NCR, gem_readl(bp, NCR) |
>> + GEM_BIT(TWO_PT_FIVE_GIG));
>> + } else if (phydev->speed == SPEED_1000) {
>> + gem_writel(bp, NCFGR, GEM_BIT(GBE) |
>> + gem_readl(bp, NCFGR));
>> + } else {
>> + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII)
>{
>> + reg = gem_readl(bp, NCFGR);
>> + reg &= ~(GEM_BIT(SGMIIEN) |
>GEM_BIT(PCSSEL));
>> + gem_writel(bp, NCFGR, reg);
>> + }
>> if (phydev->speed == SPEED_100)
>> - reg |= MACB_BIT(SPD);
>> - if (phydev->speed == SPEED_1000 &&
>> - bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
>> - reg |= GEM_BIT(GBE);
>> -
>> - macb_or_gem_writel(bp, NCFGR, reg);
>> -
>> - bp->speed = phydev->speed;
>> - bp->duplex = phydev->duplex;
>> - status_change = 1;
>> + macb_writel(bp, NCFGR, MACB_BIT(SPD) |
>> + macb_readl(bp, NCFGR));
>> }
>
>There is a lot of repetition while setting the GBE bit which always set based on
>speed == 1000 irrespective of the mode, so take that part out of the if () else if ()
>else () clauses.
>
Ok, I will change it.
>> +
>> + bp->speed = phydev->speed;
>> + bp->duplex = phydev->duplex;
>> + status_change = 1;
>> }
>>
>> if (phydev->link != bp->link) {
>> @@ -453,7 +496,8 @@ static void macb_handle_link_change(struct net_device
>*dev)
>> /* Update the TX clock rate if and only if the link is
>> * up and there has been a link change.
>> */
>> - macb_set_tx_clk(bp->tx_clk, phydev->speed, dev);
>> + macb_set_tx_clk(bp->tx_clk, phydev->speed,
>> + bp->phy_interface, dev);
>>
>> netif_carrier_on(dev);
>> netdev_info(dev, "link up (%d/%s)\n", @@ -543,10
>+587,16 @@ static
>> int macb_mii_probe(struct net_device *dev)
>> }
>>
>> /* mask with MAC supported features */
>> - if (macb_is_gem(bp) && bp->caps &
>MACB_CAPS_GIGABIT_MODE_AVAILABLE)
>> - phy_set_max_speed(phydev, SPEED_1000);
>> - else
>> - phy_set_max_speed(phydev, SPEED_100);
>> + if (macb_is_gem(bp)) {
>
>You have changed the previous logic that also checked for
>MACB_CAPS_GIGABIT_MODE_AVAILABLE, why?
My understanding is all GEM (ID >= 0x2) support GIGABIT mode.
Was there any other reason for this check ?
>> + linkmode_copy(phydev->supported, PHY_GBIT_FEATURES);
>> + if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED)
>> +
> linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
>> + phydev->supported);
>> + } else {
>> + linkmode_copy(phydev->supported, PHY_BASIC_FEATURES);
>> + }
>> +
>> + linkmode_copy(phydev->advertising, phydev->supported);
>>
>> if (bp->caps & MACB_CAPS_NO_GIGABIT_HALF)
>> phy_remove_link_mode(phydev,
>> @@ -2217,8 +2267,6 @@ static void macb_init_hw(struct macb *bp)
>> macb_set_hwaddr(bp);
>>
>> config = macb_mdc_clk_div(bp);
>> - if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII)
>> - config |= GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL);
>> config |= MACB_BF(RBOF, NET_IP_ALIGN); /* Make eth data
>aligned */
>> config |= MACB_BIT(PAE); /* PAuse Enable */
>> config |= MACB_BIT(DRFCS); /* Discard Rx FCS */
>> @@ -3255,6 +3303,23 @@ static void macb_configure_caps(struct macb *bp,
>> dcfg = gem_readl(bp, DCFG1);
>> if (GEM_BFEXT(IRQCOR, dcfg) == 0)
>> bp->caps |= MACB_CAPS_ISR_CLEAR_ON_WRITE;
>> + if (GEM_BFEXT(NO_PCS, dcfg) == 0)
>> + bp->caps |= MACB_CAPS_PCS;
>> + switch (MACB_BFEXT(IDNUM, macb_readl(bp, MID))) {
>> + case MACB_GEM7016_IDNUM:
>> + case MACB_GEM7017_IDNUM:
>> + case MACB_GEM7017A_IDNUM:
>> + case MACB_GEM7020_IDNUM:
>> + case MACB_GEM7021_IDNUM:
>> + case MACB_GEM7021A_IDNUM:
>> + case MACB_GEM7022_IDNUM:
>> + if (bp->caps & MACB_CAPS_PCS)
>> + bp->caps |= MACB_CAPS_TWO_PT_FIVE_GIG_SPEED;
>> + break;
>> +
>> + default:
>> + break;
>> + }
>> dcfg = gem_readl(bp, DCFG2);
>> if ((dcfg & (GEM_BIT(RX_PKT_BUFF) | GEM_BIT(TX_PKT_BUFF)))
>== 0)
>> bp->caps |= MACB_CAPS_FIFO_MODE;
>> @@ -4110,7 +4175,28 @@ static int macb_probe(struct platform_device
>*pdev)
>> else
>> bp->phy_interface = PHY_INTERFACE_MODE_MII;
>> } else {
>> + switch (err) {
>> + case PHY_INTERFACE_MODE_SGMII:
>> + if (bp->caps & MACB_CAPS_PCS) {
>> + bp->phy_interface = PHY_INTERFACE_MODE_SGMII;
>> + break;
>> + }
>
>If SGMII was selected on a version of the IP that does not support it, then falling
>back to GMII or MII does not sound correct, this is a hard error that must be
>handled as such.
>--
>Florian
My intention was to continue (instead of failing) with whatever functionality is available.
Can we have some error message and continue with what is available ?
Regards,
Parshuram Thombare
^ permalink raw reply
* [PATCH] net: phy: dp83867: add soft reset delay
From: Max Uvarov @ 2019-02-25 9:15 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli, andrew, Max Uvarov
Similar to dp83640 delay after soft reset
is needed to set up registers correctly.
Signed-off-by: Max Uvarov <muvarov@gmail.com>
---
drivers/net/phy/dp83867.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index ac8ba642d616..e1ec36c51511 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -19,6 +19,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/phy.h>
+#include <linux/delay.h>
#include <dt-bindings/net/ti-dp83867.h>
@@ -347,6 +348,8 @@ static int dp83867_phy_reset(struct phy_device *phydev)
if (err < 0)
return err;
+ usleep_range(10, 20);
+
return dp83867_config_init(phydev);
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] tcp: detect use sendpage for slab-based objects
From: Vasily Averin @ 2019-02-25 9:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <CANn89iL-Pm2mC8kSapvDJd8TKB5hwEuBaRJ-PK9oJJb5w4eycA@mail.gmail.com>
On 2/22/19 7:39 PM, Eric Dumazet wrote:
> On Fri, Feb 22, 2019 at 6:02 AM Vasily Averin <vvs@virtuozzo.com> wrote:
>> Eric, could you please elaborate once again why tcp_sendpage() should not handle slab objects?
>
> Simply because SLAB has its own way to manage objects from a page, and
> does not care
> about the underlying page having its refcount elevated.
>
> ptr = kmalloc(xx)
> ... < here you can attempt cheating and add one to the underlying page>
> kfree(ptr); // SLAB does not care of page count, it will effectively
> put ptr in the free list.
>
> ptr2 = kmalloc(xx); //
>
> ptr2 can be the same than ptr (object was kfreed() earlier)
>
> This means that some other stuff will happily reuse the piece of
> memory that you wanted to use for zero-copy.
>
> This is a serious bug IMO, since this would allow for data corruption.
Thank you for explanation, however I still have some doubts.
Yes, it's strange to use sendpage if we want to send some small 8-bytes-long slab based object,
it's better to use sendmsg instead.
Yes, using of sendpage for slab-based objects can require special attention
to guarantee that slab object will not be freed until end of IO.
However IMO this should be guaranteed if caller uses sendmsg instead of sendpage.
Btw, as far as I understand in my example XFS did it correctly, submitted slab objects was kept in use
and seems they should be freed after end of IO, via end_io callback.
At least I did not found any bugs in sendpage callers.
And most important, it seems for me switch from sendpage to sendmsg doe not resolve the problem completely:
tcp_sendmsg_locked() under some conditions can merge neighbours slab-based tcp fragments,
so local tcp_recvmsg() can trigger BUG_ON in this case too.
Am I missed something probably?
>> There is known restriction: sendpage should not be called for pages with counter=0,
>> because internal put_page() releases the page. All sendpage callers I know have such check.
>>
>> However why they should add one check for PageSlab?
>>
>> Let me explain the problem once again:
>> I do not see any bugs neither in tcp nor in any sendpage callers,
>> there is false alert on receiving side that crashes correctly worked host.
>
> This is not a false alert, but a very fundamental issue.
>
> We can not mix kmalloc() and page fragments, this simply is buggy.
^ permalink raw reply
* Re: 32-bit Amlogic SoCs: avoid using Ethernet MAC addresses
From: Piero @ 2019-02-25 9:25 UTC (permalink / raw)
To: Martin Blumenstingl; +Cc: linux.amoon, linux-amlogic, netdev
In-Reply-To: <CAFBinCDRKJS-RXgVBDo2gjp_bU8Wmbhr+HGXNad4vCFyrvN_HA@mail.gmail.com>
Hi,
in my experience using armbian (so a different distribution) on
odroidc1 I see the mac is changing every time I do a new install but
it is kept constant between reboots: so it looks like something that
can be handled somewhere above the hardware-kernel layer.
*Ciao
Piero
Il giorno dom 24 feb 2019 alle ore 21:55 Martin Blumenstingl
<martin.blumenstingl@googlemail.com> ha scritto:
>
> I have seen Anand's your question in [0]:
> > only issue is I have is the each time their is random MAC address so I
> > get new IP from dhcp server.
> > How can I avoid this. I have tried to enable eFuse driver but with no success.
>
> u-boot on the 64-bit SoCs can read the MAC address from the eFuse and
> pass it (via the .dtb) to the kernel.
> This requires an ethernet0 alias in the mainline .dts though, see [1]
> for and example.
>
> I'm not sure if this also works with the older u-boot on the 32-bit SoCs.
> if it doesn't then there's a nvmem-cells binding for all Ethernet
> controllers: [2] (please note that the function implementing this
> binding was recently renamed: [3])
> as far as I can tell the stmmac driver doesn't support the nvmem-cells
> based binding yet
>
> Anand, if you want to work on this: feel free to do so!
> I have the SDHC MMC driver and a discussion about the power-domain
> drivers on my TODO-list, so I'm pretty busy at the moment.
>
>
> Regards
> Martin
>
>
> [0] http://lists.infradead.org/pipermail/linux-amlogic/2019-February/010464.html
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7c36209c46c4d162202b65eed2e66962ad8c3c1
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9217e566bdee4583d0a9ea4879c8f5e004886eac
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=afa64a72b862a7a9d04f8d07fba632eaf06b23f8
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
--
Stupid is as stupid does.
Forrest Gump
^ permalink raw reply
* [PATCH] xfrm: correctly check policy index in verify_newpolicy_info
From: Yue Haibing @ 2019-02-25 9:27 UTC (permalink / raw)
To: steffen.klassert, herbert, davem; +Cc: linux-kernel, netdev, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
UBSAN report this:
UBSAN: Undefined behaviour in net/xfrm/xfrm_policy.c:1289:24
index 6 is out of range for type 'unsigned int [6]'
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.162-514.55.6.9.x86_64+ #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
0000000000000000 1466cf39b41b23c9 ffff8801f6b07a58 ffffffff81cb35f4
0000000041b58ab3 ffffffff83230f9c ffffffff81cb34e0 ffff8801f6b07a80
ffff8801f6b07a20 1466cf39b41b23c9 ffffffff851706e0 ffff8801f6b07ae8
Call Trace:
<IRQ> [<ffffffff81cb35f4>] __dump_stack lib/dump_stack.c:15 [inline]
<IRQ> [<ffffffff81cb35f4>] dump_stack+0x114/0x1a0 lib/dump_stack.c:51
[<ffffffff81d94225>] ubsan_epilogue+0x12/0x8f lib/ubsan.c:164
[<ffffffff81d954db>] __ubsan_handle_out_of_bounds+0x16e/0x1b2 lib/ubsan.c:382
[<ffffffff82a25acd>] __xfrm_policy_unlink+0x3dd/0x5b0 net/xfrm/xfrm_policy.c:1289
[<ffffffff82a2e572>] xfrm_policy_delete+0x52/0xb0 net/xfrm/xfrm_policy.c:1309
[<ffffffff82a3319b>] xfrm_policy_timer+0x30b/0x590 net/xfrm/xfrm_policy.c:243
[<ffffffff813d3927>] call_timer_fn+0x237/0x990 kernel/time/timer.c:1144
[<ffffffff813d8e7e>] __run_timers kernel/time/timer.c:1218 [inline]
[<ffffffff813d8e7e>] run_timer_softirq+0x6ce/0xb80 kernel/time/timer.c:1401
[<ffffffff8120d6f9>] __do_softirq+0x299/0xe10 kernel/softirq.c:273
[<ffffffff8120e676>] invoke_softirq kernel/softirq.c:350 [inline]
[<ffffffff8120e676>] irq_exit+0x216/0x2c0 kernel/softirq.c:391
[<ffffffff82c5edab>] exiting_irq arch/x86/include/asm/apic.h:652 [inline]
[<ffffffff82c5edab>] smp_apic_timer_interrupt+0x8b/0xc0 arch/x86/kernel/apic/apic.c:926
[<ffffffff82c5c985>] apic_timer_interrupt+0xa5/0xb0 arch/x86/entry/entry_64.S:735
<EOI> [<ffffffff81188096>] ? native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:52
[<ffffffff810834d7>] arch_safe_halt arch/x86/include/asm/paravirt.h:111 [inline]
[<ffffffff810834d7>] default_idle+0x27/0x430 arch/x86/kernel/process.c:446
[<ffffffff81085f05>] arch_cpu_idle+0x15/0x20 arch/x86/kernel/process.c:437
[<ffffffff8132abc3>] default_idle_call+0x53/0x90 kernel/sched/idle.c:92
[<ffffffff8132b32d>] cpuidle_idle_call kernel/sched/idle.c:156 [inline]
[<ffffffff8132b32d>] cpu_idle_loop kernel/sched/idle.c:251 [inline]
[<ffffffff8132b32d>] cpu_startup_entry+0x60d/0x9a0 kernel/sched/idle.c:299
[<ffffffff8113e119>] start_secondary+0x3c9/0x560 arch/x86/kernel/smpboot.c:245
xfrm_add_policy calls verify_newpolicy_info to check user's policy info,
but it doest check policy index correcly, if the policy index(ex. 6) is great
than XFRM_POLICY_MAX which is 3 for now, the validation check will be bypassed.
It will trigger out of bounds access.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: e682adf021be ("xfrm: Try to honor policy index if it's supplied by user")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/xfrm/xfrm_user.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index a131f9f..c2de950 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1424,7 +1424,8 @@ static int verify_newpolicy_info(struct xfrm_userpolicy_info *p)
ret = verify_policy_dir(p->dir);
if (ret)
return ret;
- if (p->index && ((p->index & XFRM_POLICY_MAX) != p->dir))
+ if (p->index && (p->index > XFRM_POLICY_MAX &&
+ (p->index & XFRM_POLICY_MAX) != p->dir))
return -EINVAL;
return 0;
--
2.7.0
^ permalink raw reply related
* Re: [PATCH] tcp: detect use sendpage for slab-based objects
From: Vasily Averin @ 2019-02-25 9:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <56220566-0811-eabe-53f2-9fa625a58bbd@virtuozzo.com>
On 2/25/19 12:15 PM, Vasily Averin wrote:
> On 2/22/19 7:39 PM, Eric Dumazet wrote:
>> On Fri, Feb 22, 2019 at 6:02 AM Vasily Averin <vvs@virtuozzo.com> wrote:
>
>>> Eric, could you please elaborate once again why tcp_sendpage() should not handle slab objects?
>>
>> Simply because SLAB has its own way to manage objects from a page, and
>> does not care
>> about the underlying page having its refcount elevated.
>>
>> ptr = kmalloc(xx)
>> ... < here you can attempt cheating and add one to the underlying page>
>> kfree(ptr); // SLAB does not care of page count, it will effectively
>> put ptr in the free list.
>>
>> ptr2 = kmalloc(xx); //
>>
>> ptr2 can be the same than ptr (object was kfreed() earlier)
>>
>> This means that some other stuff will happily reuse the piece of
>> memory that you wanted to use for zero-copy.
>>
>> This is a serious bug IMO, since this would allow for data corruption.
>
> Thank you for explanation, however I still have some doubts.
>
> Yes, it's strange to use sendpage if we want to send some small 8-bytes-long slab based object,
> it's better to use sendmsg instead.
>
> Yes, using of sendpage for slab-based objects can require special attention
> to guarantee that slab object will not be freed until end of IO.
> However IMO this should be guaranteed if caller uses sendmsg instead of sendpage.
> Btw, as far as I understand in my example XFS did it correctly, submitted slab objects was kept in use
> and seems they should be freed after end of IO, via end_io callback.
> At least I did not found any bugs in sendpage callers.
>
> And most important, it seems for me switch from sendpage to sendmsg doe not resolve the problem completely:
> tcp_sendmsg_locked() under some conditions can merge neighbours slab-based tcp fragments,
> so local tcp_recvmsg() can trigger BUG_ON in this case too.
>
> Am I missed something probably?
Seems I missed that skb_copy_to_page_nocache() in tcp_sendpage_locked copies data from original slab object,
and merges fragments with copied data.
^ 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