* RE: [PATCH v4 net-next 4/6] net: dsa: sja1105: Advertise the 8 TX queues
From: Jose Abreu @ 2019-09-15 16:41 UTC (permalink / raw)
To: Vladimir Oltean, f.fainelli@gmail.com, vivien.didelot@gmail.com,
andrew@lunn.ch, davem@davemloft.net, vinicius.gomes@intel.com,
vedang.patel@intel.com, richardcochran@gmail.com
Cc: weifeng.voon@intel.com, jiri@mellanox.com, m-karicheri2@ti.com,
jose.abreu@synopsys.com, ilias.apalodimas@linaro.org,
jhs@mojatatu.com, xiyou.wangcong@gmail.com,
kurt.kanzenbach@linutronix.de, joergen.andreasen@microchip.com,
netdev@vger.kernel.org
In-Reply-To: <20190915020003.27926-5-olteanv@gmail.com>
From: Vladimir Oltean <olteanv@gmail.com>
Date: Sep/15/2019, 03:00:01 (UTC+00:00)
> Instead of looking directly at skb->priority during xmit, let's get the
> netdev queue and the queue-to-traffic-class mapping, and put the
> resulting traffic class into the dsa_8021q PCP field. The switch is
> configured with a 1-to-1 PCP-to-ingress-queue-to-egress-queue mapping
> (see vlan_pmap in sja1105_main.c), so the effect is that we can inject
> into a front-panel's egress traffic class through VLAN tagging from
> Linux, completely transparently.
Wouldn't it be better to just rely on skb queue mapping as per userspace
settings ? I mean this way you cant create some complex scenarios
without having the VLAN ID need.
I generally use u32 filter and skbedit queue_mapping action to achieve
this.
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* [PATCH net-next] s390/ctcm: Delete unnecessary checks before the macro call “dev_kfree_skb”
From: Julian Wiedmann @ 2019-09-15 17:21 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-s390, Heiko Carstens, Stefan Raspl, Ursula Braun,
Markus Elfring, Julian Wiedmann
From: Markus Elfring <elfring@users.sourceforge.net>
The dev_kfree_skb() function performs also input parameter validation.
Thus the test around the shown calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
---
drivers/s390/net/ctcm_main.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/s390/net/ctcm_main.c b/drivers/s390/net/ctcm_main.c
index 2117870ed855..437a6d822105 100644
--- a/drivers/s390/net/ctcm_main.c
+++ b/drivers/s390/net/ctcm_main.c
@@ -1072,10 +1072,8 @@ static void ctcm_free_netdevice(struct net_device *dev)
if (grp) {
if (grp->fsm)
kfree_fsm(grp->fsm);
- if (grp->xid_skb)
- dev_kfree_skb(grp->xid_skb);
- if (grp->rcvd_xid_skb)
- dev_kfree_skb(grp->rcvd_xid_skb);
+ dev_kfree_skb(grp->xid_skb);
+ dev_kfree_skb(grp->rcvd_xid_skb);
tasklet_kill(&grp->mpc_tasklet2);
kfree(grp);
priv->mpcg = NULL;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v4 net-next 4/6] net: dsa: sja1105: Advertise the 8 TX queues
From: Vladimir Oltean @ 2019-09-15 17:28 UTC (permalink / raw)
To: Jose Abreu
Cc: f.fainelli@gmail.com, vivien.didelot@gmail.com, andrew@lunn.ch,
davem@davemloft.net, vinicius.gomes@intel.com,
vedang.patel@intel.com, richardcochran@gmail.com,
weifeng.voon@intel.com, jiri@mellanox.com, m-karicheri2@ti.com,
ilias.apalodimas@linaro.org, jhs@mojatatu.com,
xiyou.wangcong@gmail.com, kurt.kanzenbach@linutronix.de,
joergen.andreasen@microchip.com, netdev@vger.kernel.org
In-Reply-To: <BN8PR12MB326684898CC3CBC27ABEA4E7D38D0@BN8PR12MB3266.namprd12.prod.outlook.com>
Hi Jose,
On Sun, 15 Sep 2019 at 19:41, Jose Abreu <Jose.Abreu@synopsys.com> wrote:
>
> From: Vladimir Oltean <olteanv@gmail.com>
> Date: Sep/15/2019, 03:00:01 (UTC+00:00)
>
> > Instead of looking directly at skb->priority during xmit, let's get the
> > netdev queue and the queue-to-traffic-class mapping, and put the
> > resulting traffic class into the dsa_8021q PCP field. The switch is
> > configured with a 1-to-1 PCP-to-ingress-queue-to-egress-queue mapping
> > (see vlan_pmap in sja1105_main.c), so the effect is that we can inject
> > into a front-panel's egress traffic class through VLAN tagging from
> > Linux, completely transparently.
>
> Wouldn't it be better to just rely on skb queue mapping as per userspace
> settings ? I mean this way you cant create some complex scenarios
> without having the VLAN ID need.
>
I think I need to clarify the "without having the VLAN ID need" portion.
This is a DSA switch, and the thing that all these switches have in
common is that their data path is connected to the host system through
an Ethernet port pair (as opposed to e.g. DMA and real queues).
When you send a frame from the host through that Ethernet port, the
switch's natural tendency is to forward/flood it according to FDB
rules, which may not be what you want to achieve (i.e. you may want to
xmit on a specific front-panel port only, to achieve a 'port
multiplier' behavior out of it). Switch vendors achieve that by using
a proprietary frame header which indicates stuff such as: egress port,
QoS priority, etc. The host adds this tag to frames sent towards the
switch, and the switch consumes it.
In the case of sja1105, the frame tagging format is actually
'open-spec', e.g. it is an actual VLAN header, just with a custom
EtherType. Hence the QoS priority in this tagging format is the PCP
field. Other DSA switch vendors still have a 'priority' field in their
tagging format, even though it is not PCP.
So to answer your question, I do need VLAN tagging either way, for
even more basic reasons. But it is VLAN only from the switch's
hardware view. From the operating system's view it is no different
than populating the 'priority' field of any other DSA frame tagger.
> I generally use u32 filter and skbedit queue_mapping action to achieve
> this.
>
The trouble with relying on 'queue_mapping' only is that it's too
open-ended: what does a queue really mean for an Ethernet-managed
switch?
In my interpretation of the mqprio/taprio offloads, the netdev queue
is only an intermediary representation between the qdisc and the NIC's
traffic classes. Now that makes sense, because even though the switch
xmit procedure isn't multi-queue, there is still strict egress
prioritization based on the traffic class mapping (inferred from VLAN
PCP).
I have no idea how people are managing multi-queue net devices without
an mqprio-type offload, if those netdev queues are not of equal
priority. Technically, if you use the 'skbedit queue_mapping' action
with this switch, it is your choice how you manage the
net_device->tc_to_txq array, keeping in mind that tc 7 will have
higher priority over tc 6. Alternatively, you can still use an
mqprio-type offload, specify "num_tc 8 map 0 1 2 3 5 6 7 queues 1@0
1@1 1@2 1@3 1@4 1@5 1@6 1@7", and then just use the 'skbedit priority'
action. Then things would just work.
So I am just using the 'queues' term for this switch to express the
strict priority scheduler. There isn't really any benefit to having
more than one netdev queue exposed per traffic class.
> ---
> Thanks,
> Jose Miguel Abreu
Hope this clarifies,
-Vladimir
^ permalink raw reply
* Re: [v3] iproute2-next: police: support 64bit rate and peakrate in tc utility
From: David Ahern @ 2019-09-15 17:37 UTC (permalink / raw)
To: David Dai, jhs, xiyou.wangcong, jiri, netdev, linux-kernel; +Cc: zdai
In-Reply-To: <1567609611-27051-1-git-send-email-zdai@linux.vnet.ibm.com>
On 9/4/19 9:06 AM, David Dai wrote:
> For high speed adapter like Mellanox CX-5 card, it can reach upto
> 100 Gbits per second bandwidth. Currently htb already supports 64bit rate
> in tc utility. However police action rate and peakrate are still limited
> to 32bit value (upto 32 Gbits per second). Taking advantage of the 2 new
> attributes TCA_POLICE_RATE64 and TCA_POLICE_PEAKRATE64 from kernel,
> tc can use them to break the 32bit limit, and still keep the backward
> binary compatibility.
>
> Tested-by: David Dai <zdai@linux.vnet.ibm.com>
> Signed-off-by: David Dai <zdai@linux.vnet.ibm.com>
> ---
> Changelog:
> v1->v2:
> - Change patch submit component from iproute2 to iproute2-next
> - Move 2 attributes TCA_POLICE_RATE64 TCA_POLICE_PEAKRATE64 after
> TCA_POLICE_PAD in pkt_cls.h header to be consistent with kernel's
> pkt_cls.h header.
> v2->v3:
> - Use common functions of duparg and invarg in police filter.
> ---
> include/uapi/linux/pkt_cls.h | 2 +
> tc/m_police.c | 149 +++++++++++++++++++-----------------------
> tc/tc_core.c | 29 ++++++++
> tc/tc_core.h | 3 +
> 4 files changed, 102 insertions(+), 81 deletions(-)
>
applied to iproute2-next.
^ permalink raw reply
* Re: [PATCH iproute2-next] bpf: replace snprintf with asprintf when dealing with long buffers
From: David Ahern @ 2019-09-15 17:45 UTC (permalink / raw)
To: Andrea Claudi, netdev; +Cc: stephen, dsahern
In-Reply-To: <d2631870837a01f1488bf0bd547bb126f24de6b9.1568043463.git.aclaudi@redhat.com>
On 9/9/19 10:05 AM, Andrea Claudi wrote:
> This reduces stack usage, as asprintf allocates memory on the heap.
>
> This indirectly fixes a snprintf truncation warning (from gcc v9.2.1):
>
> bpf.c: In function ‘bpf_get_work_dir’:
> bpf.c:784:49: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=]
> 784 | snprintf(bpf_wrk_dir, sizeof(bpf_wrk_dir), "%s/", mnt);
> | ^
> bpf.c:784:2: note: ‘snprintf’ output between 2 and 4097 bytes into a destination of size 4096
> 784 | snprintf(bpf_wrk_dir, sizeof(bpf_wrk_dir), "%s/", mnt);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Fixes: e42256699cac ("bpf: make tc's bpf loader generic and move into lib")
> Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
> ---
> lib/bpf.c | 95 +++++++++++++++++++++++++++++++++----------------------
> 1 file changed, 57 insertions(+), 38 deletions(-)
>
> diff --git a/lib/bpf.c b/lib/bpf.c
> index 7d2a322ffbaec..18e0334d3f11b 100644
> --- a/lib/bpf.c
> +++ b/lib/bpf.c
> @@ -406,13 +406,14 @@ static int bpf_derive_elf_map_from_fdinfo(int fd, struct bpf_elf_map *map,
> struct bpf_map_ext *ext)
> {
> unsigned int val, owner_type = 0, owner_jited = 0;
> - char file[PATH_MAX], buff[4096];
> + char *file, buff[4096];
> FILE *fp;
>
> - snprintf(file, sizeof(file), "/proc/%d/fdinfo/%d", getpid(), fd);
> + asprintf(&file, "/proc/%d/fdinfo/%d", getpid(), fd);
Thanks for taking this on.
From 'man asprintf':
"If memory allocation wasn't possible, or some other error occurs,
these functions will return -1, and the contents of strp are undefined."
ie., you should check the return code of asprintf and make sure the
pointer passed is always initialized to NULL (static ones do not need
the init).
^ permalink raw reply
* Re: [PATCH iproute2-next] rdma: Check comm string before print in print_comm()
From: David Ahern @ 2019-09-15 17:47 UTC (permalink / raw)
To: Leon Romanovsky, David Ahern
Cc: Mark Zhang, netdev, RDMA mailing list, Stephen Hemminger,
Leon Romanovsky
In-Reply-To: <20190911081243.28917-1-leon@kernel.org>
On 9/11/19 2:12 AM, Leon Romanovsky wrote:
> From: Mark Zhang <markz@mellanox.com>
>
> Broken kernels (not-upstream) can provide wrong empty "comm" field.
> It causes to segfault while printing in JSON format.
>
> Fixes: 8ecac46a60ff ("rdma: Add QP resource tracking information")
that commit is from 2018, so this should go to master; re-assigned in
patchwork.
> Signed-off-by: Mark Zhang <markz@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> rdma/res.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/rdma/res.c b/rdma/res.c
> index 97a7b964..6003006e 100644
> --- a/rdma/res.c
> +++ b/rdma/res.c
> @@ -161,6 +161,9 @@ void print_comm(struct rd *rd, const char *str, struct nlattr **nla_line)
> {
> char tmp[18];
>
> + if (!str)
> + return;
> +
> if (rd->json_output) {
> /* Don't beatify output in JSON format */
> jsonw_string_field(rd->jw, "comm", str);
>
^ permalink raw reply
* Re: [PATCH iproute2-next] devlink: add 'reset_dev_on_drv_probe' devlink param
From: David Ahern @ 2019-09-15 17:50 UTC (permalink / raw)
To: Simon Horman, David Ahern
Cc: Jiri Pirko, netdev, oss-drivers, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190911130517.21986-1-simon.horman@netronome.com>
On 9/11/19 7:05 AM, Simon Horman wrote:
> From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
>
> Add support for the new devlink parameter along with string to uint
> conversion.
>
> Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> ---
> Depends on devlink.h changes present in net-next commit
> 5bbd21df5a07 ("devlink: add 'reset_dev_on_drv_probe' param")
> ---
> devlink/devlink.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
applied to iproute2-next. Thanks
^ permalink raw reply
* Re: [PATCH iproute2-next] devlink: unknown 'fw_load_policy' string validation
From: David Ahern @ 2019-09-15 17:52 UTC (permalink / raw)
To: Simon Horman, David Ahern
Cc: Jiri Pirko, netdev, oss-drivers, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190911145629.28259-1-simon.horman@netronome.com>
On 9/11/19 8:56 AM, Simon Horman wrote:
> From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
>
> The 'fw_load_policy' devlink parameter now supports an unknown value.
>
> Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> ---
>
applied to iproute2-next. Thanks
^ permalink raw reply
* Re: [patch iproute2-next v4 0/2] devlink: couple forgotten flash patches
From: David Ahern @ 2019-09-15 17:58 UTC (permalink / raw)
To: Jiri Pirko, David Ahern
Cc: netdev, stephen, jakub.kicinski, saeedm, mlxsw, f.fainelli
In-Reply-To: <20190914060012.GC2276@nanopsycho.orion>
On 9/14/19 12:00 AM, Jiri Pirko wrote:
> Fri, Sep 13, 2019 at 07:25:07PM CEST, dsahern@gmail.com wrote:
>> On 9/12/19 12:29 PM, Jiri Pirko wrote:
>>> From: Jiri Pirko <jiri@mellanox.com>
>>>
>>> I was under impression they are already merged, but apparently they are
>>> not. I just rebased them on top of current iproute2 net-next tree.
>>>
>>
>> they were not forgotten; they were dropped asking for changes.
>>
>> thread is here:
>> https://lore.kernel.org/netdev/20190604134450.2839-3-jiri@resnulli.us/
>
> Well not really. The path was discussed in the thread. However, that is
> unrelated to the changes these patches do. The flashing itself is
> already there and present. These patches only add status.
>
> Did I missed something?
>
you are thinking like a kernel developer and not a user.
The second patch has a man page change that should state that firmware
files are expected to be in /lib/firmware and that path is added by the
kernel so the path passed on the command line needs to drop that part.
^ permalink raw reply
* Re: [patch iproute2-next] devlink: add reload failed indication
From: David Ahern @ 2019-09-15 18:00 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: dsahern, stephen, idosch, jakub.kicinski, tariqt, mlxsw
In-Reply-To: <20190914065637.27226-1-jiri@resnulli.us>
On 9/14/19 12:56 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
Please add a description here - e.g., what change is there to user output.
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> devlink/devlink.c | 22 +++++++++++++++-------
> include/uapi/linux/devlink.h | 2 ++
> 2 files changed, 17 insertions(+), 7 deletions(-)
>
^ permalink raw reply
* Re: [patch iproute2-next 1/2] devlink: introduce cmdline option to switch to a different namespace
From: David Ahern @ 2019-09-15 18:01 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, idosch, dsahern, jakub.kicinski, tariqt, saeedm, kuznet,
yoshfuji, shuah, mlxsw
In-Reply-To: <20190914065757.27295-1-jiri@resnulli.us>
On 9/14/19 12:57 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
Both of these patches have no commit logs. Please add - e.g., why -N
versus -n that other commands use.
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> v3->v4:
> - rebased on top of trap patches
> ---
> devlink/devlink.c | 12 ++++++++++--
> man/man8/devlink.8 | 4 ++++
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* Re: [PATCH V1 net-next 01/11] net: ena: add intr_moder_rx_interval to struct ena_com_dev and use it
From: David Miller @ 2019-09-15 18:32 UTC (permalink / raw)
To: akiyano
Cc: netdev, dwmw, zorik, matua, saeedb, msw, aliguori, nafea, gtzalik,
netanel, alisaidi, benh, sameehj, ndagan
In-Reply-To: <1568326128-4057-2-git-send-email-akiyano@amazon.com>
From: <akiyano@amazon.com>
Date: Fri, 13 Sep 2019 01:08:38 +0300
> @@ -1307,8 +1304,8 @@ static void ena_com_update_intr_delay_resolution(struct ena_com_dev *ena_dev,
> ena_dev->intr_delay_resolution = intr_delay_resolution;
>
> /* update Rx */
> - for (i = 0; i < ENA_INTR_MAX_NUM_OF_LEVELS; i++)
> - intr_moder_tbl[i].intr_moder_interval /= intr_delay_resolution;
> + ena_dev->intr_moder_rx_interval /= intr_delay_resolution;
> +
>
> /* update Tx */
Now there are two empty lines here, please remove one of them.
^ permalink raw reply
* Re: [PATCH net] net/sched: fix race between deactivation and dequeue for NOLOCK qdisc
From: David Miller @ 2019-09-15 18:37 UTC (permalink / raw)
To: pabeni; +Cc: netdev, dcaratti, shuali
In-Reply-To: <80e0c9577218090cada29e4adc9ec116f591cb6f.1568113414.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Thu, 12 Sep 2019 12:02:42 +0200
> The test implemented by some_qdisc_is_busy() is somewhat loosy for
> NOLOCK qdisc, as we may hit the following scenario:
>
> CPU1 CPU2
> // in net_tx_action()
> clear_bit(__QDISC_STATE_SCHED...);
> // in some_qdisc_is_busy()
> val = (qdisc_is_running(q) ||
> test_bit(__QDISC_STATE_SCHED,
> &q->state));
> // here val is 0 but...
> qdisc_run(q)
> // ... CPU1 is going to run the qdisc next
>
> As a conseguence qdisc_run() in net_tx_action() can race with qdisc_reset()
> in dev_qdisc_reset(). Such race is not possible for !NOLOCK qdisc as
> both the above bit operations are under the root qdisc lock().
>
> After commit 021a17ed796b ("pfifo_fast: drop unneeded additional lock on dequeue")
> the race can cause use after free and/or null ptr dereference, but the root
> cause is likely older.
>
> This patch addresses the issue explicitly checking for deactivation under
> the seqlock for NOLOCK qdisc, so that the qdisc_run() in the critical
> scenario becomes a no-op.
>
> Note that the enqueue() op can still execute concurrently with dev_qdisc_reset(),
> but that is safe due to the skb_array() locking, and we can't avoid that
> for NOLOCK qdiscs.
>
> Fixes: 021a17ed796b ("pfifo_fast: drop unneeded additional lock on dequeue")
> Reported-by: Li Shuang <shuali@redhat.com>
> Reported-and-tested-by: Davide Caratti <dcaratti@redhat.com>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] net: dsa: Fix load order between DSA drivers and taggers
From: David Miller @ 2019-09-15 18:50 UTC (permalink / raw)
To: andrew; +Cc: f.fainelli, vivien.didelot, netdev
In-Reply-To: <20190912131645.24782-1-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Thu, 12 Sep 2019 15:16:45 +0200
> The DSA core, DSA taggers and DSA drivers all make use of
> module_init(). Hence they get initialised at device_initcall() time.
> The ordering is non-deterministic. It can be a DSA driver is bound to
> a device before the needed tag driver has been initialised, resulting
> in the message:
>
> No tagger for this switch
>
> Rather than have this be fatal, return -EPROBE_DEFER so that it is
> tried again later once all the needed drivers have been loaded.
>
> Fixes: d3b8c04988ca ("dsa: Add boilerplate helper to register DSA tag driver modules")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>
> I did wonder if we should play with the core and tag drivers and make
> them use subsystem_initcall(), but EPROBE_DEFER seems to be the more
> preferred solution nowadays.
Yes that does indeed seem preferable these days and all of the init
types is usually quite fragile.
Applied and queued up for v5.2 -stable.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] net: stmmac: socfpga: re-use the `interface` parameter from platform data
From: David Miller @ 2019-09-15 18:51 UTC (permalink / raw)
To: alexandru.ardelean
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel,
peppe.cavallaro, alexandre.torgue, joabreu, mcoquelin.stm32
In-Reply-To: <20190912132850.10585-1-alexandru.ardelean@analog.com>
From: Alexandru Ardelean <alexandru.ardelean@analog.com>
Date: Thu, 12 Sep 2019 16:28:50 +0300
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> index c141fe783e87..5b6213207c43 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
...
> +static inline int socfpga_get_plat_phymode(struct socfpga_dwmac *dwmac)
Please do not use the inline keyword in foo.c files, let the compiler device.
^ permalink raw reply
* Re: [PATCH] net/mlx5: Remove unneeded variable in mlx5_unload_one
From: David Miller @ 2019-09-15 18:53 UTC (permalink / raw)
To: zhongjiang; +Cc: saeedm, netdev, linux-kernel
In-Reply-To: <1568307542-43797-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
Date: Fri, 13 Sep 2019 00:59:02 +0800
> mlx5_unload_one do not need local variable to store different value,
> Hence just remove it.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Saeed, just take this directly via one of your trees.
Thank you.
^ permalink raw reply
* Re: [Patch net v2] net_sched: let qdisc_put() accept NULL pointer
From: David Miller @ 2019-09-15 18:55 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, syzbot+d5870a903591faaca4ae, torvalds, jhs, jiri
In-Reply-To: <20190912172230.9635-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu, 12 Sep 2019 10:22:30 -0700
> When tcf_block_get() fails in sfb_init(), q->qdisc is still a NULL
> pointer which leads to a crash in sfb_destroy(). Similar for
> sch_dsmark.
>
> Instead of fixing each separately, Linus suggested to just accept
> NULL pointer in qdisc_put(), which would make callers easier.
>
> (For sch_dsmark, the bug probably exists long before commit
> 6529eaba33f0.)
>
> Fixes: 6529eaba33f0 ("net: sched: introduce tcf block infractructure")
> Reported-by: syzbot+d5870a903591faaca4ae@syzkaller.appspotmail.com
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] net/rds: Fix 'ib_evt_handler_call' element in 'rds_ib_stat_names'
From: David Miller @ 2019-09-15 18:56 UTC (permalink / raw)
To: gerd.rausch; +Cc: santosh.shilimkar, netdev, linux-rdma, rds-devel
In-Reply-To: <914b48be-2373-5b38-83f5-e0d917dd139d@oracle.com>
From: Gerd Rausch <gerd.rausch@oracle.com>
Date: Thu, 12 Sep 2019 13:49:41 -0700 (PDT)
> All entries in 'rds_ib_stat_names' are stringified versions
> of the corresponding "struct rds_ib_statistics" element
> without the "s_"-prefix.
>
> Fix entry 'ib_evt_handler_call' to do the same.
>
> Fixes: f4f943c958a2 ("RDS: IB: ack more receive completions to improve performance")
> Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] brcmsmac: remove a useless test
From: Christophe JAILLET @ 2019-09-15 19:32 UTC (permalink / raw)
To: arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, kvalo, davem
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
netdev, linux-kernel, kernel-janitors, Christophe JAILLET
'pih' is known to be non-NULL at this point, so the test can be removed.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
index 080e829da9b3..6bb34a12a94b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
@@ -1816,8 +1816,7 @@ void brcms_b_phy_reset(struct brcms_hardware *wlc_hw)
udelay(2);
brcms_b_core_phy_clk(wlc_hw, ON);
- if (pih)
- wlc_phy_anacore(pih, ON);
+ wlc_phy_anacore(pih, ON);
}
/* switch to and initialize new band */
--
2.20.1
^ permalink raw reply related
* Re: [patch net-next 02/15] net: fib_notifier: make FIB notifier per-netns
From: David Ahern @ 2019-09-15 20:05 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, idosch, jakub.kicinski, tariqt, saeedm, kuznet, yoshfuji,
shuah, mlxsw
In-Reply-To: <20190914064608.26799-3-jiri@resnulli.us>
On 9/14/19 12:45 AM, Jiri Pirko wrote:
> #define FIB_DUMP_MAX_RETRIES 5
> -int register_fib_notifier(struct notifier_block *nb,
> +int register_fib_notifier(struct net *net, struct notifier_block *nb,
> void (*cb)(struct notifier_block *nb))
> {
> int retries = 0;
> int err;
>
> do {
> - unsigned int fib_seq = fib_seq_sum();
> - struct net *net;
> -
> - rcu_read_lock();
> - for_each_net_rcu(net) {
> - err = fib_net_dump(net, nb);
> - if (err)
> - goto err_fib_net_dump;
> - }
> - rcu_read_unlock();
> -
> - if (fib_dump_is_consistent(nb, cb, fib_seq))
> + unsigned int fib_seq = fib_seq_sum(net);
> +
> + err = fib_net_dump(net, nb);
> + if (err)
> + return err;
> +
> + if (fib_dump_is_consistent(net, nb, cb, fib_seq))
> return 0;
> } while (++retries < FIB_DUMP_MAX_RETRIES);
This is still more complicated than it needs to be. Why lump all
fib_notifier_ops into 1 dump when they are separate databases with
separate seq numbers? Just dump them 1 at a time and retry that 1
database as needed.
ie., This:
list_for_each_entry_rcu(ops, &net->fib_notifier_ops, list) {
should be in register_fib_notifier and not fib_net_dump.
as it stands you are potentially replaying way more than is needed when
a dump is inconsistent.
>
> return -EBUSY;
> -
> -err_fib_net_dump:
> - rcu_read_unlock();
> - return err;
> }
> EXPORT_SYMBOL(register_fib_notifier);
>
> -int unregister_fib_notifier(struct notifier_block *nb)
> +int unregister_fib_notifier(struct net *net, struct notifier_block *nb)
> {
> - return atomic_notifier_chain_unregister(&fib_chain, nb);
> + struct fib_notifier_net *fn_net = net_generic(net, fib_notifier_net_id);
> +
> + return atomic_notifier_chain_unregister(&fn_net->fib_chain, nb);
> }
> EXPORT_SYMBOL(unregister_fib_notifier);
>
^ permalink raw reply
* linux-next: manual merge of the net-next tree with Linus' tree
From: Mark Brown @ 2019-09-15 20:24 UTC (permalink / raw)
To: Mario Limonciello, Marcel Holtmann, Alex Lu, David Miller,
Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/bluetooth/btusb.c
between commit:
1ffdb51f28e8ec ("Revert "Bluetooth: btusb: driver to enable the usb-wakeup feature"")
from Linus' tree and commit:
9e45524a011107 ("Bluetooth: btusb: Fix suspend issue for Realtek devices")
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.
diff --cc drivers/bluetooth/btusb.c
index ba41490543040,ed455de598eae..0000000000000
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@@ -1173,7 -1201,18 +1204,14 @@@ static int btusb_open(struct hci_dev *h
}
data->intf->needs_remote_wakeup = 1;
- /* device specific wakeup source enabled and required for USB
- * remote wakeup while host is suspended
- */
- device_wakeup_enable(&data->udev->dev);
+ /* Disable device remote wakeup when host is suspended
+ * For Realtek chips, global suspend without
+ * SET_FEATURE (DEVICE_REMOTE_WAKEUP) can save more power in device.
+ */
+ if (test_bit(BTUSB_WAKEUP_DISABLE, &data->flags))
+ device_wakeup_disable(&data->udev->dev);
+
if (test_and_set_bit(BTUSB_INTR_RUNNING, &data->flags))
goto done;
@@@ -1237,6 -1276,12 +1275,11 @@@ static int btusb_close(struct hci_dev *
goto failed;
data->intf->needs_remote_wakeup = 0;
+
+ /* Enable remote wake up for auto-suspend */
+ if (test_bit(BTUSB_WAKEUP_DISABLE, &data->flags))
+ data->intf->needs_remote_wakeup = 1;
+
- device_wakeup_disable(&data->udev->dev);
usb_autopm_put_interface(data->intf);
failed:
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the net-next tree with Linus' tree
From: Mark Brown @ 2019-09-15 20:31 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
between commit:
bf280c0387ebbf8ee ("ixgbe: fix double clean of Tx descriptors with xdp")
from Linus' tree and commit:
5c129241e2de79f09 ("ixgbe: add support for AF_XDP need_wakeup feature")
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.
diff --cc drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
index a3b6d8c89127f,ad802a8909e0d..0000000000000
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
@@@ -682,10 -697,19 +691,17 @@@ bool ixgbe_clean_xdp_tx_irq(struct ixgb
if (xsk_frames)
xsk_umem_complete_tx(umem, xsk_frames);
+ if (xsk_umem_uses_need_wakeup(tx_ring->xsk_umem)) {
+ if (tx_ring->next_to_clean == tx_ring->next_to_use)
+ xsk_set_tx_need_wakeup(tx_ring->xsk_umem);
+ else
+ xsk_clear_tx_need_wakeup(tx_ring->xsk_umem);
+ }
+
- xmit_done = ixgbe_xmit_zc(tx_ring, q_vector->tx.work_limit);
-
- return budget > 0 && xmit_done;
+ return ixgbe_xmit_zc(tx_ring, q_vector->tx.work_limit);
}
- int ixgbe_xsk_async_xmit(struct net_device *dev, u32 qid)
+ int ixgbe_xsk_wakeup(struct net_device *dev, u32 qid, u32 flags)
{
struct ixgbe_adapter *adapter = netdev_priv(dev);
struct ixgbe_ring *ring;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] net/wan: dscc4: remove broken dscc4 driver
From: Francois Romieu @ 2019-09-15 23:06 UTC (permalink / raw)
To: Dan Carpenter; +Cc: David S. Miller, netdev, kernel-janitors
In-Reply-To: <20190913132817.GA13179@mwanda>
Dan Carpenter <dan.carpenter@oracle.com> :
> Using static analysis, I discovered that the "dpriv->pci_priv->pdev"
> pointer is always NULL. This pointer was supposed to be initialized
> during probe and is essential for the driver to work. It would be easy
> to add a "ppriv->pdev = pdev;" to dscc4_found1() but this driver has
> been broken since before we started using git and no one has complained
> so probably we should just remove it.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
--
Ueimor
^ permalink raw reply
* Re: rt_uses_gateway was removed?
From: David Ahern @ 2019-09-16 0:05 UTC (permalink / raw)
To: Julian Anastasov; +Cc: netdev, Ido Schimmel
In-Reply-To: <alpine.LFD.2.21.1909151104060.2546@ja.home.ssi.bg>
On 9/15/19 3:08 AM, Julian Anastasov wrote:
> Now I see commit 1550c171935d wrongly changes that to
> "If rt_gw_family is set it implies rt_uses_gateway.".
> As result, we set rt_gw_family while rt_uses_gateway was 0
> for above cases. Think about it in this way: there should be
> a reason why we used rt_uses_gateway flag instead a simple
> "rt_gateway != 0" check, right?
>
> Replacing rt->rt_gateway checks with rt_gw_family
> checks is right but rt_uses_gateway checks should be put
> back because they indicates the route has more hops to
> target.
>
> As the problem is related to some FNHW and non-cached
> routes, redirects, etc the easiest way to see the problem is with
> 'ip route get LOCAL_IP oif eth0' where extra 'via GW' line is
> shown.
Hi Julian:
Thanks for the detailed report. Yes, I misunderstood the subtle point of
rt_uses_gateway. I will look at a fix this week.
David
^ permalink raw reply
* [PATCH] netfilter: bridge: drop a broken include
From: Adam Borowski @ 2019-09-16 0:05 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
Roopa Prabhu, Nikolay Aleksandrov, netfilter-devel, coreteam,
netdev
Cc: Adam Borowski
This caused a build failure if CONFIG_NF_CONNTRACK_BRIDGE is set but
CONFIG_NF_TABLES=n -- and appears to be unused anyway.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
net/bridge/netfilter/nf_conntrack_bridge.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/bridge/netfilter/nf_conntrack_bridge.c b/net/bridge/netfilter/nf_conntrack_bridge.c
index 4f5444d2a526..844ef5a53f87 100644
--- a/net/bridge/netfilter/nf_conntrack_bridge.c
+++ b/net/bridge/netfilter/nf_conntrack_bridge.c
@@ -18,7 +18,6 @@
#include <linux/netfilter/nf_tables.h>
#include <net/netfilter/ipv6/nf_defrag_ipv6.h>
-#include <net/netfilter/nf_tables.h>
#include "../br_private.h"
--
2.23.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