* [PATCH v1] stmmac: platform: adjust messages and move to dev level
From: Andy Shevchenko @ 2019-09-05 13:00 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, netdev,
Maxime Coquelin, linux-stm32, David S . Miller
Cc: Andy Shevchenko
This patch amends the error and warning messages across the platform driver.
It includes the following changes:
- append \n to the end of messages
- change pr_* macros to dev_*
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
.../ethernet/stmicro/stmmac/stmmac_platform.c | 22 +++++++++++--------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 154daf4d1072..1da461907114 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -23,6 +23,7 @@
/**
* dwmac1000_validate_mcast_bins - validates the number of Multicast filter bins
+ * @dev: struct device of the platform device
* @mcast_bins: Multicast filtering bins
* Description:
* this function validates the number of Multicast filtering bins specified
@@ -33,7 +34,7 @@
* invalid and will cause the filtering algorithm to use Multicast
* promiscuous mode.
*/
-static int dwmac1000_validate_mcast_bins(int mcast_bins)
+static int dwmac1000_validate_mcast_bins(struct device *dev, int mcast_bins)
{
int x = mcast_bins;
@@ -44,8 +45,8 @@ static int dwmac1000_validate_mcast_bins(int mcast_bins)
break;
default:
x = 0;
- pr_info("Hash table entries set to unexpected value %d",
- mcast_bins);
+ dev_info(dev, "Hash table entries set to unexpected value %d\n",
+ mcast_bins);
break;
}
return x;
@@ -53,6 +54,7 @@ static int dwmac1000_validate_mcast_bins(int mcast_bins)
/**
* dwmac1000_validate_ucast_entries - validate the Unicast address entries
+ * @dev: struct device of the platform device
* @ucast_entries: number of Unicast address entries
* Description:
* This function validates the number of Unicast address entries supported
@@ -62,7 +64,8 @@ static int dwmac1000_validate_mcast_bins(int mcast_bins)
* selected, and defaults to 1 Unicast address if an unsupported
* configuration is selected.
*/
-static int dwmac1000_validate_ucast_entries(int ucast_entries)
+static int dwmac1000_validate_ucast_entries(struct device *dev,
+ int ucast_entries)
{
int x = ucast_entries;
@@ -73,8 +76,8 @@ static int dwmac1000_validate_ucast_entries(int ucast_entries)
break;
default:
x = 1;
- pr_info("Unicast table entries set to unexpected value %d\n",
- ucast_entries);
+ dev_info(dev, "Unicast table entries set to unexpected value %d\n",
+ ucast_entries);
break;
}
return x;
@@ -457,9 +460,9 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
of_property_read_u32(np, "snps,perfect-filter-entries",
&plat->unicast_filter_entries);
plat->unicast_filter_entries = dwmac1000_validate_ucast_entries(
- plat->unicast_filter_entries);
+ &pdev->dev, plat->unicast_filter_entries);
plat->multicast_filter_bins = dwmac1000_validate_mcast_bins(
- plat->multicast_filter_bins);
+ &pdev->dev, plat->multicast_filter_bins);
plat->has_gmac = 1;
plat->pmt = 1;
}
@@ -508,7 +511,8 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
plat->force_thresh_dma_mode = of_property_read_bool(np, "snps,force_thresh_dma_mode");
if (plat->force_thresh_dma_mode) {
plat->force_sf_dma_mode = 0;
- pr_warn("force_sf_dma_mode is ignored if force_thresh_dma_mode is set.");
+ dev_warn(&pdev->dev,
+ "force_sf_dma_mode is ignored if force_thresh_dma_mode is set.\n");
}
of_property_read_u32(np, "snps,ps-speed", &plat->mac_port_sel_speed);
--
2.23.0.rc1
^ permalink raw reply related
* IPv6 temporary addresses (Fwd: New Version Notification for draft-ietf-6man-rfc4941bis-03.txt)
From: Fernando Gont @ 2019-09-05 12:56 UTC (permalink / raw)
To: netdev
In-Reply-To: <156768734939.22666.4804883631217307240.idtracker@ietfa.amsl.com>
Folks,
We are working in a revision of RFC4941 (temporary addresses), to
address issues found in such spec -- for example, RFC4941 leads to the
same interface identifiers being employed for different prefixes (which
of course has privacy implications)
The current version of the revised spec is available at:
https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis
We'd really like to hear your comments and double-check if we got
everything right, if there's something that we missed, etc.
If possible, please post your feedback on the 6man list
(https://www.ietf.org/mailman/listinfo/ipv6). But I'll be happy to
receive comments here or unicast and relay them as necessary.
Thanks!
Cheers,
Fernando
-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-6man-rfc4941bis-03.txt
Date: Thu, 05 Sep 2019 05:42:29 -0700
From: internet-drafts@ietf.org
To: Fernando Gont <fgont@si6networks.com>, Suresh Krishnan
<suresh.krishnan@ericsson.com>, Richard Draves <richdr@microsoft.com>,
Thomas Narten <narten@us.ibm.com>
A new version of I-D, draft-ietf-6man-rfc4941bis-03.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.
Name: draft-ietf-6man-rfc4941bis
Revision: 03
Title: Privacy Extensions for Stateless Address Autoconfiguration in IPv6
Document date: 2019-09-05
Group: 6man
Pages: 21
URL:
https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4941bis-03.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/
Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis-03
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc4941bis
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4941bis-03
Abstract:
Nodes use IPv6 stateless address autoconfiguration to generate
addresses using a combination of locally available information and
information advertised by routers. Addresses are formed by combining
network prefixes with an interface identifier. This document
describes an extension that causes nodes to generate global scope
addresses with randomized interface identifiers that change over
time. Changing global scope addresses over time makes it more
difficult for eavesdroppers and other information collectors to
identify when different addresses used in different transactions
actually correspond to the same node. This document formally
obsoletes RFC4941.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
^ permalink raw reply
* Re: [PATCH bpf-next] i40e: fix xdp handle calculations
From: Daniel Borkmann @ 2019-09-05 13:13 UTC (permalink / raw)
To: Kevin Laatz, netdev, ast, bjorn.topel, magnus.karlsson,
jonathan.lemon
Cc: bruce.richardson, ciara.loftus, bpf, intel-wired-lan
In-Reply-To: <20190905011144.3513-1-kevin.laatz@intel.com>
On 9/5/19 3:11 AM, Kevin Laatz wrote:
> Currently, we don't add headroom to the handle in i40e_zca_free,
> i40e_alloc_buffer_slow_zc and i40e_alloc_buffer_zc. The addition of the
> headroom to the handle was removed in
> commit 2f86c806a8a8 ("i40e: modify driver for handling offsets"), which
> will break things when headroom is non-zero. This patch fixes this and uses
> xsk_umem_adjust_offset to add it appropritely based on the mode being run.
>
> Fixes: 2f86c806a8a8 ("i40e: modify driver for handling offsets")
> Reported-by: Bjorn Topel <bjorn.topel@intel.com>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH bpf-next] ixgbe: fix xdp handle calculations
From: Daniel Borkmann @ 2019-09-05 13:13 UTC (permalink / raw)
To: Kevin Laatz, netdev, ast, bjorn.topel, magnus.karlsson,
jonathan.lemon
Cc: bruce.richardson, ciara.loftus, bpf, intel-wired-lan
In-Reply-To: <20190905011217.3567-1-kevin.laatz@intel.com>
On 9/5/19 3:12 AM, Kevin Laatz wrote:
> Currently, we don't add headroom to the handle in ixgbe_zca_free,
> ixgbe_alloc_buffer_slow_zc and ixgbe_alloc_buffer_zc. The addition of the
> headroom to the handle was removed in
> commit d8c3061e5edd ("ixgbe: modify driver for handling offsets"), which
> will break things when headroom isvnon-zero. This patch fixes this and uses
> xsk_umem_adjust_offset to add it appropritely based on the mode being run.
>
> Fixes: d8c3061e5edd ("ixgbe: modify driver for handling offsets")
> Reported-by: Bjorn Topel <bjorn.topel@intel.com>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: precision tracking tests
From: Daniel Borkmann @ 2019-09-05 13:13 UTC (permalink / raw)
To: Alexei Starovoitov, davem; +Cc: netdev, bpf, kernel-team
In-Reply-To: <20190903225133.821243-1-ast@kernel.org>
On 9/4/19 12:51 AM, Alexei Starovoitov wrote:
> Add two tests to check that stack slot marking during backtracking
> doesn't trigger 'spi > allocated_stack' warning.
> One test is using BPF_ST insn. Another is using BPF_STX.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH bpf-next v3 0/4] xsk: various CPU barrier and {READ, WRITE}_ONCE
From: Daniel Borkmann @ 2019-09-05 13:14 UTC (permalink / raw)
To: Björn Töpel, ast, netdev
Cc: magnus.karlsson, magnus.karlsson, bpf, bjorn.topel,
jonathan.lemon, syzbot+c82697e3043781e08802, hdanton, i.maximets
In-Reply-To: <20190904114913.17217-1-bjorn.topel@gmail.com>
On 9/4/19 1:49 PM, Björn Töpel wrote:
> This is a four patch series of various barrier, {READ, WRITE}_ONCE
> cleanups in the AF_XDP socket code. More details can be found in the
> corresponding commit message. Previous revisions: v1 [4] and v2 [5].
>
> For an AF_XDP socket, most control plane operations are done under the
> control mutex (struct xdp_sock, mutex), but there are some places
> where members of the struct is read outside the control mutex. The
> dev, queue_id members are set in bind() and cleared at cleanup. The
> umem, fq, cq, tx, rx, and state member are all assigned in various
> places, e.g. bind() and setsockopt(). When the members are assigned,
> they are protected by the control mutex, but since they are read
> outside the mutex, a WRITE_ONCE is required to avoid store-tearing on
> the read-side.
>
> Prior the state variable was introduced by Ilya, the dev member was
> used to determine whether the socket was bound or not. However, when
> dev was read, proper SMP barriers and READ_ONCE were missing. In order
> to address the missing barriers and READ_ONCE, we start using the
> state variable as a point of synchronization. The state member
> read/write is paired with proper SMP barriers, and from this follows
> that the members described above does not need READ_ONCE statements if
> used in conjunction with state check.
>
> To summarize: The members struct xdp_sock members dev, queue_id, umem,
> fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
> and missing {READ, WRITE}_ONCE. After this series umem, fq, cq, tx,
> rx, and state are read lock-less. When these members are updated,
> WRITE_ONCE is used. When read, READ_ONCE are only used when read
> outside the control mutex (e.g. mmap) or, not synchronized with the
> state member (XSK_BOUND plus smp_rmb())
>
> Thanks,
> Björn
>
> [1] https://lore.kernel.org/bpf/beef16bb-a09b-40f1-7dd0-c323b4b89b17@iogearbox.net/
> [2] https://lwn.net/Articles/793253/
> [3] https://github.com/google/ktsan/wiki/READ_ONCE-and-WRITE_ONCE
> [4] https://lore.kernel.org/bpf/20190822091306.20581-1-bjorn.topel@gmail.com/
> [5] https://lore.kernel.org/bpf/20190826061053.15996-1-bjorn.topel@gmail.com/
>
> v2->v3:
> Minor restructure of commits.
> Improve cover and commit messages. (Daniel)
> v1->v2:
> Removed redundant dev check. (Jonathan)
>
> Björn Töpel (4):
> xsk: avoid store-tearing when assigning queues
> xsk: avoid store-tearing when assigning umem
> xsk: use state member for socket synchronization
> xsk: lock the control mutex in sock_diag interface
>
> net/xdp/xsk.c | 60 ++++++++++++++++++++++++++++++++--------------
> net/xdp/xsk_diag.c | 3 +++
> 2 files changed, 45 insertions(+), 18 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH bpf] bpf: fix precision tracking of stack slots
From: Daniel Borkmann @ 2019-09-05 13:15 UTC (permalink / raw)
To: Alexei Starovoitov, davem; +Cc: netdev, bpf, kernel-team
In-Reply-To: <20190903221617.635375-1-ast@kernel.org>
On 9/4/19 12:16 AM, Alexei Starovoitov wrote:
> The problem can be seen in the following two tests:
> 0: (bf) r3 = r10
> 1: (55) if r3 != 0x7b goto pc+0
> 2: (7a) *(u64 *)(r3 -8) = 0
> 3: (79) r4 = *(u64 *)(r10 -8)
> ..
> 0: (85) call bpf_get_prandom_u32#7
> 1: (bf) r3 = r10
> 2: (55) if r3 != 0x7b goto pc+0
> 3: (7b) *(u64 *)(r3 -8) = r0
> 4: (79) r4 = *(u64 *)(r10 -8)
>
> When backtracking need to mark R4 it will mark slot fp-8.
> But ST or STX into fp-8 could belong to the same block of instructions.
> When backtracing is done the parent state may have fp-8 slot
> as "unallocated stack". Which will cause verifier to warn
> and incorrectly reject such programs.
>
> Writes into stack via non-R10 register are rare. llvm always
> generates canonical stack spill/fill.
> For such pathological case fall back to conservative precision
> tracking instead of rejecting.
>
> Reported-by: syzbot+c8d66267fd2b5955287e@syzkaller.appspotmail.com
> Fixes: b5dc0163d8fd ("bpf: precise scalar_value tracking")
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH REPOST 1/2] can: flexcan: fix deadlock when using self wakeup
From: Sean Nyekjaer @ 2019-09-05 13:17 UTC (permalink / raw)
To: Joakim Zhang, mkl@pengutronix.de, linux-can@vger.kernel.org
Cc: wg@grandegger.com, netdev@vger.kernel.org, dl-linux-imx,
Martin Hundebøll
In-Reply-To: <DB7PR04MB461868320DA0B25CC8255213E6BB0@DB7PR04MB4618.eurprd04.prod.outlook.com>
On 05/09/2019 09.10, Joakim Zhang wrote:
> Hi Sean,
>
> Could you update lastest flexcan driver using linux-can-next/flexcan and then merge below two patches from linux-can/testing?
> d0b53616716e (HEAD -> testing, origin/testing) can: flexcan: add LPSR mode support for i.MX7D
> 803eb6bad65b can: flexcan: fix deadlock when using self wakeup
>
> Best Regards,
> Joakim Zhang
The testing branch have some UBI bugs, when suspending it crashes...
So will have to leave this, until they are resolved :-)
/Sean
^ permalink raw reply
* RE: [PATCH net] net: sched: fix reordering issues
From: John Fastabend @ 2019-09-05 13:27 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller
Cc: netdev, Eric Dumazet, Eric Dumazet, John Fastabend
In-Reply-To: <20190905122022.106680-1-edumazet@google.com>
Eric Dumazet wrote:
> Whenever MQ is not used on a multiqueue device, we experience
> serious reordering problems. Bisection found the cited
> commit.
>
> The issue can be described this way :
>
> - A single qdisc hierarchy is shared by all transmit queues.
> (eg : tc qdisc replace dev eth0 root fq_codel)
>
> - When/if try_bulk_dequeue_skb_slow() dequeues a packet targetting
> a different transmit queue than the one used to build a packet train,
> we stop building the current list and save the 'bad' skb (P1) in a
> special queue. (bad_txq)
>
> - When dequeue_skb() calls qdisc_dequeue_skb_bad_txq() and finds this
> skb (P1), it checks if the associated transmit queues is still in frozen
> state. If the queue is still blocked (by BQL or NIC tx ring full),
> we leave the skb in bad_txq and return NULL.
>
> - dequeue_skb() calls q->dequeue() to get another packet (P2)
>
> The other packet can target the problematic queue (that we found
> in frozen state for the bad_txq packet), but another cpu just ran
> TX completion and made room in the txq that is now ready to accept
> new packets.
>
> - Packet P2 is sent while P1 is still held in bad_txq, P1 might be sent
> at next round. In practice P2 is the lead of a big packet train
> (P2,P3,P4 ...) filling the BQL budget and delaying P1 by many packets :/
>
> To solve this problem, we have to block the dequeue process as long
> as the first packet in bad_txq can not be sent. Reordering issues
> disappear and no side effects have been seen.
>
> Fixes: a53851e2c321 ("net: sched: explicit locking in gso_cpu fallback")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: John Fastabend <john.fastabend@gmail.com>
> ---
> net/sched/sch_generic.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
Dang, missed this case. Thanks!
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* [PATCH V2 net-next 0/7] net: hns3: add some bugfixes and cleanups
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Huazhong Tan
This patch-set includes bugfixes and cleanups for the HNS3
ethernet controller driver.
[patch 01/07] fixes an error when setting VLAN offload.
[patch 02/07] fixes an double free issue when setting ringparam.
[patch 03/07] fixes a mis-assignment of hdev->reset_level.
[patch 04/07] adds a checking for client's validity.
[patch 05/07] simplifies bool variable's assignment.
[patch 06/07] disables loopback when initializing.
[patch 07/07] makes internal function to static.
Change log:
V1->V2: fixes comment from Sergei Shtylyov.
Guojia Liao (2):
net: hns3: remove explicit conversion to bool
net: hns3: make hclge_dbg_get_m7_stats_info static
Huazhong Tan (2):
net: hns3: fix double free bug when setting ringparam
net: hns3: fix mis-assignment to hdev->reset_level in hclge_reset
Jian Shen (1):
net: hns3: fix error VF index when setting VLAN offload
Peng Li (1):
net: hns3: add client node validity judgment
Yufeng Mo (1):
net: hns3: disable loopback setting in hclge_mac_init
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 16 ++++++
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 4 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 2 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 59 ++++++++++++++++++----
4 files changed, 69 insertions(+), 12 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH V2 net-next 6/7] net: hns3: disable loopback setting in hclge_mac_init
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Yufeng Mo, Huazhong Tan
In-Reply-To: <1567690302-16648-1-git-send-email-tanhuazhong@huawei.com>
From: Yufeng Mo <moyufeng@huawei.com>
If the selftest and reset are performed at the same time, the loopback
setting may be still in the enable state after the reset. As a result,
packets cannot be sent out.
This patch fixes this issue by disabling loopback in hclge_mac_init.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 34 +++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index dde752f..8d4dc1b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -66,6 +66,7 @@ static void hclge_rfs_filter_expire(struct hclge_dev *hdev);
static void hclge_clear_arfs_rules(struct hnae3_handle *handle);
static enum hnae3_reset_type hclge_get_reset_level(struct hnae3_ae_dev *ae_dev,
unsigned long *addr);
+static int hclge_set_default_loopback(struct hclge_dev *hdev);
static struct hnae3_ae_algo ae_algo;
@@ -2599,6 +2600,10 @@ static int hclge_mac_init(struct hclge_dev *hdev)
return ret;
}
+ ret = hclge_set_default_loopback(hdev);
+ if (ret)
+ return ret;
+
ret = hclge_buffer_alloc(hdev);
if (ret)
dev_err(&hdev->pdev->dev,
@@ -6331,7 +6336,7 @@ static int hclge_set_app_loopback(struct hclge_dev *hdev, bool en)
return ret;
}
-static int hclge_set_serdes_loopback(struct hclge_dev *hdev, bool en,
+static int hclge_cfg_serdes_loopback(struct hclge_dev *hdev, bool en,
enum hnae3_loop loop_mode)
{
#define HCLGE_SERDES_RETRY_MS 10
@@ -6392,6 +6397,17 @@ static int hclge_set_serdes_loopback(struct hclge_dev *hdev, bool en,
dev_err(&hdev->pdev->dev, "serdes loopback set failed in fw\n");
return -EIO;
}
+ return ret;
+}
+
+static int hclge_set_serdes_loopback(struct hclge_dev *hdev, bool en,
+ enum hnae3_loop loop_mode)
+{
+ int ret;
+
+ ret = hclge_cfg_serdes_loopback(hdev, en, loop_mode);
+ if (ret)
+ return ret;
hclge_cfg_mac_mode(hdev, en);
@@ -6535,6 +6551,22 @@ static int hclge_set_loopback(struct hnae3_handle *handle,
return 0;
}
+static int hclge_set_default_loopback(struct hclge_dev *hdev)
+{
+ int ret;
+
+ ret = hclge_set_app_loopback(hdev, false);
+ if (ret)
+ return ret;
+
+ ret = hclge_cfg_serdes_loopback(hdev, false, HNAE3_LOOP_SERIAL_SERDES);
+ if (ret)
+ return ret;
+
+ return hclge_cfg_serdes_loopback(hdev, false,
+ HNAE3_LOOP_PARALLEL_SERDES);
+}
+
static void hclge_reset_tqp_stats(struct hnae3_handle *handle)
{
struct hclge_vport *vport = hclge_get_vport(handle);
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 4/7] net: hns3: add client node validity judgment
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Peng Li, Huazhong Tan
In-Reply-To: <1567690302-16648-1-git-send-email-tanhuazhong@huawei.com>
From: Peng Li <lipeng321@huawei.com>
HNS3 driver can only unregister client which included in hnae3_client_list.
This patch adds the client node validity judgment.
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index 528f624..03ca7d9 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -138,12 +138,28 @@ EXPORT_SYMBOL(hnae3_register_client);
void hnae3_unregister_client(struct hnae3_client *client)
{
+ struct hnae3_client *client_tmp;
struct hnae3_ae_dev *ae_dev;
+ bool existed = false;
if (!client)
return;
mutex_lock(&hnae3_common_lock);
+
+ list_for_each_entry(client_tmp, &hnae3_client_list, node) {
+ if (client_tmp->type == client->type) {
+ existed = true;
+ break;
+ }
+ }
+
+ if (!existed) {
+ mutex_unlock(&hnae3_common_lock);
+ pr_err("client %s does not exist!\n", client->name);
+ return;
+ }
+
/* un-initialize the client on every matched port */
list_for_each_entry(ae_dev, &hnae3_ae_dev_list, node) {
hnae3_uninit_client_instance(client, ae_dev);
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 7/7] net: hns3: make hclge_dbg_get_m7_stats_info static
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Guojia Liao, Huazhong Tan
In-Reply-To: <1567690302-16648-1-git-send-email-tanhuazhong@huawei.com>
From: Guojia Liao <liaoguojia@huawei.com>
hclge_dbg_get_m7_info is used only in the hclge_debugfs.c,
so it should be declared with static.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
index 1c6b501..6dcce48 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
@@ -949,7 +949,7 @@ static void hclge_dbg_dump_rst_info(struct hclge_dev *hdev)
hdev->rst_stats.reset_cnt);
}
-void hclge_dbg_get_m7_stats_info(struct hclge_dev *hdev)
+static void hclge_dbg_get_m7_stats_info(struct hclge_dev *hdev)
{
struct hclge_desc *desc_src, *desc_tmp;
struct hclge_get_m7_bd_cmd *req;
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 5/7] net: hns3: remove explicit conversion to bool
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Guojia Liao, Huazhong Tan
In-Reply-To: <1567690302-16648-1-git-send-email-tanhuazhong@huawei.com>
From: Guojia Liao <liaoguojia@huawei.com>
Relational and logical operators evaluate to bool,
explicit conversion is overly verbose and unnecessary.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 76e1c84..dde752f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -6174,7 +6174,7 @@ static void hclge_enable_fd(struct hnae3_handle *handle, bool enable)
bool clear;
hdev->fd_en = enable;
- clear = hdev->fd_active_type == HCLGE_FD_ARFS_ACTIVE ? true : false;
+ clear = hdev->fd_active_type == HCLGE_FD_ARFS_ACTIVE;
if (!enable)
hclge_del_all_fd_entries(handle, clear);
else
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 1/7] net: hns3: fix error VF index when setting VLAN offload
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Jian Shen, Huazhong Tan
In-Reply-To: <1567690302-16648-1-git-send-email-tanhuazhong@huawei.com>
From: Jian Shen <shenjian15@huawei.com>
In original codes, the VF index used incorrectly in function
hclge_set_vlan_rx_offload_cfg() and hclge_set_vlan_rx_offload_cfg().
When VF id is greater than 8, for example 9, it will set the
same bit with VF id 1.
This patch fixes it by using vport->vport_id % HCLGE_VF_NUM_PER_CMD /
HCLGE_VF_NUM_PER_BYTE as the array index, instead of vport->vport_id /
HCLGE_VF_NUM_PER_CMD.
Fixes: 052ece6dc19c ("net: hns3: add ethtool related offload command")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 2b65f27..0e1225c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -7691,6 +7691,7 @@ static int hclge_set_vlan_tx_offload_cfg(struct hclge_vport *vport)
struct hclge_vport_vtag_tx_cfg_cmd *req;
struct hclge_dev *hdev = vport->back;
struct hclge_desc desc;
+ u16 bmap_index;
int status;
hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_VLAN_PORT_TX_CFG, false);
@@ -7713,8 +7714,10 @@ static int hclge_set_vlan_tx_offload_cfg(struct hclge_vport *vport)
hnae3_set_bit(req->vport_vlan_cfg, HCLGE_CFG_NIC_ROCE_SEL_B, 0);
req->vf_offset = vport->vport_id / HCLGE_VF_NUM_PER_CMD;
- req->vf_bitmap[req->vf_offset] =
- 1 << (vport->vport_id % HCLGE_VF_NUM_PER_BYTE);
+ bmap_index = vport->vport_id % HCLGE_VF_NUM_PER_CMD /
+ HCLGE_VF_NUM_PER_BYTE;
+ req->vf_bitmap[bmap_index] =
+ 1U << (vport->vport_id % HCLGE_VF_NUM_PER_BYTE);
status = hclge_cmd_send(&hdev->hw, &desc, 1);
if (status)
@@ -7731,6 +7734,7 @@ static int hclge_set_vlan_rx_offload_cfg(struct hclge_vport *vport)
struct hclge_vport_vtag_rx_cfg_cmd *req;
struct hclge_dev *hdev = vport->back;
struct hclge_desc desc;
+ u16 bmap_index;
int status;
hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_VLAN_PORT_RX_CFG, false);
@@ -7746,8 +7750,10 @@ static int hclge_set_vlan_rx_offload_cfg(struct hclge_vport *vport)
vcfg->vlan2_vlan_prionly ? 1 : 0);
req->vf_offset = vport->vport_id / HCLGE_VF_NUM_PER_CMD;
- req->vf_bitmap[req->vf_offset] =
- 1 << (vport->vport_id % HCLGE_VF_NUM_PER_BYTE);
+ bmap_index = vport->vport_id % HCLGE_VF_NUM_PER_CMD /
+ HCLGE_VF_NUM_PER_BYTE;
+ req->vf_bitmap[bmap_index] =
+ 1U << (vport->vport_id % HCLGE_VF_NUM_PER_BYTE);
status = hclge_cmd_send(&hdev->hw, &desc, 1);
if (status)
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 2/7] net: hns3: fix double free bug when setting ringparam
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Huazhong Tan
In-Reply-To: <1567690302-16648-1-git-send-email-tanhuazhong@huawei.com>
The system will panic when change the ringparam in HNS3 drivers:
[ 1459.627727] hns3 0000:bd:00.0 eth6: Changing Tx/Rx ring ds from 1024/1024 to 24/24
[ 1459.635766] hns3 0000:bd:00.0 eth6: link down
[ 1459.640788] BUG: Bad page state in process ethtool pfn:203f75c18
[ 1459.646940] page:ffff7ee4ffd70600 refcount:0 mapcount:0 mapping:ffff993fff40f400 index:0x0 compound_mapcount: 0
[ 1459.656987] flags: 0x9fffe00000010200(slab|head)
[ 1459.661591] raw: 9fffe00000010200 dead000000000100 dead000000000122 ffff993fff40f400
[ 1459.669302] raw: 0000000000000000 0000000080100010 00000000ffffffff 0000000000000000
[ 1459.677016] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
[ 1459.683432] bad because of flags: 0x200(slab)
[ 1459.687775] Modules linked in: ib_ipoib ib_umad rpcrdma ib_iser libiscsi scsi_transport_iscsi hns_roce_hw_v2 crct10dif_ce hns3 ses hclge hnae3 hisi_hpre hisi_zip qm uacce ip_tables x_tables hisi_sas_v3_hw hisi_sas_main libsas scsi_transport_sas
[ 1459.709329] CPU: 14 PID: 17244 Comm: ethtool Tainted: G O 5.3.0-rc4-00415-gc86f057 #1
[ 1459.718419] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B040.01 07/26/2019
[ 1459.727248] Call trace:
[ 1459.729688] dump_backtrace+0x0/0x150
[ 1459.733335] show_stack+0x24/0x30
[ 1459.736639] dump_stack+0xa0/0xc4
[ 1459.739943] bad_page+0xf0/0x158
[ 1459.743157] free_pages_check_bad+0x84/0xa0
[ 1459.747322] __free_pages_ok+0x348/0x378
[ 1459.751228] page_frag_free+0x80/0x88
[ 1459.754877] skb_free_head+0x38/0x48
[ 1459.758436] skb_release_data+0x134/0x160
[ 1459.762427] skb_release_all+0x30/0x40
[ 1459.766158] consume_skb+0x38/0x108
[ 1459.769633] __dev_kfree_skb_any+0x58/0x68
[ 1459.773718] hns3_fini_ring+0x48/0x58 [hns3]
[ 1459.777970] hns3_set_ringparam+0x2a8/0x418 [hns3]
[ 1459.782741] dev_ethtool+0x5f4/0x2080
[ 1459.786390] dev_ioctl+0x190/0x3d8
[ 1459.789777] sock_do_ioctl+0xf8/0x220
[ 1459.793423] sock_ioctl+0x3bc/0x490
[ 1459.796896] do_vfs_ioctl+0xc4/0x868
[ 1459.800454] ksys_ioctl+0x8c/0xa0
[ 1459.803752] __arm64_sys_ioctl+0x28/0x38
[ 1459.807658] el0_svc_common.constprop.0+0xe0/0x1e0
[ 1459.812426] el0_svc_handler+0x34/0x90
[ 1459.816158] el0_svc+0x10/0x14
[ 1459.819220] Disabling lock debugging due to kernel taint
[ 1459.825182] ------------[ cut here ]------------
Since ndo_stop will reclaim the RX's skb allocated by the driver,
so the backed up ring parameter should not keep this info.
Fixes: a723fb8efe29 ("net: hns3: refine for set ring parameters")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index c52eccc..aa692b1 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -908,9 +908,11 @@ static struct hns3_enet_ring *hns3_backup_ringparam(struct hns3_nic_priv *priv)
if (!tmp_rings)
return NULL;
- for (i = 0; i < handle->kinfo.num_tqps * 2; i++)
+ for (i = 0; i < handle->kinfo.num_tqps * 2; i++) {
memcpy(&tmp_rings[i], priv->ring_data[i].ring,
sizeof(struct hns3_enet_ring));
+ tmp_rings[i].skb = NULL;
+ }
return tmp_rings;
}
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 3/7] net: hns3: fix mis-assignment to hdev->reset_level in hclge_reset
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Huazhong Tan
In-Reply-To: <1567690302-16648-1-git-send-email-tanhuazhong@huawei.com>
Since hclge_get_reset_level may return HNAE3_NONE_RESET,
so hdev->reset_level can not be assigned with the return
value in the hclge_reset(), otherwise, it will cause
the use of hdev->reset_level in hclge_reset_event get
into error.
Fixes: 012fcb52f67c ("net: hns3: activate reset timer when calling reset_event")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 0e1225c..76e1c84 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3619,6 +3619,7 @@ static int hclge_reset_stack(struct hclge_dev *hdev)
static void hclge_reset(struct hclge_dev *hdev)
{
struct hnae3_ae_dev *ae_dev = pci_get_drvdata(hdev->pdev);
+ enum hnae3_reset_type reset_level;
int ret;
/* Initialize ae_dev reset status as well, in case enet layer wants to
@@ -3697,10 +3698,10 @@ static void hclge_reset(struct hclge_dev *hdev)
* it should be handled as soon as possible. since some errors
* need this kind of reset to fix.
*/
- hdev->reset_level = hclge_get_reset_level(ae_dev,
- &hdev->default_reset_request);
- if (hdev->reset_level != HNAE3_NONE_RESET)
- set_bit(hdev->reset_level, &hdev->reset_request);
+ reset_level = hclge_get_reset_level(ae_dev,
+ &hdev->default_reset_request);
+ if (reset_level != HNAE3_NONE_RESET)
+ set_bit(reset_level, &hdev->reset_request);
return;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] hostap: remove set but not used variable 'copied' in prism2_io_debug_proc_read
From: Kalle Valo @ 2019-09-05 13:45 UTC (permalink / raw)
To: zhong jiang; +Cc: kvalo, davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <5D6E1DF2.1000109@huawei.com>
zhong jiang <zhongjiang@huawei.com> writes:
> Please ignore the patch. Because the hostap_proc.c is marked as 'obsolete'.
You mean marked in the MAINTAINERS file? I don't see that as a problem,
I can (and should) still apply any patches submitted to hostap driver.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* pull-request: wireless-drivers 2019-09-05
From: Kalle Valo @ 2019-09-05 13:58 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request to net tree for v5.3, more info below. Please let
me know if there are any problems.
Kalle
The following changes since commit 089cf7f6ecb266b6a4164919a2e69bd2f938374a:
Linux 5.3-rc7 (2019-09-02 09:57:40 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2019-09-05
for you to fetch changes up to 8b51dc7291473093c821195c4b6af85fadedbc2f:
rsi: fix a double free bug in rsi_91x_deinit() (2019-09-03 16:54:48 +0300)
----------------------------------------------------------------
wireless-drivers fixes for 5.3
Fourth set of fixes for 5.3, and hopefully really the last one. Quite
a few CVE fixes this time but at least to my knowledge none of them
have a known exploit.
mt76
* workaround firmware hang by disabling hardware encryption on MT7630E
* disable 5GHz band for MT7630E as it's not working properly
mwifiex
* fix IE parsing to avoid a heap buffer overflow
iwlwifi
* fix for QuZ device initialisation
rt2x00
* another fix for rekeying
* revert a commit causing degradation in rx signal levels
rsi
* fix a double free
----------------------------------------------------------------
Hui Peng (1):
rsi: fix a double free bug in rsi_91x_deinit()
Luca Coelho (1):
iwlwifi: assign directly to iwl_trans->cfg in QuZ detection
Stanislaw Gruszka (4):
mt76: mt76x0e: don't use hw encryption for MT7630E
mt76: mt76x0e: disable 5GHz band for MT7630E
rt2x00: clear up IV's on key removal
Revert "rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band"
Wen Huang (1):
mwifiex: Fix three heap overflow at parsing element in cfg80211_ap_settings
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 24 +++++++-------
drivers/net/wireless/marvell/mwifiex/ie.c | 3 ++
drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 9 +++++-
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c | 5 +++
drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 15 ++++++++-
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 37 +++++++++++-----------
drivers/net/wireless/rsi/rsi_91x_usb.c | 1 -
7 files changed, 60 insertions(+), 34 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/2] Revert and rework on the metadata accelreation
From: Jason Gunthorpe @ 2019-09-05 13:59 UTC (permalink / raw)
To: Jason Wang
Cc: mst@redhat.com, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, aarcange@redhat.com,
jglisse@redhat.com, linux-mm@kvack.org
In-Reply-To: <20190905122736.19768-1-jasowang@redhat.com>
On Thu, Sep 05, 2019 at 08:27:34PM +0800, Jason Wang wrote:
> Hi:
>
> Per request from Michael and Jason, the metadata accelreation is
> reverted in this version and rework in next version.
>
> Please review.
>
> Thanks
>
> Jason Wang (2):
> Revert "vhost: access vq metadata through kernel virtual address"
> vhost: re-introducing metadata acceleration through kernel virtual
> address
There are a bunch of patches in the queue already that will help
vhost, and I a working on one for next cycle that will help alot more
too.
I think you should apply the revert this cycle and rebase the other
patch for next..
Jason
^ permalink raw reply
* [PATCH] lan743x: remove redundant assignment to variable rx_process_result
From: Colin King @ 2019-09-05 14:01 UTC (permalink / raw)
To: Bryan Whitehead, Microchip Linux Driver Support, David S . Miller,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The variable rx_process_result is being initialized with a value that
is never read and is being re-assigned immediately afterwards. The
assignment is redundant, so replace it with the return from function
lan743x_rx_process_packet.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/microchip/lan743x_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
index 15a8be6bad27..a43140f7b5eb 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -2172,9 +2172,8 @@ static int lan743x_rx_napi_poll(struct napi_struct *napi, int weight)
}
count = 0;
while (count < weight) {
- int rx_process_result = -1;
+ int rx_process_result = lan743x_rx_process_packet(rx);
- rx_process_result = lan743x_rx_process_packet(rx);
if (rx_process_result == RX_PROCESS_RESULT_PACKET_RECEIVED) {
count++;
} else if (rx_process_result ==
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] hostap: remove set but not used variable 'copied' in prism2_io_debug_proc_read
From: zhong jiang @ 2019-09-05 14:10 UTC (permalink / raw)
To: Kalle Valo; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <87zhjij1q6.fsf@tynnyri.adurom.net>
On 2019/9/5 21:45, Kalle Valo wrote:
> zhong jiang <zhongjiang@huawei.com> writes:
>
>> Please ignore the patch. Because the hostap_proc.c is marked as 'obsolete'.
> You mean marked in the MAINTAINERS file? I don't see that as a problem,
> I can (and should) still apply any patches submitted to hostap driver.
>
I hit the following issue when checking the patch by checkpatch.pl
WARNING: drivers/net/wireless/intersil/hostap/hostap_proc.c is marked as 'obsolete' in the MAINTAINERS hierarchy.
No unnecessary modifications please.
I certainly hope it can be appiled to upstream if the above check doesn't matter.
Thanks,
zhong jiang
^ permalink raw reply
* Re: [PATCH] net/skbuff: silence warnings under memory pressure
From: Qian Cai @ 2019-09-05 14:09 UTC (permalink / raw)
To: Eric Dumazet, Sergey Senozhatsky
Cc: Sergey Senozhatsky, Michal Hocko, davem, netdev, linux-mm,
linux-kernel, Petr Mladek, Steven Rostedt
In-Reply-To: <165827b5-6783-f4f8-69d6-b088dd97eb45@gmail.com>
On Thu, 2019-09-05 at 10:32 +0200, Eric Dumazet wrote:
>
> On 9/4/19 10:42 PM, Qian Cai wrote:
>
> > To summary, those look to me are all good long-term improvement that would
> > reduce the likelihood of this kind of livelock in general especially for
> > other
> > unknown allocations that happen while processing softirqs, but it is still
> > up to
> > the air if it fixes it 100% in all situations as printk() is going to take
> > more
> > time and could deal with console hardware that involve irq_exit() anyway.
> >
> > On the other hand, adding __GPF_NOWARN in the build_skb() allocation will
> > fix
> > this known NET_TX_SOFTIRQ case which is common when softirqd involved at
> > least
> > in short-term. It even have a benefit to reduce the overall warn_alloc()
> > noise
> > out there.
> >
> > I can resubmit with an update changelog. Does it make any sense?
>
> It does not make sense.
>
> We have thousands other GFP_ATOMIC allocations in the networking stacks.
Instead of repeatedly make generalize statements, could you enlighten me with
some concrete examples that have the similar properties which would trigger a
livelock,
- guaranteed GFP_ATOMIC allocations when processing softirq batches.
- the allocation has a fallback mechanism that is unnecessary to warn a failure.
I thought "skb" is a special-case here as every packet sent or received is
handled using this data structure.
>
> Soon you will have to send more and more patches adding __GFP_NOWARN once
> your workloads/tests can hit all these various points.
I doubt so.
>
> It is really time to fix this problem generically, instead of having
> to review hundreds of patches.
>
> This was my initial feedback really, nothing really has changed since.
I feel like you may not follow the thread closely. There are more details
uncovered in the last few days and narrowed down to the culprits.
>
> The ability to send a warning with a stack trace, holding the cpu
> for many milliseconds should not be decided case by case, otherwise
> every call points will decide to opt-out from the harmful warnings.
That is not really the reasons anymore why I asked to add a __GPF_NOWARN here.
^ permalink raw reply
* Re: [PATCH] hostap: remove set but not used variable 'copied' in prism2_io_debug_proc_read
From: Kalle Valo @ 2019-09-05 14:19 UTC (permalink / raw)
To: zhong jiang; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <5D711760.20903@huawei.com>
zhong jiang <zhongjiang@huawei.com> writes:
> On 2019/9/5 21:45, Kalle Valo wrote:
>> zhong jiang <zhongjiang@huawei.com> writes:
>>
>>> Please ignore the patch. Because the hostap_proc.c is marked as 'obsolete'.
>> You mean marked in the MAINTAINERS file? I don't see that as a problem,
>> I can (and should) still apply any patches submitted to hostap driver.
>>
> I hit the following issue when checking the patch by checkpatch.pl
>
> WARNING: drivers/net/wireless/intersil/hostap/hostap_proc.c is marked
> as 'obsolete' in the MAINTAINERS hierarchy.
> No unnecessary modifications please.
>
> I certainly hope it can be appiled to upstream if the above check doesn't matter.
I have no idea why checkpatch says like that and I'm going to just
ignore that warning. As long as the driver is in the tree I think it
should be improved.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH] rtlwifi: rtl8821ae: make array static const and remove redundant assignment
From: Colin King @ 2019-09-05 15:00 UTC (permalink / raw)
To: Ping-Ke Shih, Kalle Valo, David S . Miller, Larry Finger,
linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The array channel_all can be make static const rather than populating
it on the stack, this makes the code smaller. Also, variable place
is being initialized with a value that is never read, so this assignment
is redundant and can be removed.
Before:
text data bss dec hex filename
118537 9591 0 128128 1f480 realtek/rtlwifi/rtl8821ae/phy.o
After:
text data bss dec hex filename
118331 9687 0 128018 1f412 realtek/rtlwifi/rtl8821ae/phy.o
Saves 110 bytes, (gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
index 408af144098e..979e434a4e73 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
@@ -3613,14 +3613,14 @@ u8 rtl8821ae_phy_sw_chnl(struct ieee80211_hw *hw)
u8 _rtl8812ae_get_right_chnl_place_for_iqk(u8 chnl)
{
- u8 channel_all[TARGET_CHNL_NUM_2G_5G_8812] = {
+ static const u8 channel_all[TARGET_CHNL_NUM_2G_5G_8812] = {
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
14, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54,
56, 58, 60, 62, 64, 100, 102, 104, 106, 108,
110, 112, 114, 116, 118, 120, 122, 124, 126,
128, 130, 132, 134, 136, 138, 140, 149, 151,
153, 155, 157, 159, 161, 163, 165};
- u8 place = chnl;
+ u8 place;
if (chnl > 14) {
for (place = 14; place < sizeof(channel_all); place++)
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox