* Re: [PATCH 09/18] net: mac80211.h: fix a bad comment line
From: Johannes Berg @ 2018-05-09 12:04 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Kalle Valo, Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel, Jonathan Corbet, David S. Miller, linux-wireless,
netdev
In-Reply-To: <20180509090400.0156c0c8@vento.lan>
On Wed, 2018-05-09 at 09:04 -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 07 May 2018 14:38:26 +0200
> Johannes Berg <johannes@sipsolutions.net> escreveu:
>
> > On Mon, 2018-05-07 at 15:37 +0300, Kalle Valo wrote:
> > > Mauro Carvalho Chehab <mchehab+samsung@kernel.org> writes:
> > >
> > > > Sphinx produces a lot of errors like this:
> > > > ./include/net/mac80211.h:2083: warning: bad line: >
> > > >
> > > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > >
> > > Randy already submitted a similar patch:
> > >
> > > https://patchwork.kernel.org/patch/10367275/
> > >
> > > But it seems Johannes has not applied that yet.
> >
> > Yeah, I've been super busy preparing for the plugfest.
> >
> > I'll make a pass over all the patches as soon as I can, hopefully today
> > or tomorrow.
>
> Thanks. I'll drop it from my patchset, assuming that you'll
> be applying Randy's version or mine via your tree.
Right, I did, just need to send a pull request.
johannes
^ permalink raw reply
* Re: [PATCH 09/18] net: mac80211.h: fix a bad comment line
From: Mauro Carvalho Chehab @ 2018-05-09 12:04 UTC (permalink / raw)
To: Johannes Berg
Cc: Kalle Valo, Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel, Jonathan Corbet, David S. Miller, linux-wireless,
netdev
In-Reply-To: <1525696706.6049.7.camel@sipsolutions.net>
Em Mon, 07 May 2018 14:38:26 +0200
Johannes Berg <johannes@sipsolutions.net> escreveu:
> On Mon, 2018-05-07 at 15:37 +0300, Kalle Valo wrote:
> > Mauro Carvalho Chehab <mchehab+samsung@kernel.org> writes:
> >
> > > Sphinx produces a lot of errors like this:
> > > ./include/net/mac80211.h:2083: warning: bad line: >
> > >
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> >
> > Randy already submitted a similar patch:
> >
> > https://patchwork.kernel.org/patch/10367275/
> >
> > But it seems Johannes has not applied that yet.
>
> Yeah, I've been super busy preparing for the plugfest.
>
> I'll make a pass over all the patches as soon as I can, hopefully today
> or tomorrow.
Thanks. I'll drop it from my patchset, assuming that you'll
be applying Randy's version or mine via your tree.
Thanks,
Mauro
^ permalink raw reply
* [PATCH ethtool] ethtool: fix stack clash in do_get_phy_tunable and do_set_phy_tunable
From: Michal Kubecek @ 2018-05-09 12:01 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, Raju Lakkaraju, Allan W. Nielsen
Users reported stack clash detected when using --get-phy-tunable on
ppc64le. Problem is caused by local variable ds of type struct
ethtool_tunable which has last member "void *data[0]". Accessing data[0]
(as do_get_phy_tunable() does) or adding requested value at the end (which
is what kernel ioctl does) writes past allocated space for the variable.
Make ds part of an anonymous structure to make sure there is enough space
for tunable value and drop the (pointless) access to ds.data[0]. The same
problem also exists in do_set_phy_tunable().
Fixes: b0fe96dec90f ("Ethtool: Implements ETHTOOL_PHY_GTUNABLE/ETHTOOL_PHY_STUNABLE and PHY downshift")
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
ethtool.c | 39 +++++++++++++++++++++------------------
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index 3289e0f6e8ec..2e873848eb4e 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -4740,20 +4740,22 @@ static int do_get_phy_tunable(struct cmd_context *ctx)
}
if (downshift_changed) {
- struct ethtool_tunable ds;
+ struct {
+ struct ethtool_tunable ds;
+ u8 __count;
+ } cont;
u8 count = 0;
- ds.cmd = ETHTOOL_PHY_GTUNABLE;
- ds.id = ETHTOOL_PHY_DOWNSHIFT;
- ds.type_id = ETHTOOL_TUNABLE_U8;
- ds.len = 1;
- ds.data[0] = &count;
- err = send_ioctl(ctx, &ds);
+ cont.ds.cmd = ETHTOOL_PHY_GTUNABLE;
+ cont.ds.id = ETHTOOL_PHY_DOWNSHIFT;
+ cont.ds.type_id = ETHTOOL_TUNABLE_U8;
+ cont.ds.len = 1;
+ err = send_ioctl(ctx, &cont.ds);
if (err < 0) {
perror("Cannot Get PHY downshift count");
return 87;
}
- count = *((u8 *)&ds.data[0]);
+ count = *((u8 *)&cont.ds.data[0]);
if (count)
fprintf(stdout, "Downshift count: %d\n", count);
else
@@ -4931,16 +4933,17 @@ static int do_set_phy_tunable(struct cmd_context *ctx)
/* Do it */
if (ds_changed) {
- struct ethtool_tunable ds;
- u8 count;
-
- ds.cmd = ETHTOOL_PHY_STUNABLE;
- ds.id = ETHTOOL_PHY_DOWNSHIFT;
- ds.type_id = ETHTOOL_TUNABLE_U8;
- ds.len = 1;
- ds.data[0] = &count;
- *((u8 *)&ds.data[0]) = ds_cnt;
- err = send_ioctl(ctx, &ds);
+ struct {
+ struct ethtool_tunable ds;
+ u8 __count;
+ } cont;
+
+ cont.ds.cmd = ETHTOOL_PHY_STUNABLE;
+ cont.ds.id = ETHTOOL_PHY_DOWNSHIFT;
+ cont.ds.type_id = ETHTOOL_TUNABLE_U8;
+ cont.ds.len = 1;
+ *((u8 *)&cont.ds.data[0]) = ds_cnt;
+ err = send_ioctl(ctx, &cont.ds);
if (err < 0) {
perror("Cannot Set PHY downshift count");
err = 87;
--
2.16.3
^ permalink raw reply related
* Re: [PATCH net-next] net: dsa: fix added_by_user switchdev notification
From: Nikolay Aleksandrov @ 2018-05-09 11:32 UTC (permalink / raw)
To: Vivien Didelot, netdev
Cc: linux-kernel, kernel, Petr Machata, jiri, idosch, ivecera, davem,
stephen, andrew, f.fainelli, bridge
In-Reply-To: <20180509030312.29548-1-vivien.didelot@savoirfairelinux.com>
On 09/05/18 06:03, Vivien Didelot wrote:
> Commit 161d82de1ff8 ("net: bridge: Notify about !added_by_user FDB
> entries") causes the below oops when bringing up a slave interface,
> because dsa_port_fdb_add is still scheduled, but with a NULL address.
>
> To fix this, keep the dsa_slave_switchdev_event function agnostic of the
> notified info structure and handle the added_by_user flag in the
> specific dsa_slave_switchdev_event_work function.
>
> [ 75.512263] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [ 75.519063] pgd = (ptrval)
> [ 75.520545] [00000000] *pgd=00000000
> [ 75.522839] Internal error: Oops: 17 [#1] ARM
> [ 75.525898] Modules linked in:
> [ 75.527673] CPU: 0 PID: 9 Comm: kworker/u2:1 Not tainted 4.17.0-rc2 #78
> [ 75.532988] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
> [ 75.538153] Workqueue: dsa_ordered dsa_slave_switchdev_event_work
> [ 75.542970] PC is at mv88e6xxx_port_db_load_purge+0x60/0x1b0
> [ 75.547341] LR is at mdiobus_read_nested+0x6c/0x78
> [ 75.550833] pc : [<804cd5c0>] lr : [<804bba84>] psr: 60070013
> [ 75.555796] sp : 9f54bd78 ip : 9f54bd87 fp : 9f54bddc
> [ 75.559719] r10: 00000000 r9 : 0000000e r8 : 9f6a6010
> [ 75.563643] r7 : 00000000 r6 : 81203048 r5 : 9f6a6010 r4 : 9f6a601c
> [ 75.568867] r3 : 00000000 r2 : 00000000 r1 : 0000000d r0 : 00000000
> [ 75.574094] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> [ 75.579933] Control: 10c53c7d Table: 9de20059 DAC: 00000051
> [ 75.584384] Process kworker/u2:1 (pid: 9, stack limit = 0x(ptrval))
> [ 75.589349] Stack: (0x9f54bd78 to 0x9f54c000)
> [ 75.592406] bd60: 00000000 00000000
> [ 75.599295] bd80: 00000391 9f299d10 9f299d68 8014317c 9f7f0000 8120af00 00006dc2 00000000
> [ 75.606186] bda0: 8120af00 00000000 9f54bdec 1c9f5d92 8014317c 9f6a601c 9f6a6010 00000000
> [ 75.613076] bdc0: 00000000 00000000 9dd1141c 8125a0b4 9f54be0c 9f54bde0 804cd8a8 804cd56c
> [ 75.619966] bde0: 0000000e 80143680 00000001 9dce9c1c 81203048 9dce9c10 00000003 00000000
> [ 75.626858] be00: 9f54be5c 9f54be10 806abcac 804cd864 9f54be54 80143664 8014317c 80143054
> [ 75.633748] be20: ffcaa81d 00000000 812030b0 1c9f5d92 00000000 81203048 9f54beb4 00000003
> [ 75.640639] be40: ffffffff 00000000 9dd1141c 8125a0b4 9f54be84 9f54be60 80138e98 806abb18
> [ 75.647529] be60: 81203048 9ddc4000 9dce9c54 9f72a300 00000000 00000000 9f54be9c 9f54be88
> [ 75.654420] be80: 801390bc 80138e50 00000000 9dce9c54 9f54beac 9f54bea0 806a9524 801390a0
> [ 75.661310] bea0: 9f54bedc 9f54beb0 806a9c7c 806a950c 9f54becc 00000000 00000000 00000000
> [ 75.668201] bec0: 9f540000 1c9f5d92 805fe604 9ddffc00 9f54befc 9f54bee0 806ab228 806a9c38
> [ 75.675092] bee0: 806ab178 9ddffc00 9f4c1900 9f40d200 9f54bf34 9f54bf00 80131e30 806ab184
> [ 75.681983] bf00: 9f40d214 9f54a038 9f40d200 9f40d200 9f4c1918 812119a0 9f40d214 9f54a038
> [ 75.688873] bf20: 9f40d200 9f4c1900 9f54bf7c 9f54bf38 80132124 80131d1c 9f5f2dd8 00000000
> [ 75.695764] bf40: 812119a0 9f54a038 812119a0 81259c5b 9f5f2dd8 9f5f2dc0 9f53dbc0 00000000
> [ 75.702655] bf60: 9f4c1900 801320b4 9f5f2dd8 9f4f7e88 9f54bfac 9f54bf80 80137ad0 801320c0
> [ 75.709544] bf80: 9f54a000 9f53dbc0 801379a0 00000000 00000000 00000000 00000000 00000000
> [ 75.716434] bfa0: 00000000 9f54bfb0 801010e8 801379ac 00000000 00000000 00000000 00000000
> [ 75.723324] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 75.730206] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [ 75.737083] Backtrace:
> [ 75.738252] [<804cd560>] (mv88e6xxx_port_db_load_purge) from [<804cd8a8>] (mv88e6xxx_port_fdb_add+0x50/0x68)
> [ 75.746795] r10:8125a0b4 r9:9dd1141c r8:00000000 r7:00000000 r6:00000000 r5:9f6a6010
> [ 75.753323] r4:9f6a601c
> [ 75.754570] [<804cd858>] (mv88e6xxx_port_fdb_add) from [<806abcac>] (dsa_switch_event+0x1a0/0x660)
> [ 75.762238] r8:00000000 r7:00000003 r6:9dce9c10 r5:81203048 r4:9dce9c1c
> [ 75.767655] [<806abb0c>] (dsa_switch_event) from [<80138e98>] (notifier_call_chain+0x54/0x94)
> [ 75.774893] r10:8125a0b4 r9:9dd1141c r8:00000000 r7:ffffffff r6:00000003 r5:9f54beb4
> [ 75.781423] r4:81203048
> [ 75.782672] [<80138e44>] (notifier_call_chain) from [<801390bc>] (raw_notifier_call_chain+0x28/0x30)
> [ 75.790514] r9:00000000 r8:00000000 r7:9f72a300 r6:9dce9c54 r5:9ddc4000 r4:81203048
> [ 75.796982] [<80139094>] (raw_notifier_call_chain) from [<806a9524>] (dsa_port_notify+0x24/0x38)
> [ 75.804483] [<806a9500>] (dsa_port_notify) from [<806a9c7c>] (dsa_port_fdb_add+0x50/0x6c)
> [ 75.811371] [<806a9c2c>] (dsa_port_fdb_add) from [<806ab228>] (dsa_slave_switchdev_event_work+0xb0/0x10c)
> [ 75.819635] r4:9ddffc00
> [ 75.820885] [<806ab178>] (dsa_slave_switchdev_event_work) from [<80131e30>] (process_one_work+0x120/0x3a4)
> [ 75.829241] r6:9f40d200 r5:9f4c1900 r4:9ddffc00 r3:806ab178
> [ 75.833612] [<80131d10>] (process_one_work) from [<80132124>] (worker_thread+0x70/0x574)
> [ 75.840415] r10:9f4c1900 r9:9f40d200 r8:9f54a038 r7:9f40d214 r6:812119a0 r5:9f4c1918
> [ 75.846945] r4:9f40d200
> [ 75.848191] [<801320b4>] (worker_thread) from [<80137ad0>] (kthread+0x130/0x160)
> [ 75.854300] r10:9f4f7e88 r9:9f5f2dd8 r8:801320b4 r7:9f4c1900 r6:00000000 r5:9f53dbc0
> [ 75.860830] r4:9f5f2dc0
> [ 75.862076] [<801379a0>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c)
> [ 75.867999] Exception stack(0x9f54bfb0 to 0x9f54bff8)
> [ 75.871753] bfa0: 00000000 00000000 00000000 00000000
> [ 75.878640] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 75.885519] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [ 75.890844] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:801379a0
> [ 75.897377] r4:9f53dbc0 r3:9f54a000
> [ 75.899663] Code: e3a02000 e3a03000 e14b26f4 e24bc055 (e5973000)
> [ 75.904575] ---[ end trace fbca818a124dbf0d ]---
>
> Fixes: 816a3bed9549 ("switchdev: Add fdb.added_by_user to switchdev notifications")
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> ---
> @petr I expect the same issue with Rocker, but I haven't tested it.
>
> net/dsa/slave.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index c287f1ef964c..746ab428a17a 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -1395,6 +1395,9 @@ static void dsa_slave_switchdev_event_work(struct work_struct *work)
> switch (switchdev_work->event) {
> case SWITCHDEV_FDB_ADD_TO_DEVICE:
> fdb_info = &switchdev_work->fdb_info;
> + if (!fdb_info->added_by_user)
> + break;
> +
> err = dsa_port_fdb_add(dp, fdb_info->addr, fdb_info->vid);
> if (err) {
> netdev_dbg(dev, "fdb add failed err=%d\n", err);
> @@ -1406,6 +1409,9 @@ static void dsa_slave_switchdev_event_work(struct work_struct *work)
>
> case SWITCHDEV_FDB_DEL_TO_DEVICE:
> fdb_info = &switchdev_work->fdb_info;
> + if (!fdb_info->added_by_user)
> + break;
> +
> err = dsa_port_fdb_del(dp, fdb_info->addr, fdb_info->vid);
> if (err) {
> netdev_dbg(dev, "fdb del failed err=%d\n", err);
> @@ -1441,7 +1447,6 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused,
> unsigned long event, void *ptr)
> {
> struct net_device *dev = switchdev_notifier_info_to_dev(ptr);
> - struct switchdev_notifier_fdb_info *fdb_info = ptr;
> struct dsa_switchdev_event_work *switchdev_work;
>
> if (!dsa_slave_dev_check(dev))
> @@ -1459,10 +1464,7 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused,
> switch (event) {
> case SWITCHDEV_FDB_ADD_TO_DEVICE: /* fall through */
> case SWITCHDEV_FDB_DEL_TO_DEVICE:
> - if (!fdb_info->added_by_user)
> - break;
> - if (dsa_slave_switchdev_fdb_work_init(switchdev_work,
> - fdb_info))
> + if (dsa_slave_switchdev_fdb_work_init(switchdev_work, ptr))
> goto err_fdb_work_init;
> dev_hold(dev);
> break;
>
Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* [PATCH net-next RFC 2/3] bnxt_en: Store min/max tx/rx rings for individual VFs.
From: Michael Chan @ 2018-05-09 11:21 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1525864903-32619-1-git-send-email-michael.chan@broadcom.com>
With new infrastructure to configure queues differently for each VF,
we need to store the current min/max rx/tx rings for each VF.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 5 +++++
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 23 +++++++++++++++++++----
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index 9b14eb6..2f5a23c 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -837,6 +837,10 @@ struct bnxt_vf_info {
u32 func_flags; /* func cfg flags */
u32 min_tx_rate;
u32 max_tx_rate;
+ u16 min_tx_rings;
+ u16 max_tx_rings;
+ u16 min_rx_rings;
+ u16 max_rx_rings;
void *hwrm_cmd_req_addr;
dma_addr_t hwrm_cmd_req_dma_addr;
};
@@ -1351,6 +1355,7 @@ struct bnxt {
#ifdef CONFIG_BNXT_SRIOV
int nr_vfs;
struct bnxt_vf_info vf;
+ struct hwrm_func_vf_resource_cfg_input vf_resc_cfg_input;
wait_queue_head_t sriov_cfg_wait;
bool sriov_cfg;
#define BNXT_SRIOV_CFG_WAIT_TMO msecs_to_jiffies(10000)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
index a649108..489e534 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
@@ -171,6 +171,10 @@ int bnxt_get_vf_config(struct net_device *dev, int vf_id,
ivi->linkstate = IFLA_VF_LINK_STATE_ENABLE;
else
ivi->linkstate = IFLA_VF_LINK_STATE_DISABLE;
+ ivi->min_tx_queues = vf->min_tx_rings;
+ ivi->max_tx_queues = vf->max_tx_rings;
+ ivi->min_rx_queues = vf->min_rx_rings;
+ ivi->max_rx_queues = vf->max_rx_rings;
return 0;
}
@@ -498,6 +502,8 @@ static int bnxt_hwrm_func_vf_resc_cfg(struct bnxt *bp, int num_vfs)
mutex_lock(&bp->hwrm_cmd_lock);
for (i = 0; i < num_vfs; i++) {
+ struct bnxt_vf_info *vf = &pf->vf[i];
+
req.vf_id = cpu_to_le16(pf->first_vf_id + i);
rc = _hwrm_send_message(bp, &req, sizeof(req),
HWRM_CMD_TIMEOUT);
@@ -506,7 +512,11 @@ static int bnxt_hwrm_func_vf_resc_cfg(struct bnxt *bp, int num_vfs)
break;
}
pf->active_vfs = i + 1;
- pf->vf[i].fw_fid = pf->first_vf_id + i;
+ vf->fw_fid = pf->first_vf_id + i;
+ vf->min_tx_rings = le16_to_cpu(req.min_tx_rings);
+ vf->max_tx_rings = vf_tx_rings;
+ vf->min_rx_rings = le16_to_cpu(req.min_rx_rings);
+ vf->max_rx_rings = vf_rx_rings;
}
mutex_unlock(&bp->hwrm_cmd_lock);
if (pf->active_vfs) {
@@ -521,6 +531,7 @@ static int bnxt_hwrm_func_vf_resc_cfg(struct bnxt *bp, int num_vfs)
hw_resc->max_stat_ctxs -= le16_to_cpu(req.min_stat_ctx) * n;
hw_resc->max_vnics -= le16_to_cpu(req.min_vnics) * n;
+ memcpy(&bp->vf_resc_cfg_input, &req, sizeof(req));
rc = pf->active_vfs;
}
return rc;
@@ -585,6 +596,7 @@ static int bnxt_hwrm_func_cfg(struct bnxt *bp, int num_vfs)
mutex_lock(&bp->hwrm_cmd_lock);
for (i = 0; i < num_vfs; i++) {
+ struct bnxt_vf_info *vf = &pf->vf[i];
int vf_tx_rsvd = vf_tx_rings;
req.fid = cpu_to_le16(pf->first_vf_id + i);
@@ -593,12 +605,15 @@ static int bnxt_hwrm_func_cfg(struct bnxt *bp, int num_vfs)
if (rc)
break;
pf->active_vfs = i + 1;
- pf->vf[i].fw_fid = le16_to_cpu(req.fid);
- rc = __bnxt_hwrm_get_tx_rings(bp, pf->vf[i].fw_fid,
- &vf_tx_rsvd);
+ vf->fw_fid = le16_to_cpu(req.fid);
+ rc = __bnxt_hwrm_get_tx_rings(bp, vf->fw_fid, &vf_tx_rsvd);
if (rc)
break;
total_vf_tx_rings += vf_tx_rsvd;
+ vf->min_tx_rings = vf_tx_rsvd;
+ vf->max_tx_rings = vf_tx_rsvd;
+ vf->min_rx_rings = vf_rx_rings;
+ vf->max_rx_rings = vf_rx_rings;
}
mutex_unlock(&bp->hwrm_cmd_lock);
if (rc)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next RFC 3/3] bnxt_en: Implement .ndo_set_vf_queues().
From: Michael Chan @ 2018-05-09 11:21 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1525864903-32619-1-git-send-email-michael.chan@broadcom.com>
Implement .ndo_set_vf_queues() on the PF driver to configure the queues
parameters for individual VFs. This allows the admin. on the host to
increase or decrease queues for individual VFs.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 1 +
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 67 +++++++++++++++++++++++++
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.h | 2 +
3 files changed, 70 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index dfa0839..2ce9779 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -8373,6 +8373,7 @@ static int bnxt_swdev_port_attr_get(struct net_device *dev,
.ndo_set_vf_link_state = bnxt_set_vf_link_state,
.ndo_set_vf_spoofchk = bnxt_set_vf_spoofchk,
.ndo_set_vf_trust = bnxt_set_vf_trust,
+ .ndo_set_vf_queues = bnxt_set_vf_queues,
#endif
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = bnxt_poll_controller,
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
index 489e534..f0d938c 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
@@ -138,6 +138,73 @@ int bnxt_set_vf_trust(struct net_device *dev, int vf_id, bool trusted)
return 0;
}
+static bool bnxt_param_ok(int new, u16 curr, u16 avail)
+{
+ int delta;
+
+ if (new <= curr)
+ return true;
+
+ delta = new - curr;
+ if (delta <= avail)
+ return true;
+ return false;
+}
+
+int bnxt_set_vf_queues(struct net_device *dev, int vf_id, int min_txq,
+ int max_txq, int min_rxq, int max_rxq)
+{
+ struct hwrm_func_vf_resource_cfg_input req = {0};
+ struct bnxt *bp = netdev_priv(dev);
+ u16 avail_tx_rings, avail_rx_rings;
+ struct bnxt_hw_resc *hw_resc;
+ struct bnxt_vf_info *vf;
+ int rc;
+
+ if (bnxt_vf_ndo_prep(bp, vf_id))
+ return -EINVAL;
+
+ if (!(bp->flags & BNXT_FLAG_NEW_RM))
+ return -EOPNOTSUPP;
+
+ vf = &bp->pf.vf[vf_id];
+ hw_resc = &bp->hw_resc;
+
+ avail_tx_rings = hw_resc->max_tx_rings - bp->tx_nr_rings;
+ if (bp->flags & BNXT_FLAG_AGG_RINGS)
+ avail_rx_rings = hw_resc->max_rx_rings - bp->rx_nr_rings * 2;
+ else
+ avail_rx_rings = hw_resc->max_rx_rings - bp->rx_nr_rings;
+ if (!bnxt_param_ok(min_txq, vf->min_tx_rings, avail_tx_rings))
+ return -ENOBUFS;
+ if (!bnxt_param_ok(min_rxq, vf->min_rx_rings, avail_rx_rings))
+ return -ENOBUFS;
+ if (!bnxt_param_ok(max_txq, vf->max_tx_rings, avail_tx_rings))
+ return -ENOBUFS;
+ if (!bnxt_param_ok(max_rxq, vf->max_rx_rings, avail_rx_rings))
+ return -ENOBUFS;
+
+ bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_FUNC_VF_RESOURCE_CFG, -1, -1);
+ memcpy(&req, &bp->vf_resc_cfg_input, sizeof(req));
+ req.min_tx_rings = cpu_to_le16(min_txq);
+ req.min_rx_rings = cpu_to_le16(min_rxq);
+ req.max_tx_rings = cpu_to_le16(max_txq);
+ req.max_rx_rings = cpu_to_le16(max_rxq);
+ rc = hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT);
+ if (rc)
+ return -EIO;
+
+ hw_resc->max_tx_rings += vf->min_tx_rings;
+ hw_resc->max_rx_rings += vf->min_rx_rings;
+ vf->min_tx_rings = min_txq;
+ vf->max_tx_rings = max_txq;
+ vf->min_rx_rings = min_rxq;
+ vf->max_rx_rings = max_rxq;
+ hw_resc->max_tx_rings -= vf->min_tx_rings;
+ hw_resc->max_rx_rings -= vf->min_rx_rings;
+ return 0;
+}
+
int bnxt_get_vf_config(struct net_device *dev, int vf_id,
struct ifla_vf_info *ivi)
{
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.h
index e9b20cd..325b412 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.h
@@ -35,6 +35,8 @@
int bnxt_set_vf_link_state(struct net_device *, int, int);
int bnxt_set_vf_spoofchk(struct net_device *, int, bool);
int bnxt_set_vf_trust(struct net_device *dev, int vf_id, bool trust);
+int bnxt_set_vf_queues(struct net_device *dev, int vf_id, int min_txq,
+ int max_txq, int min_rxq, int max_rxq);
int bnxt_sriov_configure(struct pci_dev *pdev, int num_vfs);
void bnxt_sriov_disable(struct bnxt *);
void bnxt_hwrm_exec_fwd_req(struct bnxt *);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next RFC 1/3] net: Add support to configure SR-IOV VF minimum and maximum queues.
From: Michael Chan @ 2018-05-09 11:21 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1525864903-32619-1-git-send-email-michael.chan@broadcom.com>
VF Queue resources are always limited and there is currently no
infrastructure to allow the admin. on the host to add or reduce queue
resources for any particular VF. With ever increasing number of VFs
being supported, it is desirable to allow the admin. to configure queue
resources differently for the VFs. Some VFs may require more or fewer
queues due to different bandwidth requirements or different number of
vCPUs in the VM. This patch adds the infrastructure to do that by
adding IFLA_VF_QUEUES netlink attribute and a new .ndo_set_vf_queues()
to the net_device_ops.
Four parameters are exposed for each VF:
o min_tx_queues - Guaranteed or current tx queues assigned to the VF.
o max_tx_queues - Maximum but not necessarily guaranteed tx queues
available to the VF.
o min_rx_queues - Guaranteed or current rx queues assigned to the VF.
o max_rx_queues - Maximum but not necessarily guaranteed rx queues
available to the VF.
The "ip link set" command will subsequently be patched to support the new
operation to set the above parameters.
After the admin. makes a change to the above parameters, the corresponding
VF will have a new range of channels to set using ethtool -L.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
include/linux/if_link.h | 4 ++++
include/linux/netdevice.h | 6 ++++++
include/uapi/linux/if_link.h | 9 +++++++++
net/core/rtnetlink.c | 28 +++++++++++++++++++++++++---
4 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 622658d..8e81121 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -29,5 +29,9 @@ struct ifla_vf_info {
__u32 rss_query_en;
__u32 trusted;
__be16 vlan_proto;
+ __u32 min_tx_queues;
+ __u32 max_tx_queues;
+ __u32 min_rx_queues;
+ __u32 max_rx_queues;
};
#endif /* _LINUX_IF_LINK_H */
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 03ed492..30a3caf 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1023,6 +1023,8 @@ struct dev_ifalias {
* with PF and querying it may introduce a theoretical security risk.
* int (*ndo_set_vf_rss_query_en)(struct net_device *dev, int vf, bool setting);
* int (*ndo_get_vf_port)(struct net_device *dev, int vf, struct sk_buff *skb);
+ * int (*ndo_set_vf_queues)(struct net_device *dev, int vf, int min_txq,
+ * int max_txq, int min_rxq, int max_rxq);
* int (*ndo_setup_tc)(struct net_device *dev, enum tc_setup_type type,
* void *type_data);
* Called to setup any 'tc' scheduler, classifier or action on @dev.
@@ -1272,6 +1274,10 @@ struct net_device_ops {
int (*ndo_set_vf_rss_query_en)(
struct net_device *dev,
int vf, bool setting);
+ int (*ndo_set_vf_queues)(struct net_device *dev,
+ int vf,
+ int min_txq, int max_txq,
+ int min_rxq, int max_rxq);
int (*ndo_setup_tc)(struct net_device *dev,
enum tc_setup_type type,
void *type_data);
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index b852664..fc56a47 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -658,6 +658,7 @@ enum {
IFLA_VF_IB_NODE_GUID, /* VF Infiniband node GUID */
IFLA_VF_IB_PORT_GUID, /* VF Infiniband port GUID */
IFLA_VF_VLAN_LIST, /* nested list of vlans, option for QinQ */
+ IFLA_VF_QUEUES, /* Min and Max TX/RX queues */
__IFLA_VF_MAX,
};
@@ -748,6 +749,14 @@ struct ifla_vf_trust {
__u32 setting;
};
+struct ifla_vf_queues {
+ __u32 vf;
+ __u32 min_tx_queues;
+ __u32 max_tx_queues;
+ __u32 min_rx_queues;
+ __u32 max_rx_queues;
+};
+
/* VF ports management section
*
* Nested layout of set/get msg is:
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 8080254..7cf3582 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -921,7 +921,8 @@ static inline int rtnl_vfinfo_size(const struct net_device *dev,
nla_total_size_64bit(sizeof(__u64)) +
/* IFLA_VF_STATS_TX_DROPPED */
nla_total_size_64bit(sizeof(__u64)) +
- nla_total_size(sizeof(struct ifla_vf_trust)));
+ nla_total_size(sizeof(struct ifla_vf_trust)) +
+ nla_total_size(sizeof(struct ifla_vf_queues)));
return size;
} else
return 0;
@@ -1181,6 +1182,7 @@ static noinline_for_stack int rtnl_fill_vfinfo(struct sk_buff *skb,
struct ifla_vf_vlan_info vf_vlan_info;
struct ifla_vf_spoofchk vf_spoofchk;
struct ifla_vf_tx_rate vf_tx_rate;
+ struct ifla_vf_queues vf_queues;
struct ifla_vf_stats vf_stats;
struct ifla_vf_trust vf_trust;
struct ifla_vf_vlan vf_vlan;
@@ -1217,7 +1219,8 @@ static noinline_for_stack int rtnl_fill_vfinfo(struct sk_buff *skb,
vf_spoofchk.vf =
vf_linkstate.vf =
vf_rss_query_en.vf =
- vf_trust.vf = ivi.vf;
+ vf_trust.vf =
+ vf_queues.vf = ivi.vf;
memcpy(vf_mac.mac, ivi.mac, sizeof(ivi.mac));
vf_vlan.vlan = ivi.vlan;
@@ -1232,6 +1235,10 @@ static noinline_for_stack int rtnl_fill_vfinfo(struct sk_buff *skb,
vf_linkstate.link_state = ivi.linkstate;
vf_rss_query_en.setting = ivi.rss_query_en;
vf_trust.setting = ivi.trusted;
+ vf_queues.min_tx_queues = ivi.min_tx_queues;
+ vf_queues.max_tx_queues = ivi.max_tx_queues;
+ vf_queues.min_rx_queues = ivi.min_rx_queues;
+ vf_queues.max_rx_queues = ivi.max_rx_queues;
vf = nla_nest_start(skb, IFLA_VF_INFO);
if (!vf)
goto nla_put_vfinfo_failure;
@@ -1249,7 +1256,9 @@ static noinline_for_stack int rtnl_fill_vfinfo(struct sk_buff *skb,
sizeof(vf_rss_query_en),
&vf_rss_query_en) ||
nla_put(skb, IFLA_VF_TRUST,
- sizeof(vf_trust), &vf_trust))
+ sizeof(vf_trust), &vf_trust) ||
+ nla_put(skb, IFLA_VF_QUEUES,
+ sizeof(vf_queues), &vf_queues))
goto nla_put_vf_failure;
vfvlanlist = nla_nest_start(skb, IFLA_VF_VLAN_LIST);
if (!vfvlanlist)
@@ -1706,6 +1715,7 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb,
[IFLA_VF_TRUST] = { .len = sizeof(struct ifla_vf_trust) },
[IFLA_VF_IB_NODE_GUID] = { .len = sizeof(struct ifla_vf_guid) },
[IFLA_VF_IB_PORT_GUID] = { .len = sizeof(struct ifla_vf_guid) },
+ [IFLA_VF_QUEUES] = { .len = sizeof(struct ifla_vf_queues) },
};
static const struct nla_policy ifla_port_policy[IFLA_PORT_MAX+1] = {
@@ -2208,6 +2218,18 @@ static int do_setvfinfo(struct net_device *dev, struct nlattr **tb)
return handle_vf_guid(dev, ivt, IFLA_VF_IB_PORT_GUID);
}
+ if (tb[IFLA_VF_QUEUES]) {
+ struct ifla_vf_queues *ivq = nla_data(tb[IFLA_VF_QUEUES]);
+
+ err = -EOPNOTSUPP;
+ if (ops->ndo_set_vf_queues)
+ err = ops->ndo_set_vf_queues(dev, ivq->vf,
+ ivq->min_tx_queues, ivq->max_tx_queues,
+ ivq->min_rx_queues, ivq->max_rx_queues);
+ if (err < 0)
+ return err;
+ }
+
return err;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next RFC 0/3] net: Add support to configure SR-IOV VF queues.
From: Michael Chan @ 2018-05-09 11:21 UTC (permalink / raw)
To: davem; +Cc: netdev
VF Queue resources are always limited and there is currently no
infrastructure to allow the admin. on the host to add or reduce queue
resources for any particular VF. This RFC series adds the infrastructure
to do that and adds the functionality to the bnxt_en driver.
The "ip link set" command will subsequently be patched to support the new
operation.
Michael Chan (3):
net: Add support to configure SR-IOV VF minimum and maximum queues.
bnxt_en: Store min/max tx/rx rings for individual VFs.
bnxt_en: Implement .ndo_set_vf_queues().
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 1 +
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 5 ++
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 90 +++++++++++++++++++++++--
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.h | 2 +
include/linux/if_link.h | 4 ++
include/linux/netdevice.h | 6 ++
include/uapi/linux/if_link.h | 9 +++
net/core/rtnetlink.c | 28 +++++++-
8 files changed, 138 insertions(+), 7 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH] sctp: fix spelling mistake: "max_retans" -> "max_retrans"
From: Neil Horman @ 2018-05-09 11:16 UTC (permalink / raw)
To: Colin King
Cc: Vlad Yasevich, Marcelo Ricardo Leitner, David S . Miller,
linux-sctp, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180508222428.24874-1-colin.king@canonical.com>
On Tue, May 08, 2018 at 11:24:28PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in error string
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> net/sctp/sm_make_chunk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> index 4d7b3ccea078..4a4fd1971255 100644
> --- a/net/sctp/sm_make_chunk.c
> +++ b/net/sctp/sm_make_chunk.c
> @@ -1131,7 +1131,7 @@ struct sctp_chunk *sctp_make_violation_max_retrans(
> const struct sctp_association *asoc,
> const struct sctp_chunk *chunk)
> {
> - static const char error[] = "Association exceeded its max_retans count";
> + static const char error[] = "Association exceeded its max_retrans count";
> size_t payload_len = sizeof(error) + sizeof(struct sctp_errhdr);
> struct sctp_chunk *retval;
>
> --
> 2.17.0
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* [PATCH v2 net-next] drivers: net: davinci_mdio: prevent spurious timeout
From: Sekhar Nori @ 2018-05-09 11:00 UTC (permalink / raw)
To: David S . Miller
Cc: Grygorii Strashko, linux-omap, netdev, Andrew Lunn, Sekhar Nori
A well timed kernel preemption in the time_after() loop
in wait_for_idle() can result in a spurious timeout
error to be returned.
Fix it by using readl_poll_timeout() which takes care of
this issue.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
v2: use readl_poll_timeout() per suggestion from Andrew.
The issue has not been personally observed by me, but has
been reported by users. Sending for next-next given the
non-critical nature. There is seems to be no easy way to
reproduce this.
drivers/net/ethernet/ti/davinci_mdio.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 3c33f4504d8e..d073432a5dbe 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -34,6 +34,7 @@
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/io.h>
+#include <linux/iopoll.h>
#include <linux/pm_runtime.h>
#include <linux/davinci_emac.h>
#include <linux/of.h>
@@ -227,14 +228,16 @@ static inline int wait_for_user_access(struct davinci_mdio_data *data)
static inline int wait_for_idle(struct davinci_mdio_data *data)
{
struct davinci_mdio_regs __iomem *regs = data->regs;
- unsigned long timeout = jiffies + msecs_to_jiffies(MDIO_TIMEOUT);
+ u32 val, ret;
- while (time_after(timeout, jiffies)) {
- if (__raw_readl(®s->control) & CONTROL_IDLE)
- return 0;
+ ret = readl_poll_timeout(®s->control, val, val & CONTROL_IDLE,
+ 0, MDIO_TIMEOUT * 1000);
+ if (ret) {
+ dev_err(data->dev, "timed out waiting for idle\n");
+ return ret;
}
- dev_err(data->dev, "timed out waiting for idle\n");
- return -ETIMEDOUT;
+
+ return 0;
}
static int davinci_mdio_read(struct mii_bus *bus, int phy_id, int phy_reg)
--
2.16.2
^ permalink raw reply related
* Re: [PATCH net-next] drivers: net: davinci_mdio: prevent sprious timeout
From: Sekhar Nori @ 2018-05-09 10:44 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Grygorii Strashko, David S . Miller, linux-omap, netdev
In-Reply-To: <20180508124856.GA2888@lunn.ch>
On Tuesday 08 May 2018 06:18 PM, Andrew Lunn wrote:
> On Tue, May 08, 2018 at 01:56:38PM +0530, Sekhar Nori wrote:
>> A well timed kernel preemption in the time_after() loop
>> in wait_for_idle() can result in a spurious timeout
>> error to be returned.
>>
>> Fix it by checking for status of hardware before returning
>> timeout error.
>>
>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>
> I've seen this with other drivers as well.
>
> I suggest you make use of readx_poll_timeout(), or one of its
> cousins. They get this right.
Thanks for pointing me to these. I somehow thought these helpers are
only available with regmap.
Sending a version using readl_poll_timeout(). I know __raw_readl() is
used elsewhere in the driver, but I think that should be cleaned up
sometime to use readl_relaxed() at least. So not sure if there is
benefit in persisting with existing accessor.
Thanks,
Sekhar
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2018-05-09 10:44 UTC (permalink / raw)
To: Anders Roxell
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List
In-Reply-To: <CADYN=9JYJVVKyrPexNKNkbNjNBr1B3Xeuf6-wpdpE9+Px1UF9g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
Hi Anders,
On Wed, 9 May 2018 10:24:49 +0200 Anders Roxell <anders.roxell@linaro.org> wrote:
>
> On 9 May 2018 at 06:19, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
> > - TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
> > + TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh udpgso.sh
>
> in_netns.sh shouldn't be in the above list, its already in the
> TEST_PROGS_EXTENDED below.
Thanks for that, I have fixed up my merge resolution for tomorrow.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH net] udp: fix SO_BINDTODEVICE
From: Paolo Abeni @ 2018-05-09 10:42 UTC (permalink / raw)
To: netdev; +Cc: Damir Mansurov, David Ahern, David Miller
Damir reported a breakage of SO_BINDTODEVICE for UDP sockets.
In absence of VRF devices, after commit fb74c27735f0 ("net:
ipv4: add second dif to udp socket lookups") the dif mismatch
isn't fatal anymore for UDP socket lookup with non null
sk_bound_dev_if, breaking SO_BINDTODEVICE semantics.
This changeset addresses the issue making the dif match mandatory
again in the above scenario.
Reported-by: Damir Mansurov <dnman@oktetlabs.ru>
Fixes: fb74c27735f0 ("net: ipv4: add second dif to udp socket lookups")
Fixes: 1801b570dd2a ("net: ipv6: add second dif to udp socket lookups")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
net/ipv4/udp.c | 4 ++--
net/ipv6/udp.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 24b5c59b1c53..c2a292dfd137 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -401,9 +401,9 @@ static int compute_score(struct sock *sk, struct net *net,
bool dev_match = (sk->sk_bound_dev_if == dif ||
sk->sk_bound_dev_if == sdif);
- if (exact_dif && !dev_match)
+ if (!dev_match)
return -1;
- if (sk->sk_bound_dev_if && dev_match)
+ if (sk->sk_bound_dev_if)
score += 4;
}
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 4ec76a87aeb8..ea0730028e5d 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -148,9 +148,9 @@ static int compute_score(struct sock *sk, struct net *net,
bool dev_match = (sk->sk_bound_dev_if == dif ||
sk->sk_bound_dev_if == sdif);
- if (exact_dif && !dev_match)
+ if (!dev_match)
return -1;
- if (sk->sk_bound_dev_if && dev_match)
+ if (sk->sk_bound_dev_if)
score++;
}
--
2.14.3
^ permalink raw reply related
* Re: [PATCH] net/mlx4_en: Fix an error handling path in 'mlx4_en_init_netdev()'
From: Tariq Toukan @ 2018-05-09 10:31 UTC (permalink / raw)
To: Christophe JAILLET, davem, tariqt
Cc: netdev, linux-rdma, linux-kernel, kernel-janitors
In-Reply-To: <20180508093426.11550-1-christophe.jaillet@wanadoo.fr>
On 08/05/2018 12:34 PM, Christophe JAILLET wrote:
> If the 2nd memory allocation of the loop fails, we must undo the
> memory allocation done so far.
>
> Fixes: 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index e0adac4a9a19..bf078244e467 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -3331,7 +3331,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
> if (!priv->tx_cq[t]) {
> kfree(priv->tx_ring[t]);
> err = -ENOMEM;
> - goto out;
> + goto err_free_tx;
> }
> }
> priv->rx_ring_num = prof->rx_ring_num;
>
Hi Christophe,
Thanks for re-sending this.
In your previous mail you referred to the call mlx4_en_destroy_netdev here:
https://elixir.bootlin.com/linux/v4.16-rc5/source/drivers/net/ethernet/mellanox/mlx4/en_main.c#L232
While I was referring to the one below, which is always called on failures:
https://elixir.bootlin.com/linux/v4.16-rc5/source/drivers/net/ethernet/mellanox/mlx4/en_netdev.c#L3587
I still believe that the err_free_tx label and its while loop is redundant.
Regards,
Tariq
^ permalink raw reply
* Re: mwifiex: delete unneeded include
From: Kalle Valo @ 2018-05-09 10:25 UTC (permalink / raw)
To: Julia Lawall
Cc: Amitkumar Karwar, kernel-janitors, Nishant Sarmukadam,
Ganapathi Bhat, Xinming Hu, David S. Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <1525593233-10968-1-git-send-email-Julia.Lawall@lip6.fr>
Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> Nothing that is defined in 11ac.h is referenced in cmdevt.c.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Patch applied to wireless-drivers-next.git, thanks.
4793e5a954fa mwifiex: delete unneeded include
--
https://patchwork.kernel.org/patch/10382667/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH net] ipv4: reset fnhe_mtu_locked after cache route flushed
From: Hangbin Liu @ 2018-05-09 10:06 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, Stefano Brivio, Hangbin Liu
After route cache is flushed via ipv4_sysctl_rtcache_flush(), we forget
to reset fnhe_mtu_locked in rt_bind_exception(). When pmtu is updated
in __ip_rt_update_pmtu(), it will return directly since the pmtu is
still locked. e.g.
+ ip netns exec client ping 10.10.1.1 -c 1 -s 1400 -M do
PING 10.10.1.1 (10.10.1.1) 1400(1428) bytes of data.
>From 10.10.0.254 icmp_seq=1 Frag needed and DF set (mtu = 0)
--- 10.10.1.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
+ ip netns exec client ip route get 10.10.1.1
10.10.1.1 via 10.10.0.254 dev veth0_c src 10.10.0.1 uid 0
cache expires 599sec mtu lock 552
+ ip netns exec client ip route flush cache
+ ip netns exec client ip route get 10.10.1.1
10.10.1.1 via 10.10.0.254 dev veth0_c src 10.10.0.1 uid 0
cache
+ ip netns exec client ping 10.10.1.1 -c 1 -s 1400 -M do
PING 10.10.1.1 (10.10.1.1) 1400(1428) bytes of data.
ping: local error: Message too long, mtu=576
--- 10.10.1.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
+ ip netns exec client ip route get 10.10.1.1
10.10.1.1 via 10.10.0.254 dev veth0_c src 10.10.0.1 uid 0
cache
Fixes: d52e5a7e7ca49 ("ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmtu")
Reported-by: Jianlin Shi <jishi@redhat.com>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/ipv4/route.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 1412a7b..29268ef 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1375,6 +1375,7 @@ static bool rt_bind_exception(struct rtable *rt, struct fib_nh_exception *fnhe,
fnhe->fnhe_gw = 0;
fnhe->fnhe_pmtu = 0;
fnhe->fnhe_expires = 0;
+ fnhe->fnhe_mtu_locked = false;
fnhe_flush_routes(fnhe);
orig = NULL;
}
--
2.5.5
^ permalink raw reply related
* [PATCH] net/9p: fix spelling mistake: "suspsend" -> "suspend"
From: Colin King @ 2018-05-09 9:48 UTC (permalink / raw)
To: Eric Van Hensbergen, Ron Minnich, Latchesar Ionkov,
David S . Miller, v9fs-developer, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in dev_warn message text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/9p/trans_xen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 086a4abdfa7c..0f19960390a6 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -485,7 +485,7 @@ static int xen_9pfs_front_probe(struct xenbus_device *dev,
static int xen_9pfs_front_resume(struct xenbus_device *dev)
{
- dev_warn(&dev->dev, "suspsend/resume unsupported\n");
+ dev_warn(&dev->dev, "suspend/resume unsupported\n");
return 0;
}
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net-next] tun: Do SIOCGSKNS out of rtnl_lock()
From: Kirill Tkhai @ 2018-05-09 9:00 UTC (permalink / raw)
To: Jason Wang, davem, edumazet, mst, brouer, peterpenkov96, sd,
netdev
In-Reply-To: <06a89506-2d3c-a0dd-3ac2-2c517683517e@redhat.com>
Hi, Jason,
On 09.05.2018 10:18, Jason Wang wrote:
>
>
> On 2018年05月09日 00:21, Kirill Tkhai wrote:
>> Since net ns of tun device is assigned on the device creation,
>> and it never changes, we do not need to use any lock to get it
>> from alive tun.
>>
>> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
>> ---
>> drivers/net/tun.c | 18 +++++++-----------
>> 1 file changed, 7 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index d3c04ab9752a..44d4f3d25350 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -2850,10 +2850,10 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
>> unsigned long arg, int ifreq_len)
>> {
>> struct tun_file *tfile = file->private_data;
>> + struct net *net = sock_net(&tfile->sk);
>> struct tun_struct *tun;
>> void __user* argp = (void __user*)arg;
>> struct ifreq ifr;
>> - struct net *net;
>> kuid_t owner;
>> kgid_t group;
>> int sndbuf;
>> @@ -2877,14 +2877,18 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
>> */
>> return put_user(IFF_TUN | IFF_TAP | TUN_FEATURES,
>> (unsigned int __user*)argp);
>> - } else if (cmd == TUNSETQUEUE)
>> + } else if (cmd == TUNSETQUEUE) {
>> return tun_set_queue(file, &ifr);
>> + } else if (cmd == SIOCGSKNS) {
>
> Not for this patch, reusing socket ioctl cmd is probably not good though they were probably not intersected (see ioctl-number.txt). We probably need to introduce TUN specific ioctls for SIOCGSKNS and SIOCGIFHWADDR and warn for socket ones.
The most of socket ioctl cmds use 0x8900 type:
#define SOCK_IOC_TYPE 0x89
while tun cmd is 5400 ('T'). They should not intersect.
The only exceptions are
#define SIOCINQ FIONREAD
#define SIOCOUTQ TIOCOUTQ
#define TIOCOUTQ 0x5411
#define FIONREAD 0x541B
But they can't intersect even with exceptions, since tun nr starts from 200:
#define TUNSETNOCSUM _IOW('T', 200, int)
and 200 > 0x1b (==27).
I implemented SIOCGSKNS cmd in the same style as older socket cmds were used.
I'm not sure, we can remove existing SIOCGIFHWADDR, since they are already used.
If we add a warn, which time will we able to remove them? Some old software may
use it, and in case of the program isn't developed any more, nobody can fix this
warnings, even if he/she sees them..
Kirill
>
>> + if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
>> + return -EPERM;
>> + return open_related_ns(&net->ns, get_net_ns);
>> + }
>> ret = 0;
>> rtnl_lock();
>> tun = tun_get(tfile);
>> - net = sock_net(&tfile->sk);
>> if (cmd == TUNSETIFF) {
>> ret = -EEXIST;
>> if (tun)
>> @@ -2914,14 +2918,6 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
>> tfile->ifindex = ifindex;
>> goto unlock;
>> }
>> - if (cmd == SIOCGSKNS) {
>> - ret = -EPERM;
>> - if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
>> - goto unlock;
>> -
>> - ret = open_related_ns(&net->ns, get_net_ns);
>> - goto unlock;
>> - }
>> ret = -EBADFD;
>> if (!tun)
>>
>
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: fix added_by_user switchdev notification
From: Petr Machata @ 2018-05-09 8:54 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, jiri, idosch, ivecera, davem,
stephen, andrew, f.fainelli, nikolay, bridge
In-Reply-To: <20180509030312.29548-1-vivien.didelot@savoirfairelinux.com>
Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
> @petr I expect the same issue with Rocker, but I haven't tested it.
Yeah, pretty sure. Such an obvious bug, sorry about that :-/
I'll send a rocker patch later today.
Thanks,
Petr
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Anders Roxell @ 2018-05-09 8:24 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List
In-Reply-To: <20180509141908.7b07df43@canb.auug.org.au>
On 9 May 2018 at 06:19, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> tools/testing/selftests/net/Makefile
>
> between commit:
>
> 1751eb42ddb5 ("selftests: net: use TEST_PROGS_EXTENDED")
>
> from the net tree and commits:
>
> a7b15ab887e5 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc tools/testing/selftests/net/Makefile
> index 3ff81a478dbe,73af45773938..000000000000
> --- a/tools/testing/selftests/net/Makefile
> +++ b/tools/testing/selftests/net/Makefile
> @@@ -5,10 -5,13 +5,13 @@@ CFLAGS = -Wall -Wl,--no-as-needed -O2
> CFLAGS += -I../../../../usr/include/
>
> TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
> - TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
> + TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh udpgso.sh
in_netns.sh shouldn't be in the above list, its already in the
TEST_PROGS_EXTENDED below.
Cheers,
Anders
> + TEST_PROGS += udpgso_bench.sh
> -TEST_GEN_PROGS_EXTENDED := in_netns.sh
> +TEST_PROGS_EXTENDED := in_netns.sh
> TEST_GEN_FILES = socket
> TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
> + TEST_GEN_FILES += tcp_mmap tcp_inq
> + TEST_GEN_FILES += udpgso udpgso_bench_tx udpgso_bench_rx
> TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
> TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict
>
^ permalink raw reply
* [PATCH v2] hv_netvsc: Fix net device attach on older Windows hosts
From: Mohammed Gamal @ 2018-05-09 8:17 UTC (permalink / raw)
To: netdev, sthemmin; +Cc: Mohammed Gamal, haiyangz, linux-kernel, devel, vkuznets
On older windows hosts the net_device instance is returned to
the caller of rndis_filter_device_add() without having the presence
bit set first. This would cause any subsequent calls to network device
operations (e.g. MTU change, channel change) to fail after the device
is detached once, returning -ENODEV.
Instead of returning the device instabce, we take the exit path where
we call netif_device_attach()
Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic")
Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
---
drivers/net/hyperv/rndis_filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
index 6b127be..e7ca5b5 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -1288,7 +1288,7 @@ struct netvsc_device *rndis_filter_device_add(struct hv_device *dev,
rndis_device->link_state ? "down" : "up");
if (net_device->nvsp_version < NVSP_PROTOCOL_VERSION_5)
- return net_device;
+ goto out;
rndis_filter_query_link_speed(rndis_device, net_device);
--
1.8.3.1
^ permalink raw reply related
* Re: [bpf-next v2 8/9] bpf: Provide helper to do forwarding lookups in kernel FIB table
From: Daniel Borkmann @ 2018-05-09 8:15 UTC (permalink / raw)
To: David Ahern, netdev, borkmann, ast
Cc: davem, shm, roopa, brouer, toke, john.fastabend
In-Reply-To: <20180504025432.23451-9-dsahern@gmail.com>
On 05/04/2018 04:54 AM, David Ahern wrote:
> Provide a helper for doing a FIB and neighbor lookup in the kernel
> tables from an XDP program. The helper provides a fastpath for forwarding
> packets. If the packet is a local delivery or for any reason is not a
> simple lookup and forward, the packet continues up the stack.
>
> If it is to be forwarded, the forwarding can be done directly if the
> neighbor is already known. If the neighbor does not exist, the first
> few packets go up the stack for neighbor resolution. Once resolved, the
> xdp program provides the fast path.
>
> On successful lookup the nexthop dmac, current device smac and egress
> device index are returned.
>
> The API supports IPv4, IPv6 and MPLS protocols, but only IPv4 and IPv6
> are implemented in this patch. The API includes layer 4 parameters if
> the XDP program chooses to do deep packet inspection to allow compare
> against ACLs implemented as FIB rules.
>
> Header rewrite is left to the XDP program.
>
> The lookup takes 2 flags:
> - BPF_FIB_LOOKUP_DIRECT to do a lookup that bypasses FIB rules and goes
> straight to the table associated with the device (expert setting for
> those looking to maximize throughput)
>
> - BPF_FIB_LOOKUP_OUTPUT to do a lookup from the egress perspective.
> Default is an ingress lookup.
>
> Initial performance numbers collected by Jesper, forwarded packets/sec:
>
> Full stack XDP FIB lookup XDP Direct lookup
> IPv4 1,947,969 7,074,156 7,415,333
> IPv6 1,728,000 6,165,504 7,262,720
>
> These number are single CPU core forwarding on a Broadwell
> E5-1650 v4 @ 3.60GHz.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Ohh well, this is causing allmodconfig build warnings (e.g. on x86) as reported today:
In file included from include/linux/dma-mapping.h:5:0,
from include/linux/skbuff.h:34,
from include/linux/if_ether.h:23,
from include/uapi/linux/bpf.h:13,
from include/linux/bpf-cgroup.h:6,
from include/linux/cgroup-defs.h:22,
from include/linux/cgroup.h:28,
from include/linux/perf_event.h:57,
from include/linux/trace_events.h:10,
from include/trace/trace_events.h:20,
from include/trace/define_trace.h:96,
from drivers/android/binder_trace.h:387,
from drivers/android/binder.c:5702:
include/linux/sizes.h:24:0: warning: "SZ_1K" redefined
#define SZ_1K 0x00000400
drivers/android/binder.c:116:0: note: this is the location of the previous definition
#define SZ_1K 0x400
In file included from include/linux/dma-mapping.h:5:0,
from include/linux/skbuff.h:34,
from include/linux/if_ether.h:23,
from include/uapi/linux/bpf.h:13,
from include/linux/bpf-cgroup.h:6,
from include/linux/cgroup-defs.h:22,
from include/linux/cgroup.h:28,
from include/linux/perf_event.h:57,
from include/linux/trace_events.h:10,
from include/trace/trace_events.h:20,
from include/trace/define_trace.h:96,
from drivers/android/binder_trace.h:387,
from drivers/android/binder.c:5702:
include/linux/sizes.h:37:0: warning: "SZ_4M" redefined
#define SZ_4M 0x00400000
drivers/android/binder.c:120:0: note: this is the location of the previous definition
#define SZ_4M 0x400000
fs/ecryptfs/miscdev.c:206:0: warning: "PKT_TYPE_OFFSET" redefined
#define PKT_TYPE_OFFSET 0
In file included from include/linux/if_ether.h:23:0,
from include/uapi/linux/bpf.h:13,
from include/linux/bpf-cgroup.h:6,
from include/linux/cgroup-defs.h:22,
from include/linux/cgroup.h:28,
from include/linux/writeback.h:183,
from include/linux/backing-dev.h:16,
from fs/ecryptfs/ecryptfs_kernel.h:41,
from fs/ecryptfs/miscdev.c:30:
include/linux/skbuff.h:753:0: note: this is the location of the previous definition
#define PKT_TYPE_OFFSET() offsetof(struct sk_buff, __pkt_type_offset)
Lets get a clean, proper version of the whole series into bpf-next. I've dropped it
from there right now and waiting for your v3 respin to apply with the above fixed.
Thank you.
^ permalink raw reply
* Re: KASAN: use-after-free Read in __dev_queue_xmit
From: Eric Biggers @ 2018-05-09 7:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Dumazet, syzbot, alexander.deucher, Andrey Konovalov,
Anoob Soman, chris, David Miller, elena.reshetova,
Greg Kroah-Hartman, Kees Cook, LKML, Mike Maloney, mchehab,
netdev, rami.rosen, Sowmini Varadhan, syzkaller-bugs,
Willem de Bruijn
In-Reply-To: <1515048794.131759.4.camel@gmail.com>
On Wed, Jan 03, 2018 at 10:53:14PM -0800, Eric Dumazet wrote:
> On Wed, 2018-01-03 at 21:13 -0800, Eric Dumazet wrote:
> > Note: all commands must start from beginning of the line in the email body.
> >
> > I guess skb_probe_transport_header() should be hardened to reject malicious
> > packets given by user space, instead of being gentle.
>
> Although bug triggered for this particular repro is in flow dissector
> :/
>
> I will test :
>
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 15ce300637650e17fcab7e378b20fe7972686d46..544bddf08e13c7f6e47aadc737244c9ba5af56b2 100644
> --- a/net/core/flow_dissector.c
> +++ b/net/core/flow_dissector.c
> @@ -976,8 +976,8 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> out_good:
> ret = true;
>
> - key_control->thoff = (u16)nhoff;
> out:
> + key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
> key_basic->n_proto = proto;
> key_basic->ip_proto = ip_proto;
>
> @@ -985,7 +985,6 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>
> out_bad:
> ret = false;
> - key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
> goto out;
> }
> EXPORT_SYMBOL(__skb_flow_dissect);
Fix for this was commit d0c081b49137cd:
#syz fix: flow_dissector: properly cap thoff field
But a crash with the same signature is still occurring, so it should eventually
get reported again. C reproducer is here, it works on Linus' tree (commit
036db8bd963): https://syzkaller.appspot.com/text?tag=ReproC&x=105b1ae7800000
- Eric
^ permalink raw reply
* Re: pull-request: ieee802154 2018-05-08
From: Stefan Schmidt @ 2018-05-09 7:31 UTC (permalink / raw)
To: David Miller; +Cc: s.schmidt, linux-wpan, alex.aring, netdev
In-Reply-To: <20180508.200638.1908252284342544792.davem@davemloft.net>
Hello.
On 05/09/2018 02:06 AM, David Miller wrote:
> From: Stefan Schmidt <stefan@osg.samsung.com>
> Date: Tue, 8 May 2018 21:55:37 +0200
>
>> On 05/08/2018 04:18 PM, David Miller wrote:
>>> Please submit the -stable fix directly, you can feel free to CC: me.
>> Will do when the patch hits Linus git tree.
>>
>> I have a quick question on the process here. From the netdev-faq document
>> I was under the impression all stable patches under net/ and drivers/net
>> should be brought up to you and would be handled by you.
>>
>> Does this apply to the core part of net (I fully understand that ieee802154
>> is rather a niche) or is there some other reason for this exception?
>>
>> Both processes (the normal stable one as well as the slightly different one
>> for net/) would be fine to go with for me. Just need to know which one I
>> should use for future stable patches. :-)
>>
>> regards
>> Stefan Schmidt
> Generally wireless and ipsec have been submitting them directly,
> sometimes the Intel ethernet guys do too.
>
> Sometimes this makes things easier for me, and I'll ask you to submit
> things directly when that is the case like right now.
Thanks for taking the time to explain it. I will go ahead and handle
the stable patches for ieee802154 directly from now on. If you want
to have this changed again just let me know.
regards
Stefan Schmidt
^ permalink raw reply
* [PATCH net] nfp: flower: remove headroom from max MTU calculation
From: Jakub Kicinski @ 2018-05-09 7:18 UTC (permalink / raw)
To: davem; +Cc: oss-drivers, netdev, Pieter Jansen van Vuuren
From: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Since commit 29a5dcae2790 ("nfp: flower: offload phys port MTU change") we
take encapsulation headroom into account when calculating the max allowed
MTU. This is unnecessary as the max MTU advertised by firmware should have
already accounted for encap headroom.
Subtracting headroom twice brings the max MTU below what's necessary for
some deployments.
Fixes: 29a5dcae2790 ("nfp: flower: offload phys port MTU change")
Signed-off-by: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Reviewed-by: John Hurley <john.hurley@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
.../net/ethernet/netronome/nfp/flower/main.c | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/main.c b/drivers/net/ethernet/netronome/nfp/flower/main.c
index a997e34bcec2..84e3b9f5abb1 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/main.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/main.c
@@ -52,8 +52,6 @@
#define NFP_FLOWER_ALLOWED_VER 0x0001000000010000UL
-#define NFP_FLOWER_FRAME_HEADROOM 158
-
static const char *nfp_flower_extra_cap(struct nfp_app *app, struct nfp_net *nn)
{
return "FLOWER";
@@ -559,22 +557,6 @@ static void nfp_flower_clean(struct nfp_app *app)
app->priv = NULL;
}
-static int
-nfp_flower_check_mtu(struct nfp_app *app, struct net_device *netdev,
- int new_mtu)
-{
- /* The flower fw reserves NFP_FLOWER_FRAME_HEADROOM bytes of the
- * supported max MTU to allow for appending tunnel headers. To prevent
- * unexpected behaviour this needs to be accounted for.
- */
- if (new_mtu > netdev->max_mtu - NFP_FLOWER_FRAME_HEADROOM) {
- nfp_err(app->cpp, "New MTU (%d) is not valid\n", new_mtu);
- return -EINVAL;
- }
-
- return 0;
-}
-
static bool nfp_flower_check_ack(struct nfp_flower_priv *app_priv)
{
bool ret;
@@ -656,7 +638,6 @@ const struct nfp_app_type app_flower = {
.init = nfp_flower_init,
.clean = nfp_flower_clean,
- .check_mtu = nfp_flower_check_mtu,
.repr_change_mtu = nfp_flower_repr_change_mtu,
.vnic_alloc = nfp_flower_vnic_alloc,
--
2.17.0
^ 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