* Re: Fwd: [PATCH] bonding/802.3ad: fix slave initialization states race
From: Jay Vosburgh @ 2019-09-25 0:31 UTC (permalink / raw)
To: =?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JfQsNGF0LDRgNC+0LI=?=; +Cc: netdev, zhangsha (A)
In-Reply-To: <CAJYOGF_XStpFRkp0jN0um9d9WR1bqGpK2V=UgdnnX2m4YC=5pw@mail.gmail.com>
Алексей Захаров wrote:
[...]
>Right after reboot one of the slaves hangs with actor port state 71
>and partner port state 1.
>It doesn't send lacpdu and seems to be broken.
>Setting link down and up again fixes slave state.
[...]
I think I see what failed in the first patch, could you test the
following patch? This one is for net-next, so you'd need to again swap
slave_err / netdev_err for the Ubuntu 4.15 kernel.
Thanks,
-J
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 931d9d935686..5e248588259a 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1617,6 +1617,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
if (bond->params.miimon) {
if (bond_check_dev_link(bond, slave_dev, 0) == BMSR_LSTATUS) {
if (bond->params.updelay) {
+/*XXX*/slave_info(bond_dev, slave_dev, "BOND_LINK_BACK initial state\n");
bond_set_slave_link_state(new_slave,
BOND_LINK_BACK,
BOND_SLAVE_NOTIFY_NOW);
@@ -2086,8 +2087,7 @@ static int bond_miimon_inspect(struct bonding *bond)
ignore_updelay = !rcu_dereference(bond->curr_active_slave);
bond_for_each_slave_rcu(bond, slave, iter) {
- slave->new_link = BOND_LINK_NOCHANGE;
- slave->link_new_state = slave->link;
+ bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
link_state = bond_check_dev_link(bond, slave->dev, 0);
@@ -2096,8 +2096,6 @@ static int bond_miimon_inspect(struct bonding *bond)
if (link_state)
continue;
- bond_propose_link_state(slave, BOND_LINK_FAIL);
- commit++;
slave->delay = bond->params.downdelay;
if (slave->delay) {
slave_info(bond->dev, slave->dev, "link status down for %sinterface, disabling it in %d ms\n",
@@ -2106,6 +2104,7 @@ static int bond_miimon_inspect(struct bonding *bond)
(bond_is_active_slave(slave) ?
"active " : "backup ") : "",
bond->params.downdelay * bond->params.miimon);
+ slave->link = BOND_LINK_FAIL;
}
/*FALLTHRU*/
case BOND_LINK_FAIL:
@@ -2121,7 +2120,7 @@ static int bond_miimon_inspect(struct bonding *bond)
}
if (slave->delay <= 0) {
- slave->new_link = BOND_LINK_DOWN;
+ bond_propose_link_state(slave, BOND_LINK_DOWN);
commit++;
continue;
}
@@ -2133,15 +2132,13 @@ static int bond_miimon_inspect(struct bonding *bond)
if (!link_state)
continue;
- bond_propose_link_state(slave, BOND_LINK_BACK);
- commit++;
slave->delay = bond->params.updelay;
-
if (slave->delay) {
slave_info(bond->dev, slave->dev, "link status up, enabling it in %d ms\n",
ignore_updelay ? 0 :
bond->params.updelay *
bond->params.miimon);
+ slave->link = BOND_LINK_BACK;
}
/*FALLTHRU*/
case BOND_LINK_BACK:
@@ -2158,7 +2155,7 @@ static int bond_miimon_inspect(struct bonding *bond)
slave->delay = 0;
if (slave->delay <= 0) {
- slave->new_link = BOND_LINK_UP;
+ bond_propose_link_state(slave, BOND_LINK_UP);
commit++;
ignore_updelay = false;
continue;
@@ -2196,7 +2193,7 @@ static void bond_miimon_commit(struct bonding *bond)
struct slave *slave, *primary;
bond_for_each_slave(bond, slave, iter) {
- switch (slave->new_link) {
+ switch (slave->link_new_state) {
case BOND_LINK_NOCHANGE:
/* For 802.3ad mode, check current slave speed and
* duplex again in case its port was disabled after
@@ -2268,8 +2265,8 @@ static void bond_miimon_commit(struct bonding *bond)
default:
slave_err(bond->dev, slave->dev, "invalid new link %d on slave\n",
- slave->new_link);
- slave->new_link = BOND_LINK_NOCHANGE;
+ slave->link_new_state);
+ bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
continue;
}
@@ -2677,13 +2674,13 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
bond_for_each_slave_rcu(bond, slave, iter) {
unsigned long trans_start = dev_trans_start(slave->dev);
- slave->new_link = BOND_LINK_NOCHANGE;
+ bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
if (slave->link != BOND_LINK_UP) {
if (bond_time_in_interval(bond, trans_start, 1) &&
bond_time_in_interval(bond, slave->last_rx, 1)) {
- slave->new_link = BOND_LINK_UP;
+ bond_propose_link_state(slave, BOND_LINK_UP);
slave_state_changed = 1;
/* primary_slave has no meaning in round-robin
@@ -2708,7 +2705,7 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
if (!bond_time_in_interval(bond, trans_start, 2) ||
!bond_time_in_interval(bond, slave->last_rx, 2)) {
- slave->new_link = BOND_LINK_DOWN;
+ bond_propose_link_state(slave, BOND_LINK_DOWN);
slave_state_changed = 1;
if (slave->link_failure_count < UINT_MAX)
@@ -2739,8 +2736,8 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
goto re_arm;
bond_for_each_slave(bond, slave, iter) {
- if (slave->new_link != BOND_LINK_NOCHANGE)
- slave->link = slave->new_link;
+ if (slave->link_new_state != BOND_LINK_NOCHANGE)
+ slave->link = slave->link_new_state;
}
if (slave_state_changed) {
@@ -2763,9 +2760,9 @@ static void bond_loadbalance_arp_mon(struct bonding *bond)
}
/* Called to inspect slaves for active-backup mode ARP monitor link state
- * changes. Sets new_link in slaves to specify what action should take
- * place for the slave. Returns 0 if no changes are found, >0 if changes
- * to link states must be committed.
+ * changes. Sets proposed link state in slaves to specify what action
+ * should take place for the slave. Returns 0 if no changes are found, >0
+ * if changes to link states must be committed.
*
* Called with rcu_read_lock held.
*/
@@ -2777,12 +2774,12 @@ static int bond_ab_arp_inspect(struct bonding *bond)
int commit = 0;
bond_for_each_slave_rcu(bond, slave, iter) {
- slave->new_link = BOND_LINK_NOCHANGE;
+ bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
last_rx = slave_last_rx(bond, slave);
if (slave->link != BOND_LINK_UP) {
if (bond_time_in_interval(bond, last_rx, 1)) {
- slave->new_link = BOND_LINK_UP;
+ bond_propose_link_state(slave, BOND_LINK_UP);
commit++;
}
continue;
@@ -2810,7 +2807,7 @@ static int bond_ab_arp_inspect(struct bonding *bond)
if (!bond_is_active_slave(slave) &&
!rcu_access_pointer(bond->current_arp_slave) &&
!bond_time_in_interval(bond, last_rx, 3)) {
- slave->new_link = BOND_LINK_DOWN;
+ bond_propose_link_state(slave, BOND_LINK_DOWN);
commit++;
}
@@ -2823,7 +2820,7 @@ static int bond_ab_arp_inspect(struct bonding *bond)
if (bond_is_active_slave(slave) &&
(!bond_time_in_interval(bond, trans_start, 2) ||
!bond_time_in_interval(bond, last_rx, 2))) {
- slave->new_link = BOND_LINK_DOWN;
+ bond_propose_link_state(slave, BOND_LINK_DOWN);
commit++;
}
}
@@ -2843,7 +2840,7 @@ static void bond_ab_arp_commit(struct bonding *bond)
struct slave *slave;
bond_for_each_slave(bond, slave, iter) {
- switch (slave->new_link) {
+ switch (slave->link_new_state) {
case BOND_LINK_NOCHANGE:
continue;
@@ -2893,8 +2890,9 @@ static void bond_ab_arp_commit(struct bonding *bond)
continue;
default:
- slave_err(bond->dev, slave->dev, "impossible: new_link %d on slave\n",
- slave->new_link);
+ slave_err(bond->dev, slave->dev,
+ "impossible: link_new_state %d on slave\n",
+ slave->link_new_state);
continue;
}
@@ -3133,6 +3131,7 @@ static int bond_slave_netdev_event(unsigned long event,
* let link-monitoring (miimon) set it right when correct
* speeds/duplex are available.
*/
+/*XXX*/slave_info(bond_dev, slave_dev, "EVENT %lu llu %lu\n", event, slave->last_link_up);
if (bond_update_speed_duplex(slave) &&
BOND_MODE(bond) == BOND_MODE_8023AD) {
if (slave->last_link_up)
diff --git a/include/net/bonding.h b/include/net/bonding.h
index f7fe45689142..d416af72404b 100644
--- a/include/net/bonding.h
+++ b/include/net/bonding.h
@@ -159,7 +159,6 @@ struct slave {
unsigned long target_last_arp_rx[BOND_MAX_ARP_TARGETS];
s8 link; /* one of BOND_LINK_XXXX */
s8 link_new_state; /* one of BOND_LINK_XXXX */
- s8 new_link;
u8 backup:1, /* indicates backup slave. Value corresponds with
BOND_STATE_ACTIVE and BOND_STATE_BACKUP */
inactive:1, /* indicates inactive slave */
@@ -549,7 +548,7 @@ static inline void bond_propose_link_state(struct slave *slave, int state)
static inline void bond_commit_link_state(struct slave *slave, bool notify)
{
- if (slave->link == slave->link_new_state)
+ if (slave->link_new_state == BOND_LINK_NOCHANGE)
return;
slave->link = slave->link_new_state;
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply related
* Re: [BUG] Unable to handle kernel NULL pointer dereference in phy_support_asym_pause
From: Andrew Lunn @ 2019-09-25 0:44 UTC (permalink / raw)
To: Michal Vokáč
Cc: netdev@vger.kernel.org, Vivien Didelot, Florian Fainelli,
David S. Miller
In-Reply-To: <e7bffa36-f218-d71e-c416-38aff73d35dd@ysoft.com>
On Tue, Sep 24, 2019 at 03:10:44PM +0200, Michal Vokáč wrote:
> On 24. 09. 19 14:31, Andrew Lunn wrote:
> I added the printk and the above fix and can confirm that it is the CPU
> port and the phy is NULL pointer:
>
> [ 6.976366] qca8k 2188000.ethernet-1:0a: Using legacy PHYLIB callbacks. Please migrate to PHYLINK!
> [ 6.992021] qca8k 2188000.ethernet-1:0a: port: 0, phy: 0
> [ 7.001323] qca8k 2188000.ethernet-1:0a eth2 (uninitialized): PHY [2188000.ethernet-1:01] driver [Generic PHY]
> [ 7.014221] qca8k 2188000.ethernet-1:0a eth2 (uninitialized): phy: setting supported 00,00000000,000062ef advertising 00,00000000,000062ef
> [ 7.030598] qca8k 2188000.ethernet-1:0a eth1 (uninitialized): PHY [2188000.ethernet-1:02] driver [Generic PHY]
> [ 7.043500] qca8k 2188000.ethernet-1:0a eth1 (uninitialized): phy: setting supported 00,00000000,000062ef advertising 00,00000000,000062ef
> [ 7.063335] DSA: tree 0 setup
>
> Now the device boots but there is a problem with the CPU port configuration:
Hi Michal
Thanks for testing. I will post a different fix very soon.
> root@hydraco:~# ifconfig eth0 up
> [ 255.256047] Generic PHY fixed-0:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=fixed-0:00, irq=POLL)
> [ 255.272449] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
> [ 255.286539] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> root@hydraco:~# ifconfig eth1 up
> [ 268.350078] qca8k 2188000.ethernet-1:0a: port: 3, phy: -393143296
> [ 268.364442] qca8k 2188000.ethernet-1:0a eth1: configuring for phy/ link mode
> [ 268.375400] qca8k 2188000.ethernet-1:0a eth1: phylink_mac_config: mode=phy//Unknown/Unknown adv=00,00000000,000062ef pause=10 link=0 an=1
> [ 268.393901] qca8k 2188000.ethernet-1:0a eth1: phy link up /1Gbps/Full
> [ 268.404849] qca8k 2188000.ethernet-1:0a eth1: phylink_mac_config: mode=phy//1Gbps/Full adv=00,00000000,00000000 pause=0e link=1 an=0
> [ 268.420740] qca8k 2188000.ethernet-1:0a eth1: Link is Up - 1Gbps/Full - flow control rx/tx
> [ 268.432995] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
> root@hydraco:~# udhcpc -i eth1
> udhcpc (v1.23.2) started
> Sending discover...
> Sending discover...
> Sending discover...
This i think is something different. What looks odd is
imx6dl-yapp4-common.dtsi
&fec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
phy-mode = "rgmii-id";
phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
phy-reset-duration = <20>;
phy-supply = <&sw2_reg>;
phy-handle = <ðphy0>;
status = "okay";
mdio {
switch@10 {
compatible = "qca,qca8334";
reg = <10>;
switch_ports: ports {
#address-cells = <1>;
#size-cells = <0>;
ethphy0: port@0 {
reg = <0>;
label = "cpu";
phy-mode = "rgmii-id";
ethernet = <&fec>;
Both the FEC and the CPU port are set to use rgmii-id". So we are
getting double delays.
Try changing one of these to plain rgmii.
Andrew
^ permalink raw reply
* [PATCH net] net: dsa: qca8k: Fix port enable for CPU port
From: Andrew Lunn @ 2019-09-25 0:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Vivien Didelot, michal.vokac, Andrew Lunn
The CPU port does not have a PHY connected to it. So calling
phy_support_asym_pause() results in an Opps. As with other DSA
drivers, add a guard that the port is a user port.
Reported-by: Michal Vokáč <michal.vokac@ysoft.com>
Fixes: 0394a63acfe2 ("net: dsa: enable and disable all ports")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/qca8k.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/dsa/qca8k.c b/drivers/net/dsa/qca8k.c
index 16f15c93a102..684aa51684db 100644
--- a/drivers/net/dsa/qca8k.c
+++ b/drivers/net/dsa/qca8k.c
@@ -936,6 +936,9 @@ qca8k_port_enable(struct dsa_switch *ds, int port,
{
struct qca8k_priv *priv = (struct qca8k_priv *)ds->priv;
+ if (!dsa_is_user_port(ds, port))
+ return 0;
+
qca8k_port_set_status(priv, port, 1);
priv->port_sts[port].enabled = 1;
--
2.23.0
^ permalink raw reply related
* [PATCH] iwlwifi: prevent memory leak
From: Navid Emamdoost @ 2019-09-25 1:09 UTC (permalink / raw)
Cc: emamd001, smccaman, kjlu, Navid Emamdoost, Johannes Berg,
Emmanuel Grumbach, Luca Coelho, Intel Linux Wireless, Kalle Valo,
David S. Miller, Shahar S Matityahu, Sara Sharon, linux-wireless,
netdev, linux-kernel
In alloc_sgtable if alloc_page fails, along with releasing previously
allocated pages, the allocated table should be released too.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
---
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
index 5c8602de9168..87421807e040 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
+++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
@@ -646,6 +646,7 @@ static struct scatterlist *alloc_sgtable(int size)
if (new_page)
__free_page(new_page);
}
+ kfree(table);
return NULL;
}
alloc_size = min_t(int, size, PAGE_SIZE);
--
2.17.1
^ permalink raw reply related
* [PATCH] rtlwifi: prevent memory leak in rtl_usb_probe
From: Navid Emamdoost @ 2019-09-25 1:20 UTC (permalink / raw)
Cc: emamd001, smccaman, kjlu, Navid Emamdoost, Ping-Ke Shih,
Kalle Valo, David S. Miller, linux-wireless, netdev, linux-kernel
In rtl_usb_probe if allocation for usb_data fails the allocated hw
should be released. In addition the allocated rtlpriv->usb_data should
be released on error handling path.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
---
drivers/net/wireless/realtek/rtlwifi/usb.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 4b59f3b46b28..348b0072cdd6 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -1021,8 +1021,10 @@ int rtl_usb_probe(struct usb_interface *intf,
rtlpriv->hw = hw;
rtlpriv->usb_data = kcalloc(RTL_USB_MAX_RX_COUNT, sizeof(u32),
GFP_KERNEL);
- if (!rtlpriv->usb_data)
+ if (!rtlpriv->usb_data) {
+ ieee80211_free_hw(hw);
return -ENOMEM;
+ }
/* this spin lock must be initialized early */
spin_lock_init(&rtlpriv->locks.usb_lock);
@@ -1083,6 +1085,7 @@ int rtl_usb_probe(struct usb_interface *intf,
_rtl_usb_io_handler_release(hw);
usb_put_dev(udev);
complete(&rtlpriv->firmware_loading_complete);
+ kfree(rtlpriv->usb_data);
return -ENODEV;
}
EXPORT_SYMBOL(rtl_usb_probe);
--
2.17.1
^ permalink raw reply related
* Re: Fw: [Bug 204903] New: unable to create vrf interface when ipv6.disable=1
From: David Ahern @ 2019-09-25 2:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20190919104628.05d9f5ff@xps13>
On 9/19/19 2:46 AM, Stephen Hemminger wrote:
>
>
> Begin forwarded message:
>
> Date: Wed, 18 Sep 2019 15:15:42 +0000
> From: bugzilla-daemon@bugzilla.kernel.org
> To: stephen@networkplumber.org
> Subject: [Bug 204903] New: unable to create vrf interface when ipv6.disable=1
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=204903
>
> Bug ID: 204903
> Summary: unable to create vrf interface when ipv6.disable=1
> Product: Networking
> Version: 2.5
> Kernel Version: 5.2.14
> Hardware: All
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> Assignee: stephen@networkplumber.org
> Reporter: zhangyoufu@gmail.com
> Regression: No
>
> `ip link add vrf0 type vrf table 100` fails with EAFNOSUPPORT when boot with
> `ipv6.disable=1`. There must be somewhere inside `vrf_newlink` trying to use
> IPv6 without checking availablity. Maybe `vrf_add_fib_rules` I guess.
>
ack. I'll take a look when I get a chance. Should be a simple fix.
^ permalink raw reply
* [PATCH] net: use unlikely for dql_avail case
From: xiaolinkui @ 2019-09-25 2:40 UTC (permalink / raw)
To: davem; +Cc: netdev, xiaolinkui
This is an unlikely case, use unlikely() on it seems logical.
Signed-off-by: xiaolinkui <xiaolinkui@kylinos.cn>
---
include/linux/netdevice.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 88292953aa6f..005f3da1b13d 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3270,7 +3270,7 @@ static inline void netdev_tx_completed_queue(struct netdev_queue *dev_queue,
*/
smp_mb();
- if (dql_avail(&dev_queue->dql) < 0)
+ if (unlikely(dql_avail(&dev_queue->dql) < 0))
return;
if (test_and_clear_bit(__QUEUE_STATE_STACK_XOFF, &dev_queue->state))
--
2.17.1
^ permalink raw reply related
* RE: [PATCH v2] r8152: Use guard clause and fix comment typos
From: Hayes Wang @ 2019-09-25 2:51 UTC (permalink / raw)
To: Prashant Malani; +Cc: grundler@chromium.org, netdev@vger.kernel.org, nic_swsd
In-Reply-To: <20190924040052.71713-1-pmalani@chromium.org>
Prashant Malani [mailto:pmalani@chromium.org]
> Sent: Tuesday, September 24, 2019 12:01 PM
> To: Hayes Wang
> Cc: grundler@chromium.org; netdev@vger.kernel.org; nic_swsd; Prashant
> Malani
> Subject: [PATCH v2] r8152: Use guard clause and fix comment typos
>
> Use a guard clause in tx_bottom() to reduce the indentation of the
> do-while loop.
>
> Also, fix a couple of spelling and grammatical mistakes in the
> r8152_csum_workaround() function comment.
>
> Change-Id: I460befde150ad92248fd85b0f189ec2df2ab8431
> Signed-off-by: Prashant Malani <pmalani@chromium.org>
> Reviewed-by: Grant Grundler <grundler@chromium.org>
Acked-by: Hayes Wang <hayeswang@realtek.com>
Best Regards,
Hayes
^ permalink raw reply
* [PATCH] net/mlx5: prevent memory leak in mlx5_fpga_conn_create_cq
From: Navid Emamdoost @ 2019-09-25 3:20 UTC (permalink / raw)
Cc: emamd001, smccaman, kjlu, Navid Emamdoost, Boris Pismenny,
Saeed Mahameed, Leon Romanovsky, David S. Miller, Yishai Hadas,
Maxim Mikityanskiy, Eran Ben Elisha, Tariq Toukan, Bodong Wang,
netdev, linux-rdma, linux-kernel
In mlx5_fpga_conn_create_cq if mlx5_vector2eqn fails the allocated
memory should be released.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
---
drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c b/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c
index 4c50efe4e7f1..61021133029e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c
@@ -464,8 +464,10 @@ static int mlx5_fpga_conn_create_cq(struct mlx5_fpga_conn *conn, int cq_size)
}
err = mlx5_vector2eqn(mdev, smp_processor_id(), &eqn, &irqn);
- if (err)
+ if (err) {
+ kvfree(in);
goto err_cqwq;
+ }
cqc = MLX5_ADDR_OF(create_cq_in, in, cq_context);
MLX5_SET(cqc, cqc, log_cq_size, ilog2(cq_size));
--
2.17.1
^ permalink raw reply related
* Re: [PATCH bpf-next v11 3/4] tools: Added bpf_get_ns_current_pid_tgid helper
From: Yonghong Song @ 2019-09-25 3:27 UTC (permalink / raw)
To: Carlos Neira, netdev@vger.kernel.org
Cc: ebiederm@xmission.com, brouer@redhat.com, bpf@vger.kernel.org
In-Reply-To: <20190924152005.4659-4-cneirabustos@gmail.com>
On 9/24/19 8:20 AM, Carlos Neira wrote:
> Signed-off-by: Carlos Neira <cneirabustos@gmail.com>
Please do add some commit message. A couple of examples,
commit 0fc2e0b84ba725c5e6ee66059936638389e67c80
Author: Alexei Starovoitov <ast@kernel.org>
Date: Thu Aug 22 22:52:13 2019 -0700
tools/bpf: sync bpf.h
sync bpf.h from kernel/ to tools/
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
commit 1f8919b170318e7e13e303eedac363d44057995f
Author: Peter Wu <peter@lekensteyn.nl>
Date: Wed Aug 21 00:09:00 2019 +0100
bpf: sync bpf.h to tools/
Fix a 'struct pt_reg' typo and clarify when bpf_trace_printk discards
lines. Affects documentation only.
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
> tools/include/uapi/linux/bpf.h | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
> index 77c6be96d676..9272dc8fb08c 100644
> --- a/tools/include/uapi/linux/bpf.h
> +++ b/tools/include/uapi/linux/bpf.h
> @@ -2750,6 +2750,21 @@ union bpf_attr {
> * **-EOPNOTSUPP** kernel configuration does not enable SYN cookies
> *
> * **-EPROTONOSUPPORT** IP packet version is not 4 or 6
> + *
> + * int bpf_get_ns_current_pid_tgid(u32 dev, u64 inum)
> + * Return
> + * A 64-bit integer containing the current tgid and pid from current task
> + * which namespace inode and dev_t matches , and is create as such:
> + * *current_task*\ **->tgid << 32 \|**
> + * *current_task*\ **->pid**.
> + *
> + * On failure, the returned value is one of the following:
> + *
> + * **-EINVAL** if dev and inum supplied don't match dev_t and inode number
> + * with nsfs of current task.
> + *
> + * **-ENOENT** if /proc/self/ns does not exists.
> + *
> */
> #define __BPF_FUNC_MAPPER(FN) \
> FN(unspec), \
> @@ -2862,7 +2877,8 @@ union bpf_attr {
> FN(sk_storage_get), \
> FN(sk_storage_delete), \
> FN(send_signal), \
> - FN(tcp_gen_syncookie),
> + FN(tcp_gen_syncookie), \
> + FN(get_ns_current_pid_tgid),
>
> /* integer value in 'imm' field of BPF_CALL instruction selects which helper
> * function eBPF program intends to call
>
^ permalink raw reply
* Re: [PATCH] vhost: It's better to use size_t for the 3rd parameter of vhost_exceeds_weight()
From: Jason Wang @ 2019-09-25 3:59 UTC (permalink / raw)
To: wangxu (AE), Michael S. Tsirkin
Cc: kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <FCFCADD62FC0CA4FAEA05F13220975B01717A091@dggeml525-mbx.china.huawei.com>
On 2019/9/23 下午5:12, wangxu (AE) wrote:
> Hi Michael
>
> Thanks for your fast reply.
>
> As the following code, the 2nd branch of iov_iter_advance() does not check if i->count < size, when this happens, i->count -= size may cause len exceed INT_MAX, and then total_len exceed INT_MAX.
>
> handle_tx_copy() ->
> get_tx_bufs(..., &len, ...) ->
> init_iov_iter() ->
> iov_iter_advance(iter, ...) // has 3 branches:
> pipe_advance() // has checked the size: if (unlikely(i->count < size)) size = i->count;
> iov_iter_is_discard() ... // no check.
Yes, but I don't think we use ITER_DISCARD.
Thanks
> iterate_and_advance() //has checked: if (unlikely(i->count < n)) n = i->count;
> return iov_iter_count(iter);
>
> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: Monday, September 23, 2019 4:07 PM
> To: wangxu (AE) <wangxu72@huawei.com>
> Cc: jasowang@redhat.com; kvm@vger.kernel.org; virtualization@lists.linux-foundation.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] vhost: It's better to use size_t for the 3rd parameter of vhost_exceeds_weight()
>
> On Mon, Sep 23, 2019 at 03:46:41PM +0800, wangxu wrote:
>> From: Wang Xu <wangxu72@huawei.com>
>>
>> Caller of vhost_exceeds_weight(..., total_len) in drivers/vhost/net.c
>> usually pass size_t total_len, which may be affected by rx/tx package.
>>
>> Signed-off-by: Wang Xu <wangxu72@huawei.com>
>
> Puts a bit more pressure on the register file ...
> why do we care? Is there some way that it can exceed INT_MAX?
>
>> ---
>> drivers/vhost/vhost.c | 4 ++--
>> drivers/vhost/vhost.h | 7 ++++---
>> 2 files changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index
>> 36ca2cf..159223a 100644
>> --- a/drivers/vhost/vhost.c
>> +++ b/drivers/vhost/vhost.c
>> @@ -412,7 +412,7 @@ static void vhost_dev_free_iovecs(struct vhost_dev
>> *dev) }
>>
>> bool vhost_exceeds_weight(struct vhost_virtqueue *vq,
>> - int pkts, int total_len)
>> + int pkts, size_t total_len)
>> {
>> struct vhost_dev *dev = vq->dev;
>>
>> @@ -454,7 +454,7 @@ static size_t vhost_get_desc_size(struct
>> vhost_virtqueue *vq,
>>
>> void vhost_dev_init(struct vhost_dev *dev,
>> struct vhost_virtqueue **vqs, int nvqs,
>> - int iov_limit, int weight, int byte_weight)
>> + int iov_limit, int weight, size_t byte_weight)
>> {
>> struct vhost_virtqueue *vq;
>> int i;
>> diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h index
>> e9ed272..8d80389d 100644
>> --- a/drivers/vhost/vhost.h
>> +++ b/drivers/vhost/vhost.h
>> @@ -172,12 +172,13 @@ struct vhost_dev {
>> wait_queue_head_t wait;
>> int iov_limit;
>> int weight;
>> - int byte_weight;
>> + size_t byte_weight;
>> };
>>
>
> This just costs extra memory, and value is never large, so I don't think this matters.
>
>> -bool vhost_exceeds_weight(struct vhost_virtqueue *vq, int pkts, int
>> total_len);
>> +bool vhost_exceeds_weight(struct vhost_virtqueue *vq, int pkts,
>> + size_t total_len);
>> void vhost_dev_init(struct vhost_dev *, struct vhost_virtqueue **vqs,
>> - int nvqs, int iov_limit, int weight, int byte_weight);
>> + int nvqs, int iov_limit, int weight, size_t byte_weight);
>> long vhost_dev_set_owner(struct vhost_dev *dev); bool
>> vhost_dev_has_owner(struct vhost_dev *dev); long
>> vhost_dev_check_owner(struct vhost_dev *);
>> --
>> 1.8.5.6
^ permalink raw reply
* Re: [PATCH net-next] tuntap: Fallback to automq on TUNSETSTEERINGEBPF prog negative return
From: Jason Wang @ 2019-09-25 4:08 UTC (permalink / raw)
To: Matt Cover
Cc: Michael S. Tsirkin, davem, ast, daniel, kafai, songliubraving,
yhs, Eric Dumazet, Stanislav Fomichev, Matthew Cover, mail,
pabeni, Nicolas Dichtel, wangli39, lifei.shirley, tglx, netdev,
linux-kernel, bpf
In-Reply-To: <CAGyo_hq2fyVOOJ9ktDoM9M4umAonb0ofhP6puTz91UHEp=ojDA@mail.gmail.com>
On 2019/9/24 上午12:31, Matt Cover wrote:
>> I think it's better to safe to just drop the packet instead of trying to
>> workaround it.
>>
> This patch aside, dropping the packet here
> seems like the wrong choice. Loading a
> prog at this hookpoint "configures"
> steering. The action of configuring
> steering should not result in dropped
> packets.
>
> Suboptimal delivery is generally preferable
> to no delivery. Leaving the behavior as-is
> (i.e. relying on netdev_cap_txqueue()) or
> making any return which doesn't fit in a
> u16 simply use queue 0 would be highly
> preferable to dropping the packet.
>
>> Thanks
It leaves a choice for steering ebpf program to drop the packet that it
can't classify. But consider we have already had socket filter, it
probably not a big problem since we can drop packets there.
Thanks
^ permalink raw reply
* INFO: trying to register non-static key in finish_writeback_work
From: syzbot @ 2019-09-25 5:09 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel, netdev, syzkaller-bugs, viro
Hello,
syzbot found the following crash on:
HEAD commit: b41dae06 Merge tag 'xfs-5.4-merge-7' of git://git.kernel.o..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17d19a7e600000
kernel config: https://syzkaller.appspot.com/x/.config?x=dfcf592db22b9132
dashboard link: https://syzkaller.appspot.com/bug?extid=21875b598ddcdc309b28
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15fcf1a1600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+21875b598ddcdc309b28@syzkaller.appspotmail.com
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 2603 Comm: kworker/u4:4 Not tainted 5.3.0+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: writeback wb_workfn (flush-8:0)
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
assign_lock_key kernel/locking/lockdep.c:881 [inline]
register_lock_class+0x179e/0x1850 kernel/locking/lockdep.c:1190
__lock_acquire+0xf4/0x4e70 kernel/locking/lockdep.c:3837
lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4487
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159
__wake_up_common_lock+0xc8/0x150 kernel/sched/wait.c:122
__wake_up+0xe/0x10 kernel/sched/wait.c:142
finish_writeback_work.isra.0+0xf6/0x120 fs/fs-writeback.c:168
wb_do_writeback fs/fs-writeback.c:2030 [inline]
wb_workfn+0x34f/0x11e0 fs/fs-writeback.c:2070
process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
worker_thread+0x98/0xe40 kernel/workqueue.c:2415
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 2603 Comm: kworker/u4:4 Not tainted 5.3.0+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: writeback wb_workfn (flush-8:0)
RIP: 0010:__wake_up_common+0xdf/0x610 kernel/sched/wait.c:86
Code: 05 00 00 4c 8b 43 38 49 83 e8 18 49 8d 78 18 48 39 7d d0 0f 84 64 02
00 00 48 b8 00 00 00 00 00 fc ff df 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f
85 0b 05 00 00 49 8b 40 18 89 55 b0 31 db 49 bc 00
RSP: 0018:ffff8880a1dc7a90 EFLAGS: 00010046
RAX: dffffc0000000000 RBX: ffff888079642000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 1ffffffff138d60e RDI: 0000000000000000
RBP: ffff8880a1dc7ae8 R08: ffffffffffffffe8 R09: ffff8880a1dc7b38
R10: ffffed10143b8f4b R11: 0000000000000003 R12: 0000000000000000
R13: 0000000000000286 R14: 0000000000000000 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2e620020 CR3: 00000000a3f3e000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__wake_up_common_lock+0xea/0x150 kernel/sched/wait.c:123
__wake_up+0xe/0x10 kernel/sched/wait.c:142
finish_writeback_work.isra.0+0xf6/0x120 fs/fs-writeback.c:168
wb_do_writeback fs/fs-writeback.c:2030 [inline]
wb_workfn+0x34f/0x11e0 fs/fs-writeback.c:2070
process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
worker_thread+0x98/0xe40 kernel/workqueue.c:2415
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace a54dff274d7cf269 ]---
RIP: 0010:__wake_up_common+0xdf/0x610 kernel/sched/wait.c:86
Code: 05 00 00 4c 8b 43 38 49 83 e8 18 49 8d 78 18 48 39 7d d0 0f 84 64 02
00 00 48 b8 00 00 00 00 00 fc ff df 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f
85 0b 05 00 00 49 8b 40 18 89 55 b0 31 db 49 bc 00
RSP: 0018:ffff8880a1dc7a90 EFLAGS: 00010046
RAX: dffffc0000000000 RBX: ffff888079642000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 1ffffffff138d60e RDI: 0000000000000000
RBP: ffff8880a1dc7ae8 R08: ffffffffffffffe8 R09: ffff8880a1dc7b38
R10: ffffed10143b8f4b R11: 0000000000000003 R12: 0000000000000000
R13: 0000000000000286 R14: 0000000000000000 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2e620020 CR3: 00000000a3f3e000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: Fw: [Bug 204903] New: unable to create vrf interface when ipv6.disable=1
From: Michal Kubecek @ 2019-09-25 6:01 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Stephen Hemminger
In-Reply-To: <a15f9952-e5ed-8358-e28d-6325bf4d5801@gmail.com>
On Tue, Sep 24, 2019 at 08:28:52PM -0600, David Ahern wrote:
> On 9/19/19 2:46 AM, Stephen Hemminger wrote:
> >
> >
> > Begin forwarded message:
> >
> > Date: Wed, 18 Sep 2019 15:15:42 +0000
> > From: bugzilla-daemon@bugzilla.kernel.org
> > To: stephen@networkplumber.org
> > Subject: [Bug 204903] New: unable to create vrf interface when ipv6.disable=1
> >
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=204903
> >
> > Bug ID: 204903
> > Summary: unable to create vrf interface when ipv6.disable=1
> > Product: Networking
> > Version: 2.5
> > Kernel Version: 5.2.14
> > Hardware: All
> > OS: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: Other
> > Assignee: stephen@networkplumber.org
> > Reporter: zhangyoufu@gmail.com
> > Regression: No
> >
> > `ip link add vrf0 type vrf table 100` fails with EAFNOSUPPORT when boot with
> > `ipv6.disable=1`. There must be somewhere inside `vrf_newlink` trying to use
> > IPv6 without checking availablity. Maybe `vrf_add_fib_rules` I guess.
> >
>
> ack. I'll take a look when I get a chance. Should be a simple fix.
Not sure if it's the only problem but vrf_fib_rule() checks
ipv6_mod_enabled() for AF_INET6 but not for RTNL_FAMILY_IP6MR.
Michal
^ permalink raw reply
* Re: [PATCH] ieee802154: mcr20a: simplify a bit 'mcr20a_handle_rx_read_buf_complete()'
From: Stefan Schmidt @ 2019-09-25 6:25 UTC (permalink / raw)
To: Xue Liu
Cc: Christophe JAILLET, alex. aring, David S. Miller, linux-wpan - ML,
netdev, linux-kernel, kernel-janitors
In-Reply-To: <CAJuUDwtWJgo7PHJR4kBpQ9mGamTMEaPZBNOZcL3mWFwwZ-zOmw@mail.gmail.com>
Hello.
On 24.09.19 23:40, Xue Liu wrote:
> On Sat, 21 Sep 2019 at 13:52, Stefan Schmidt <stefan@datenfreihafen.org> wrote:
>>
>> Hello Xue.
>>
>> On 20.09.19 21:45, Christophe JAILLET wrote:
>>> Use a 'skb_put_data()' variant instead of rewritting it.
>>> The __skb_put_data variant is safe here. It is obvious that the skb can
>>> not overflow. It has just been allocated a few lines above with the same
>>> 'len'.
>>>
>>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>>> ---
>>> drivers/net/ieee802154/mcr20a.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
>>> index 17f2300e63ee..8dc04e2590b1 100644
>>> --- a/drivers/net/ieee802154/mcr20a.c
>>> +++ b/drivers/net/ieee802154/mcr20a.c
>>> @@ -800,7 +800,7 @@ mcr20a_handle_rx_read_buf_complete(void *context)
>>> if (!skb)
>>> return;
>>>
>>> - memcpy(skb_put(skb, len), lp->rx_buf, len);
>>> + __skb_put_data(skb, lp->rx_buf, len);
>>> ieee802154_rx_irqsafe(lp->hw, skb, lp->rx_lqi[0]);
>>>
>>> print_hex_dump_debug("mcr20a rx: ", DUMP_PREFIX_OFFSET, 16, 1,
>>>
>>
>> Could you please review and ACK this? If you are happy I will take it
>> through my tree.
>>
>> regards
>> Stefan Schmidt
>
> Acked-by: Xue Liu <liuxuenetmail@gmail.com>
This patch has been applied to the wpan tree and will be
part of the next pull request to net. Thanks!
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH net] net: dsa: qca8k: Fix port enable for CPU port
From: Michal Vokáč @ 2019-09-25 7:06 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev, Vivien Didelot
In-Reply-To: <20190925004707.1799-1-andrew@lunn.ch>
On 25. 09. 19 2:47, Andrew Lunn wrote:
> The CPU port does not have a PHY connected to it. So calling
> phy_support_asym_pause() results in an Opps. As with other DSA
> drivers, add a guard that the port is a user port.
>
> Reported-by: Michal Vokáč <michal.vokac@ysoft.com>
Thank you for the prompt fix Andrew!
Tested-by: Michal Vokáč <michal.vokac@ysoft.com>
> Fixes: 0394a63acfe2 ("net: dsa: enable and disable all ports")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> drivers/net/dsa/qca8k.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/dsa/qca8k.c b/drivers/net/dsa/qca8k.c
> index 16f15c93a102..684aa51684db 100644
> --- a/drivers/net/dsa/qca8k.c
> +++ b/drivers/net/dsa/qca8k.c
> @@ -936,6 +936,9 @@ qca8k_port_enable(struct dsa_switch *ds, int port,
> {
> struct qca8k_priv *priv = (struct qca8k_priv *)ds->priv;
>
> + if (!dsa_is_user_port(ds, port))
> + return 0;
> +
> qca8k_port_set_status(priv, port, 1);
> priv->port_sts[port].enabled = 1;
>
>
^ permalink raw reply
* Re: [BUG] Unable to handle kernel NULL pointer dereference in phy_support_asym_pause
From: Michal Vokáč @ 2019-09-25 7:06 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev@vger.kernel.org, Vivien Didelot, Florian Fainelli,
David S. Miller
In-Reply-To: <20190925004437.GA1253@lunn.ch>
On 25. 09. 19 2:44, Andrew Lunn wrote:
> On Tue, Sep 24, 2019 at 03:10:44PM +0200, Michal Vokáč wrote:
>> On 24. 09. 19 14:31, Andrew Lunn wrote:
>> I added the printk and the above fix and can confirm that it is the CPU
>> port and the phy is NULL pointer:
>>
>> [ 6.976366] qca8k 2188000.ethernet-1:0a: Using legacy PHYLIB callbacks. Please migrate to PHYLINK!
>> [ 6.992021] qca8k 2188000.ethernet-1:0a: port: 0, phy: 0
>> [ 7.001323] qca8k 2188000.ethernet-1:0a eth2 (uninitialized): PHY [2188000.ethernet-1:01] driver [Generic PHY]
>> [ 7.014221] qca8k 2188000.ethernet-1:0a eth2 (uninitialized): phy: setting supported 00,00000000,000062ef advertising 00,00000000,000062ef
>> [ 7.030598] qca8k 2188000.ethernet-1:0a eth1 (uninitialized): PHY [2188000.ethernet-1:02] driver [Generic PHY]
>> [ 7.043500] qca8k 2188000.ethernet-1:0a eth1 (uninitialized): phy: setting supported 00,00000000,000062ef advertising 00,00000000,000062ef
>> [ 7.063335] DSA: tree 0 setup
>>
>> Now the device boots but there is a problem with the CPU port configuration:
>
> Hi Michal
>
> Thanks for testing. I will post a different fix very soon.
Thank you, I tested the patch it and it does the business.
>> root@hydraco:~# ifconfig eth0 up
>> [ 255.256047] Generic PHY fixed-0:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=fixed-0:00, irq=POLL)
>> [ 255.272449] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
>> [ 255.286539] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>> root@hydraco:~# ifconfig eth1 up
>> [ 268.350078] qca8k 2188000.ethernet-1:0a: port: 3, phy: -393143296
>> [ 268.364442] qca8k 2188000.ethernet-1:0a eth1: configuring for phy/ link mode
>> [ 268.375400] qca8k 2188000.ethernet-1:0a eth1: phylink_mac_config: mode=phy//Unknown/Unknown adv=00,00000000,000062ef pause=10 link=0 an=1
>> [ 268.393901] qca8k 2188000.ethernet-1:0a eth1: phy link up /1Gbps/Full
>> [ 268.404849] qca8k 2188000.ethernet-1:0a eth1: phylink_mac_config: mode=phy//1Gbps/Full adv=00,00000000,00000000 pause=0e link=1 an=0
>> [ 268.420740] qca8k 2188000.ethernet-1:0a eth1: Link is Up - 1Gbps/Full - flow control rx/tx
>> [ 268.432995] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
>> root@hydraco:~# udhcpc -i eth1
>> udhcpc (v1.23.2) started
>> Sending discover...
>> Sending discover...
>> Sending discover...
>
> This i think is something different. What looks odd is
> imx6dl-yapp4-common.dtsi
>
> &fec {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_enet>;
> phy-mode = "rgmii-id";
> phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
> phy-reset-duration = <20>;
> phy-supply = <&sw2_reg>;
> phy-handle = <ðphy0>;
> status = "okay";
>
>
> mdio {
>
> switch@10 {
> compatible = "qca,qca8334";
> reg = <10>;
>
> switch_ports: ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> ethphy0: port@0 {
> reg = <0>;
> label = "cpu";
> phy-mode = "rgmii-id";
> ethernet = <&fec>;
>
> Both the FEC and the CPU port are set to use rgmii-id". So we are
> getting double delays.
>
> Try changing one of these to plain rgmii.
Actually, when this file was introduced in [1] I had rgmii-id for the FEC
and rgmii for the CPU port.
Later on the RGMII mode was "fixed" in [2] and that broke the CPU port
for the first time. The problem was fixed by introducing RGMII_ID mode [3]
and using this mode for the CPU port [4].
So now I tried setting rgmii for the FEC but it does not help.
Any other ideas?
Michal
[1] 87489ec3a77f ("ARM: dts: imx: Add Y Soft IOTA Draco, Hydra and Ursa boards")
[2] 5ecdd77c61c8 ("net: dsa: qca8k: disable delay for RGMII mode")
[3] a968b5e9d587 ("net: dsa: qca8k: Enable delay for RGMII_ID mode")
[4] 1a7ee0efb26d ("ARM: dts: imx6dl-yapp4: Use rgmii-id phy mode on the cpu port")
^ permalink raw reply
* RE: [PATCH] dimlib: make DIMLIB a hidden symbol
From: Kiyanovski, Arthur @ 2019-09-25 7:59 UTC (permalink / raw)
To: Tal Gilboa, Uwe Kleine-König, Saeed Mahameed
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <670cc72f-fef0-a8cf-eb03-25fdb608eea8@mellanox.com>
> -----Original Message-----
> From: Tal Gilboa <talgi@mellanox.com>
> Sent: Friday, September 20, 2019 8:02 PM
> To: Uwe Kleine-König <uwe@kleine-koenig.org>; Saeed Mahameed
> <saeedm@mellanox.com>; Kiyanovski, Arthur <akiyano@amazon.com>
> Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org
> Subject: Re: [PATCH] dimlib: make DIMLIB a hidden symbol
>
> On 9/20/2019 4:31 PM, Uwe Kleine-König wrote:
> > According to Tal Gilboa the only benefit from DIM comes from a driver
> > that uses it. So it doesn't make sense to make this symbol user visible,
> > instead all drivers that use it should select it (as is already the case
> > AFAICT).
> >
> > Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> > ---
> > lib/Kconfig | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/lib/Kconfig b/lib/Kconfig
> > index cc04124ed8f7..9fe8a21fd183 100644
> > --- a/lib/Kconfig
> > +++ b/lib/Kconfig
> > @@ -555,8 +555,7 @@ config SIGNATURE
> > Implementation is done using GnuPG MPI library
> >
> > config DIMLIB
> > - bool "DIM library"
> > - default y
> > + bool
> > help
> > Dynamic Interrupt Moderation library.
> > Implements an algorithm for dynamically change CQ moderation
> values
> >
> There's a pending series using DIM which didn't add the select clause
> [1]. Arthur, FYI. Other than that LGTM.
>
> [1] https://www.mail-archive.com/netdev@vger.kernel.org/msg314304.html
Thanks Tal, I missed that.
^ permalink raw reply
* RE: [PATCH V2 0/8] mdev based hardware virtio offloading support
From: Tian, Kevin @ 2019-09-25 8:24 UTC (permalink / raw)
To: Jason Wang, kvm@vger.kernel.org, linux-s390@vger.kernel.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org,
intel-gvt-dev@lists.freedesktop.org, kwankhede@nvidia.com,
alex.williamson@redhat.com, mst@redhat.com, Bie, Tiwei
Cc: virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
cohuck@redhat.com, maxime.coquelin@redhat.com, Liang, Cunming,
Wang, Zhihong, rob.miller@broadcom.com, Wang, Xiao W,
haotian.wang@sifive.com, zhenyuw@linux.intel.com, Wang, Zhi A,
jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
Vivi, Rodrigo, airlied@linux.ie, daniel@ffwll.ch,
farman@linux.ibm.com, pasic@linux.ibm.com, sebott@linux.ibm.com,
oberpar@linux.ibm.com, heiko.carstens@de.ibm.com,
gor@linux.ibm.com, borntraeger@de.ibm.com, akrowiak@linux.ibm.com,
freude@linux.ibm.com, Zhu, Lingshan, idos@mellanox.com,
eperezma@redhat.com, lulu@redhat.com, parav@mellanox.com,
christophe.de.dinechin@gmail.com
In-Reply-To: <20190924135332.14160-1-jasowang@redhat.com>
> From: Jason Wang [mailto:jasowang@redhat.com]
> Sent: Tuesday, September 24, 2019 9:53 PM
>
> Hi all:
>
> There are hardware that can do virtio datapath offloading while having
> its own control path. This path tries to implement a mdev based
> unified API to support using kernel virtio driver to drive those
> devices. This is done by introducing a new mdev transport for virtio
> (virtio_mdev) and register itself as a new kind of mdev driver. Then
> it provides a unified way for kernel virtio driver to talk with mdev
> device implementation.
>
> Though the series only contains kernel driver support, the goal is to
> make the transport generic enough to support userspace drivers. This
> means vhost-mdev[1] could be built on top as well by resuing the
> transport.
>
> A sample driver is also implemented which simulate a virito-net
> loopback ethernet device on top of vringh + workqueue. This could be
> used as a reference implementation for real hardware driver.
>
> Consider mdev framework only support VFIO device and driver right now,
> this series also extend it to support other types. This is done
> through introducing class id to the device and pairing it with
> id_talbe claimed by the driver. On top, this seris also decouple
id_table claimed ... this series ...
> device specific parents ops out of the common ones.
>
> Pktgen test was done with virito-net + mvnet loop back device.
>
> Please review.
>
> [1] https://lkml.org/lkml/2019/9/16/869
>
> Changes from V1:
>
> - move virtio_mdev.c to drivers/virtio
> - store class_id in mdev_device instead of mdev_parent
> - store device_ops in mdev_device instead of mdev_parent
> - reorder the patch, vringh fix comes first
> - really silent compiling warnings
> - really switch to use u16 for class_id
> - uevent and modpost support for mdev class_id
> - vraious tweaks per comments from Parav
>
> Changes from RFC-V2:
>
> - silent compile warnings on some specific configuration
> - use u16 instead u8 for class id
> - reseve MDEV_ID_VHOST for future vhost-mdev work
> - introduce "virtio" type for mvnet and make "vhost" type for future
> work
> - add entries in MAINTAINER
> - tweak and typos fixes in commit log
>
> Changes from RFC-V1:
>
> - rename device id to class id
> - add docs for class id and device specific ops (device_ops)
> - split device_ops into seperate headers
> - drop the mdev_set_dma_ops()
> - use device_ops to implement the transport API, then it's not a part
> of UAPI any more
> - use GFP_ATOMIC in mvnet sample device and other tweaks
> - set_vring_base/get_vring_base support for mvnet device
>
> Jason Wang (8):
> vringh: fix copy direction of vringh_iov_push_kern()
> mdev: class id support
> mdev: bus uevent support
> modpost: add support for mdev class id
> mdev: introduce device specific ops
> mdev: introduce virtio device and its device ops
> virtio: introduce a mdev based transport
> docs: sample driver to demonstrate how to implement virtio-mdev
> framework
>
> .../driver-api/vfio-mediated-device.rst | 7 +-
> MAINTAINERS | 2 +
> drivers/gpu/drm/i915/gvt/kvmgt.c | 18 +-
> drivers/s390/cio/vfio_ccw_ops.c | 18 +-
> drivers/s390/crypto/vfio_ap_ops.c | 14 +-
> drivers/vfio/mdev/mdev_core.c | 19 +
> drivers/vfio/mdev/mdev_driver.c | 22 +
> drivers/vfio/mdev/mdev_private.h | 2 +
> drivers/vfio/mdev/vfio_mdev.c | 45 +-
> drivers/vhost/vringh.c | 8 +-
> drivers/virtio/Kconfig | 7 +
> drivers/virtio/Makefile | 1 +
> drivers/virtio/virtio_mdev.c | 417 +++++++++++
> include/linux/mdev.h | 52 +-
> include/linux/mod_devicetable.h | 8 +
> include/linux/vfio_mdev.h | 52 ++
> include/linux/virtio_mdev.h | 145 ++++
> samples/Kconfig | 7 +
> samples/vfio-mdev/Makefile | 1 +
> samples/vfio-mdev/mbochs.c | 20 +-
> samples/vfio-mdev/mdpy.c | 20 +-
> samples/vfio-mdev/mtty.c | 18 +-
> samples/vfio-mdev/mvnet.c | 692 ++++++++++++++++++
> scripts/mod/devicetable-offsets.c | 3 +
> scripts/mod/file2alias.c | 10 +
> 25 files changed, 1524 insertions(+), 84 deletions(-)
> create mode 100644 drivers/virtio/virtio_mdev.c
> create mode 100644 include/linux/vfio_mdev.h
> create mode 100644 include/linux/virtio_mdev.h
> create mode 100644 samples/vfio-mdev/mvnet.c
>
> --
> 2.19.1
^ permalink raw reply
* RE: [PATCH V2 2/8] mdev: class id support
From: Tian, Kevin @ 2019-09-25 8:28 UTC (permalink / raw)
To: Jason Wang, kvm@vger.kernel.org, linux-s390@vger.kernel.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org,
intel-gvt-dev@lists.freedesktop.org, kwankhede@nvidia.com,
alex.williamson@redhat.com, mst@redhat.com, Bie, Tiwei
Cc: virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
cohuck@redhat.com, maxime.coquelin@redhat.com, Liang, Cunming,
Wang, Zhihong, rob.miller@broadcom.com, Wang, Xiao W,
haotian.wang@sifive.com, zhenyuw@linux.intel.com, Wang, Zhi A,
jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
Vivi, Rodrigo, airlied@linux.ie, daniel@ffwll.ch,
farman@linux.ibm.com, pasic@linux.ibm.com, sebott@linux.ibm.com,
oberpar@linux.ibm.com, heiko.carstens@de.ibm.com,
gor@linux.ibm.com, borntraeger@de.ibm.com, akrowiak@linux.ibm.com,
freude@linux.ibm.com, Zhu, Lingshan, idos@mellanox.com,
eperezma@redhat.com, lulu@redhat.com, parav@mellanox.com,
christophe.de.dinechin@gmail.com
In-Reply-To: <20190924135332.14160-3-jasowang@redhat.com>
> From: Jason Wang
> Sent: Tuesday, September 24, 2019 9:53 PM
>
> Mdev bus only supports vfio driver right now, so it doesn't implement
> match method. But in the future, we may add drivers other than vfio,
> the first driver could be virtio-mdev. This means we need to add
> device class id support in bus match method to pair the mdev device
> and mdev driver correctly.
>
> So this patch adds id_table to mdev_driver and class_id for mdev
> parent with the match method for mdev bus.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> Documentation/driver-api/vfio-mediated-device.rst | 3 +++
> drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
> drivers/s390/cio/vfio_ccw_ops.c | 1 +
> drivers/s390/crypto/vfio_ap_ops.c | 1 +
> drivers/vfio/mdev/mdev_core.c | 7 +++++++
> drivers/vfio/mdev/mdev_driver.c | 14 ++++++++++++++
> drivers/vfio/mdev/mdev_private.h | 1 +
> drivers/vfio/mdev/vfio_mdev.c | 6 ++++++
> include/linux/mdev.h | 8 ++++++++
> include/linux/mod_devicetable.h | 8 ++++++++
> samples/vfio-mdev/mbochs.c | 1 +
> samples/vfio-mdev/mdpy.c | 1 +
> samples/vfio-mdev/mtty.c | 1 +
> 13 files changed, 53 insertions(+)
>
> diff --git a/Documentation/driver-api/vfio-mediated-device.rst
> b/Documentation/driver-api/vfio-mediated-device.rst
> index 25eb7d5b834b..a5bdc60d62a1 100644
> --- a/Documentation/driver-api/vfio-mediated-device.rst
> +++ b/Documentation/driver-api/vfio-mediated-device.rst
> @@ -102,12 +102,14 @@ structure to represent a mediated device's
> driver::
> * @probe: called when new device created
> * @remove: called when device removed
> * @driver: device driver structure
> + * @id_table: the ids serviced by this driver
> */
> struct mdev_driver {
> const char *name;
> int (*probe) (struct device *dev);
> void (*remove) (struct device *dev);
> struct device_driver driver;
> + const struct mdev_class_id *id_table;
> };
>
> A mediated bus driver for mdev should use this structure in the function
> calls
> @@ -165,6 +167,7 @@ register itself with the mdev core driver::
> extern int mdev_register_device(struct device *dev,
> const struct mdev_parent_ops *ops);
>
> +
> However, the mdev_parent_ops structure is not required in the function
> call
> that a driver should use to unregister itself with the mdev core driver::
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 23aa3e50cbf8..f793252a3d2a 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -678,6 +678,7 @@ static int intel_vgpu_create(struct kobject *kobj,
> struct mdev_device *mdev)
> dev_name(mdev_dev(mdev)));
> ret = 0;
>
> + mdev_set_class_id(mdev, MDEV_ID_VFIO);
> out:
> return ret;
> }
> diff --git a/drivers/s390/cio/vfio_ccw_ops.c
> b/drivers/s390/cio/vfio_ccw_ops.c
> index f0d71ab77c50..d258ef1fedb9 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -129,6 +129,7 @@ static int vfio_ccw_mdev_create(struct kobject
> *kobj, struct mdev_device *mdev)
> private->sch->schid.ssid,
> private->sch->schid.sch_no);
>
> + mdev_set_class_id(mdev, MDEV_ID_VFIO);
> return 0;
> }
>
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_ops.c
> index 5c0f53c6dde7..2cfd96112aa0 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -343,6 +343,7 @@ static int vfio_ap_mdev_create(struct kobject *kobj,
> struct mdev_device *mdev)
> list_add(&matrix_mdev->node, &matrix_dev->mdev_list);
> mutex_unlock(&matrix_dev->lock);
>
> + mdev_set_class_id(mdev, MDEV_ID_VFIO);
> return 0;
> }
>
> diff --git a/drivers/vfio/mdev/mdev_core.c
> b/drivers/vfio/mdev/mdev_core.c
> index b558d4cfd082..8764cf4a276d 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -45,6 +45,12 @@ void mdev_set_drvdata(struct mdev_device *mdev,
> void *data)
> }
> EXPORT_SYMBOL(mdev_set_drvdata);
>
> +void mdev_set_class_id(struct mdev_device *mdev, u16 id)
> +{
> + mdev->class_id = id;
> +}
> +EXPORT_SYMBOL(mdev_set_class_id);
> +
> struct device *mdev_dev(struct mdev_device *mdev)
> {
> return &mdev->dev;
> @@ -135,6 +141,7 @@ static int mdev_device_remove_cb(struct device
> *dev, void *data)
> * mdev_register_device : Register a device
> * @dev: device structure representing parent device.
> * @ops: Parent device operation structure to be registered.
> + * @id: device id.
class id.
> *
> * Add device to list of registered parent devices.
> * Returns a negative value on error, otherwise 0.
> diff --git a/drivers/vfio/mdev/mdev_driver.c
> b/drivers/vfio/mdev/mdev_driver.c
> index 0d3223aee20b..b7c40ce86ee3 100644
> --- a/drivers/vfio/mdev/mdev_driver.c
> +++ b/drivers/vfio/mdev/mdev_driver.c
> @@ -69,8 +69,22 @@ static int mdev_remove(struct device *dev)
> return 0;
> }
>
> +static int mdev_match(struct device *dev, struct device_driver *drv)
> +{
> + unsigned int i;
> + struct mdev_device *mdev = to_mdev_device(dev);
> + struct mdev_driver *mdrv = to_mdev_driver(drv);
> + const struct mdev_class_id *ids = mdrv->id_table;
> +
> + for (i = 0; ids[i].id; i++)
> + if (ids[i].id == mdev->class_id)
> + return 1;
> + return 0;
> +}
> +
> struct bus_type mdev_bus_type = {
> .name = "mdev",
> + .match = mdev_match,
> .probe = mdev_probe,
> .remove = mdev_remove,
> };
> diff --git a/drivers/vfio/mdev/mdev_private.h
> b/drivers/vfio/mdev/mdev_private.h
> index 7d922950caaf..c65f436c1869 100644
> --- a/drivers/vfio/mdev/mdev_private.h
> +++ b/drivers/vfio/mdev/mdev_private.h
> @@ -33,6 +33,7 @@ struct mdev_device {
> struct kobject *type_kobj;
> struct device *iommu_device;
> bool active;
> + u16 class_id;
> };
>
> #define to_mdev_device(dev) container_of(dev, struct mdev_device, dev)
> diff --git a/drivers/vfio/mdev/vfio_mdev.c
> b/drivers/vfio/mdev/vfio_mdev.c
> index 30964a4e0a28..fd2a4d9a3f26 100644
> --- a/drivers/vfio/mdev/vfio_mdev.c
> +++ b/drivers/vfio/mdev/vfio_mdev.c
> @@ -120,10 +120,16 @@ static void vfio_mdev_remove(struct device *dev)
> vfio_del_group_dev(dev);
> }
>
> +static struct mdev_class_id id_table[] = {
> + { MDEV_ID_VFIO },
> + { 0 },
> +};
> +
> static struct mdev_driver vfio_mdev_driver = {
> .name = "vfio_mdev",
> .probe = vfio_mdev_probe,
> .remove = vfio_mdev_remove,
> + .id_table = id_table,
> };
>
> static int __init vfio_mdev_init(void)
> diff --git a/include/linux/mdev.h b/include/linux/mdev.h
> index 0ce30ca78db0..3974650c074f 100644
> --- a/include/linux/mdev.h
> +++ b/include/linux/mdev.h
> @@ -118,6 +118,7 @@ struct mdev_type_attribute
> mdev_type_attr_##_name = \
> * @probe: called when new device created
> * @remove: called when device removed
> * @driver: device driver structure
> + * @id_table: the ids serviced by this driver.
> *
> **/
> struct mdev_driver {
> @@ -125,12 +126,14 @@ struct mdev_driver {
> int (*probe)(struct device *dev);
> void (*remove)(struct device *dev);
> struct device_driver driver;
> + const struct mdev_class_id *id_table;
> };
>
> #define to_mdev_driver(drv) container_of(drv, struct mdev_driver, driver)
>
> void *mdev_get_drvdata(struct mdev_device *mdev);
> void mdev_set_drvdata(struct mdev_device *mdev, void *data);
> +void mdev_set_class_id(struct mdev_device *mdev, u16 id);
> const guid_t *mdev_uuid(struct mdev_device *mdev);
>
> extern struct bus_type mdev_bus_type;
> @@ -145,4 +148,9 @@ struct device *mdev_parent_dev(struct
> mdev_device *mdev);
> struct device *mdev_dev(struct mdev_device *mdev);
> struct mdev_device *mdev_from_dev(struct device *dev);
>
> +enum {
> + MDEV_ID_VFIO = 1,
> + /* New entries must be added here */
> +};
> +
> #endif /* MDEV_H */
> diff --git a/include/linux/mod_devicetable.h
> b/include/linux/mod_devicetable.h
> index 5714fd35a83c..f32c6e44fb1a 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -821,4 +821,12 @@ struct wmi_device_id {
> const void *context;
> };
>
> +/**
> + * struct mdev_class_id - MDEV device class identifier
> + * @id: Used to identify a specific class of device, e.g vfio-mdev device.
> + */
> +struct mdev_class_id {
> + __u16 id;
> +};
> +
> #endif /* LINUX_MOD_DEVICETABLE_H */
> diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
> index ac5c8c17b1ff..8a8583c892b2 100644
> --- a/samples/vfio-mdev/mbochs.c
> +++ b/samples/vfio-mdev/mbochs.c
> @@ -561,6 +561,7 @@ static int mbochs_create(struct kobject *kobj, struct
> mdev_device *mdev)
> mbochs_reset(mdev);
>
> mbochs_used_mbytes += type->mbytes;
> + mdev_set_class_id(mdev, MDEV_ID_VFIO);
> return 0;
>
> err_mem:
> diff --git a/samples/vfio-mdev/mdpy.c b/samples/vfio-mdev/mdpy.c
> index cc86bf6566e4..88d7e76f3836 100644
> --- a/samples/vfio-mdev/mdpy.c
> +++ b/samples/vfio-mdev/mdpy.c
> @@ -269,6 +269,7 @@ static int mdpy_create(struct kobject *kobj, struct
> mdev_device *mdev)
> mdpy_reset(mdev);
>
> mdpy_count++;
> + mdev_set_class_id(mdev, MDEV_ID_VFIO);
> return 0;
> }
>
> diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
> index 92e770a06ea2..4e0735143b69 100644
> --- a/samples/vfio-mdev/mtty.c
> +++ b/samples/vfio-mdev/mtty.c
> @@ -770,6 +770,7 @@ static int mtty_create(struct kobject *kobj, struct
> mdev_device *mdev)
> list_add(&mdev_state->next, &mdev_devices_list);
> mutex_unlock(&mdev_list_lock);
>
> + mdev_set_class_id(mdev, MDEV_ID_VFIO);
> return 0;
> }
>
> --
> 2.19.1
^ permalink raw reply
* WireGuard to port to existing Crypto API
From: Jason A. Donenfeld @ 2019-09-25 8:29 UTC (permalink / raw)
To: WireGuard mailing list, Netdev, LKML
Hi folks,
I'm at the Kernel Recipes conference now and got a chance to talk with
DaveM a bit about WireGuard upstreaming. His viewpoint has recently
solidified: in order to go upstream, WireGuard must port to the
existing crypto API, and handle the Zinc project separately. As DaveM
is the upstream network tree maintainer, his opinion is quite
instructive.
I've long resisted the idea of porting to the existing crypto API,
because I think there are serious problems with it, in terms of
primitives, API, performance, and overall safety. I didn't want to
ship WireGuard in a form that I thought was sub-optimal from a
security perspective, since WireGuard is a security-focused project.
But it seems like with or without us, WireGuard will get ported to the
existing crypto API. So it's probably better that we just fully
embrace it, and afterwards work evolutionarily to get Zinc into Linux
piecemeal. I've ported WireGuard already several times as a PoC to the
API and have a decent idea of the ways it can go wrong and generally
how to do it in the least-bad way.
I realize this kind of compromise might come as a disappointment for
some folks. But it's probably better that as a project we remain
intimately involved with our Linux kernel users and the security of
the implementation, rather than slinking away in protest because we
couldn't get it all in at once. So we'll work with upstream, port to
the crypto API, and get the process moving again. We'll pick up the
Zinc work after that's done.
I also understand there might be interested folks out there who enjoy
working with the crypto API quite a bit and would be happy to work on
the WireGuard port. Please do get in touch if you'd like to
collaborate.
Jason
^ permalink raw reply
* TCP_USER_TIMEOUT, SYN-SENT and tcp_syn_retries
From: Marek Majkowski @ 2019-09-25 8:46 UTC (permalink / raw)
To: netdev
Hello my favorite mailing list!
Recently I've been looking into TCP_USER_TIMEOUT and noticed some
strange behaviour on fresh sockets in SYN-SENT state. Full writeup:
https://blog.cloudflare.com/when-tcp-sockets-refuse-to-die/
Here's a reproducer. It does a simple thing: sets TCP_USER_TIMEOUT and
does connect() to a blackholed IP:
$ wget https://gist.githubusercontent.com/majek/b4ad53c5795b226d62fad1fa4a87151a/raw/cbb928cb99cd6c5aa9f73ba2d3bc0aef22fbc2bf/user-timeout-and-syn.py
$ sudo python3 user-timeout-and-syn.py
00:00.000000 IP 192.1.1.1.52974 > 244.0.0.1.1234: Flags [S]
00:01.007053 IP 192.1.1.1.52974 > 244.0.0.1.1234: Flags [S]
00:03.023051 IP 192.1.1.1.52974 > 244.0.0.1.1234: Flags [S]
00:05.007096 IP 192.1.1.1.52974 > 244.0.0.1.1234: Flags [S]
00:05.015037 IP 192.1.1.1.52974 > 244.0.0.1.1234: Flags [S]
00:05.023020 IP 192.1.1.1.52974 > 244.0.0.1.1234: Flags [S]
00:05.034983 IP 192.1.1.1.52974 > 244.0.0.1.1234: Flags [S]
The connect() times out with ETIMEDOUT after 5 seconds - as intended.
But Linux (5.3.0-rc3) does something weird on the network - it sends
remaining tcp_syn_retries packets aligned to the 5s mark.
In other words: with TCP_USER_TIMEOUT we are sending spurious SYN
packets on a timeout.
For the record, the man page doesn't define what TCP_USER_TIMEOUT does
on SYN-SENT state.
Cheers,
Marek
^ permalink raw reply
* Re: Linux 5.4 - bpf test build fails
From: Cristian Marussi @ 2019-09-25 8:52 UTC (permalink / raw)
To: Shuah Khan, Tim.Bird, alexei.starovoitov, daniel
Cc: linux-kselftest, bpf, netdev, davem
In-Reply-To: <d4c916ec-14a5-1076-7b84-3ca42026dd19@linuxfoundation.org>
Hi Shuah, Tim
On 9/24/19 7:23 PM, Shuah Khan wrote:
> On 9/24/19 12:07 PM, Tim.Bird@sony.com wrote:
>>
>>
>>> -----Original Message-----
>>> From: Cristian Marussi on Tuesday, September 24, 2019 7:30 AM
>>>
>>> Hi Shuah
>>>
>>> On 24/09/2019 17:39, Shuah Khan wrote:
>>>> On 9/24/19 10:03 AM, Shuah Khan wrote:
>>>>> On 9/24/19 9:52 AM, Cristian Marussi wrote:
>>>>>> Hi Shuah
>>>>>>
>>>>>> On 24/09/2019 16:26, Shuah Khan wrote:
>>>>>>> Hi Alexei and Daniel,
>>>>>>>
>>>>>>> bpf test doesn't build on Linux 5.4 mainline. Do you know what's
>>>>>>> happening here.
>>>>>>>
>>>>>>>
>>>>>>> make -C tools/testing/selftests/bpf/
>>>>>>
>>>>>> side question, since I'm writing arm64/ tests.
>>>>>>
>>>>>> my "build-testcases" following the KSFT docs are:
>>>>>>
>>>>>> make kselftest
>>>>>> make TARGETS=arm64 kselftest
>>>>>> make -C tools/testing/selftests/
>>>>>> make -C tools/testing/selftests/ INSTALL_PATH=<install-path> install
>>>>>> make TARGETS=arm64 -C tools/testing/selftests/
>>>>>> make TARGETS=arm64 -C tools/testing/selftests/
>>>>>> INSTALL_PATH=<install-path> install
>>>>>> ./kselftest_install.sh <install-path>
>>>>
>>>> Cristian,
>>>>
>>>> That being said, I definitely want to see this list limited to
>>>> a few options.
>>>>
>>>> One problem is that if somebody wants to do just a build, there
>>>> is no option from the main makefile. I have sent support for that
>>>> a few months ago and the patch didn't got lost it appears. I am
>>>> working on resending those patches. The same is true for install.
>>>> I sent in a patch for that a while back and I am going to resend.
>>>> These will make it easier for users.
>>>>
>>>> I would really want to get to supporting only these options:
>>>>
>>>> These are supported now:
>>>>
>>>> make kselftest
>>>> make TARGETS=arm64 kselftest (one or more targets)
>>>>
>>>> Replace the following:
>>>>
>>>> make -C tools/testing/selftests/ with
>>>>
>>>> make kselftes_build option from main makefile
>>>>
>>>> Replace this:
>>>> make -C tools/testing/selftests/ INSTALL_PATH=<install-path> install
>>>>
>>>> with
>>>> make kselftest_install
>>>
>>> Yes these top level options would be absolutely useful to avoid multiplication
>>> of build targets to support and test.
>>>
>>> Moreover, currently, since there was a lot of test growing into arm64/
>>> inside subdirs like arm64/signal, I support (still under review in fact) in the
>>> arm64/
>>> toplevel makefile the possibility of building/installing by subdirs only, in order
>>> to be able to limit what you want to build/install of a TARGET (resulting in
>>> quicker devel),
>>> issuing something like:
>>>
>>> make TARGETS=arm64 SUBTARGETS=signal -C tools/testing/selftests/
>>>
>>> if possible, that would be useful if kept functional even in the
>>> new schema. I mean being able to still issue:
>>>
>>> make TARGETS=arm64 SUBTARGETS=signal kselftes_build
>>
>> From a user perspective, instead of adding a new SUBTARGETS variable,
>> I would prefer something like the following:
>>
>> make TARGET=arm64/signal kselftest_build
>>
>> If you just add a single flat subsidiary namespace, then it doesn't support further
>> increasing the directory depth in the future.
>>
>
> TARGETS is make variable. Adding sub-targets might not be easy without
> cluttering the selftests main Makefile. I will have to look into it.
>
I was NOT proposing in fact to introduce handling of SUBTARGETS at the toplevel kselftest
Makefile, just not to kill the possibility for interested subsystems to handle it as they
wish in their own toplevel subsystem Makefile like in arm64/Makefile in:
https://lore.kernel.org/linux-kselftest/20190910123111.33478-2-cristian.marussi@arm.com/
(probably better renaming SUBTARGETS->ARM64_SUBTARGETS in the next v7 to avoid name clashing)
Because it's painful from the development perspective not having the possibility to selectively
build/install only a subset/subdir of the chosen TARGETS; but it's a very subsystem specific issue
and not everybody need it, so I'd let the respective TARGETS subsystems handle it if they want/need.
Thanks
Cristian
> thanks,
> -- Shuah
>
^ permalink raw reply
* Re: WireGuard to port to existing Crypto API
From: Toke Høiland-Jørgensen @ 2019-09-25 8:46 UTC (permalink / raw)
To: Jason A. Donenfeld, WireGuard mailing list, Netdev, LKML
In-Reply-To: <CAHmME9pmfZAp5zd9BDLFc2fWUhtzZcjYZc2atTPTyNFFmEdHLg@mail.gmail.com>
"Jason A. Donenfeld" <Jason@zx2c4.com> writes:
> Hi folks,
>
> I'm at the Kernel Recipes conference now and got a chance to talk with
> DaveM a bit about WireGuard upstreaming. His viewpoint has recently
> solidified: in order to go upstream, WireGuard must port to the
> existing crypto API, and handle the Zinc project separately. As DaveM
> is the upstream network tree maintainer, his opinion is quite
> instructive.
>
> I've long resisted the idea of porting to the existing crypto API,
> because I think there are serious problems with it, in terms of
> primitives, API, performance, and overall safety. I didn't want to
> ship WireGuard in a form that I thought was sub-optimal from a
> security perspective, since WireGuard is a security-focused project.
>
> But it seems like with or without us, WireGuard will get ported to the
> existing crypto API. So it's probably better that we just fully
> embrace it, and afterwards work evolutionarily to get Zinc into Linux
> piecemeal. I've ported WireGuard already several times as a PoC to the
> API and have a decent idea of the ways it can go wrong and generally
> how to do it in the least-bad way.
>
> I realize this kind of compromise might come as a disappointment for
> some folks. But it's probably better that as a project we remain
> intimately involved with our Linux kernel users and the security of
> the implementation, rather than slinking away in protest because we
> couldn't get it all in at once. So we'll work with upstream, port to
> the crypto API, and get the process moving again. We'll pick up the
> Zinc work after that's done.
On the contrary, kudos on taking the pragmatic route! Much as I have
enjoyed watching your efforts on Zinc, I always thought it was a shame
it had to hold back the upstreaming of WireGuard. So as far as I'm
concerned, doing that separately sounds like the right approach at this
point, and I'll look forward to seeing the patches land :)
-Toke
^ permalink raw reply
* [PATCH] can: peakcan: report bus recovery as well
From: Jeroen Hofstee @ 2019-09-25 8:58 UTC (permalink / raw)
To: linux-can@vger.kernel.org
Cc: Jeroen Hofstee, Stephane Grosjean, Wolfgang Grandegger,
Marc Kleine-Budde, David S. Miller, Gustavo A. R. Silva,
Nicolas Ferre, Greg Kroah-Hartman, Thomas Gleixner,
open list:NETWORKING DRIVERS, open list
While the state changes are reported when the error counters increase
and decrease, there is no event when the bus recovers and the error
counters decrease again. So add those as well.
Change the state going downward to be ERROR_PASSIVE -> ERROR_WARNING ->
ERROR_ACTIVE instead of directly to ERROR_ACTIVE again.
Signed-off-by: Jeroen Hofstee <jhofstee@victronenergy.com>
Cc: Stephane Grosjean <s.grosjean@peak-system.com>
---
drivers/net/can/usb/peak_usb/pcan_usb.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb.c b/drivers/net/can/usb/peak_usb/pcan_usb.c
index 617da295b6c1..dd2a7f529012 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb.c
@@ -436,8 +436,8 @@ static int pcan_usb_decode_error(struct pcan_usb_msg_context *mc, u8 n,
}
if ((n & PCAN_USB_ERROR_BUS_LIGHT) == 0) {
/* no error (back to active state) */
- mc->pdev->dev.can.state = CAN_STATE_ERROR_ACTIVE;
- return 0;
+ new_state = CAN_STATE_ERROR_ACTIVE;
+ break;
}
break;
@@ -460,9 +460,9 @@ static int pcan_usb_decode_error(struct pcan_usb_msg_context *mc, u8 n,
}
if ((n & PCAN_USB_ERROR_BUS_HEAVY) == 0) {
- /* no error (back to active state) */
- mc->pdev->dev.can.state = CAN_STATE_ERROR_ACTIVE;
- return 0;
+ /* no error (back to warning state) */
+ new_state = CAN_STATE_ERROR_WARNING;
+ break;
}
break;
@@ -501,6 +501,11 @@ static int pcan_usb_decode_error(struct pcan_usb_msg_context *mc, u8 n,
mc->pdev->dev.can.can_stats.error_warning++;
break;
+ case CAN_STATE_ERROR_ACTIVE:
+ cf->can_id |= CAN_ERR_CRTL;
+ cf->data[1] = CAN_ERR_CRTL_ACTIVE;
+ break;
+
default:
/* CAN_STATE_MAX (trick to handle other errors) */
cf->can_id |= CAN_ERR_CRTL;
--
2.17.1
^ permalink raw reply related
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