* Reminder: 3 open syzbot bugs in isdn subsystem
From: Eric Biggers @ 2019-07-24 3:57 UTC (permalink / raw)
To: netdev, Karsten Keil; +Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 3 of them as possibly being bugs in the isdn subsystem. I've listed
these reports below, sorted by an algorithm that tries to list first the reports
most likely to be still valid, important, and actionable.
Of these 3 bugs, 1 was seen in mainline in the last week.
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the isdn subsystem, please let me know,
and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in capi_write
Last occurred: 1 day ago
Reported: 162 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=1075c8d832330e876cad2c8c6872323f5211bc31
Original thread: https://lkml.kernel.org/lkml/0000000000000e35f00581a579cd@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+0849c524d9c634f5ae66@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000000e35f00581a579cd@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in dev_expire_timer
Last occurred: 168 days ago
Reported: 202 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=a520c896ffb4fbc8539cda4c0bb6fe48995defd7
Original thread: https://lkml.kernel.org/lkml/000000000000a317f3057e766a0a@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+7ea31f54ecacb8f68330@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000a317f3057e766a0a@google.com
--------------------------------------------------------------------------------
Title: BUG: spinlock bad magic in flush_workqueue_prep_pwqs
Last occurred: 144 days ago
Reported: 143 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=cbd7a891bd8268f9eb68dfd1f3551670b4ccb412
Original thread: https://lkml.kernel.org/lkml/0000000000009e31600583172454@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+130f0c441448a93a166b@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009e31600583172454@google.com
^ permalink raw reply
* Re: Reminder: 3 open syzbot bugs in "net/ax25" subsystem
From: Joe @ 2019-07-24 3:42 UTC (permalink / raw)
To: linux-hams, netdev, Ralf Baechle, David S. Miller, linux-kernel,
syzkaller-bugs
In-Reply-To: <20190724024049.GC643@sol.localdomain>
Hi Eric, How do I get off of this thread? When I try to unsubscribe it
tells me I'm not a member of the group.
Thanks in advance,
Joe G.
On 7/23/19 7:40 PM, Eric Biggers wrote:
> [This email was generated by a script. Let me know if you have any suggestions
> to make it better, or if you want it re-generated with the latest status.]
>
> Of the currently open syzbot reports against the upstream kernel, I've manually
> marked 3 of them as possibly being bugs in the "net/ax25" subsystem. I've
> listed these reports below, sorted by an algorithm that tries to list first the
> reports most likely to be still valid, important, and actionable.
>
> If you believe a bug is no longer valid, please close the syzbot report by
> sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
> original thread, as explained at https://goo.gl/tpsmEJ#status
>
> If you believe I misattributed a bug to the "net/ax25" subsystem, please let me
> know, and if possible forward the report to the correct people or mailing list.
>
> Here are the bugs:
>
> --------------------------------------------------------------------------------
> Title: general protection fault in ax25_send_frame
> Last occurred: 0 days ago
> Reported: 204 days ago
> Branches: Mainline and others
> Dashboard link: https://syzkaller.appspot.com/bug?id=1cdd5b120f129364fc8e9b2b027826cf99fa696e
> Original thread: https://lkml.kernel.org/lkml/0000000000009ea37c057e58d787@google.com/T/#u
>
> Unfortunately, this bug does not have a reproducer.
>
> No one replied to the original thread for this bug.
>
> If you fix this bug, please add the following tag to the commit:
> Reported-by: syzbot+e0b81535a27b8be39502@syzkaller.appspotmail.com
>
> If you send any email or patch for this bug, please consider replying to the
> original thread. For the git send-email command to use, or tips on how to reply
> if the thread isn't in your mailbox, see the "Reply instructions" at
> https://lkml.kernel.org/r/0000000000009ea37c057e58d787@google.com
>
> --------------------------------------------------------------------------------
> Title: KASAN: stack-out-of-bounds Write in ax25_getname
> Last occurred: 90 days ago
> Reported: 206 days ago
> Branches: Mainline and others
> Dashboard link: https://syzkaller.appspot.com/bug?id=fb195f91dc044978c1b186f1288b1eff61edcc20
> Original thread: https://lkml.kernel.org/lkml/000000000000ed4120057e2df0c6@google.com/T/#u
>
> This bug has a syzkaller reproducer only.
>
> No one replied to the original thread for this bug.
>
> If you fix this bug, please add the following tag to the commit:
> Reported-by: syzbot+6a29097222b4d3b8617c@syzkaller.appspotmail.com
>
> If you send any email or patch for this bug, please consider replying to the
> original thread. For the git send-email command to use, or tips on how to reply
> if the thread isn't in your mailbox, see the "Reply instructions" at
> https://lkml.kernel.org/r/000000000000ed4120057e2df0c6@google.com
>
> --------------------------------------------------------------------------------
> Title: inconsistent lock state in ax25_std_heartbeat_expiry
> Last occurred: 122 days ago
> Reported: 120 days ago
> Branches: net
> Dashboard link: https://syzkaller.appspot.com/bug?id=9086a8eac930890b2730d6441093bd478e32913f
> Original thread: https://lkml.kernel.org/lkml/0000000000001b07250584efbee3@google.com/T/#u
>
> Unfortunately, this bug does not have a reproducer.
>
> The original thread for this bug received 2 replies; the last was 119 days ago.
>
> If you fix this bug, please add the following tag to the commit:
> Reported-by: syzbot+e350b81e95a6a214da8a@syzkaller.appspotmail.com
>
> If you send any email or patch for this bug, please consider replying to the
> original thread. For the git send-email command to use, or tips on how to reply
> if the thread isn't in your mailbox, see the "Reply instructions" at
> https://lkml.kernel.org/r/0000000000001b07250584efbee3@google.com
>
^ permalink raw reply
* [PATCH] net: dsa: Check existence of .port_mdb_add callback before calling it
From: Chen-Yu Tsai @ 2019-07-24 3:47 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S . Miller
Cc: Chen-Yu Tsai, netdev, linux-kernel
From: Chen-Yu Tsai <wens@csie.org>
With the recent addition of commit 75dad2520fc3 ("net: dsa: b53: Disable
all ports on setup"), users of b53 (BCM53125 on Lamobo R1 in my case)
are forced to use the dsa subsystem to enable the switch, instead of
having it in the default transparent "forward-to-all" mode.
The b53 driver does not support mdb bitmap functions. However the dsa
layer does not check for the existence of the .port_mdb_add callback
before actually using it. This results in a NULL pointer dereference,
as shown in the kernel oops below.
The other functions seem to be properly guarded. Do the same for
.port_mdb_add in dsa_switch_mdb_add_bitmap() as well.
b53 is not the only driver that doesn't support mdb bitmap functions.
Others include bcm_sf2, dsa_loop, lantiq_gswip, mt7530, mv88e6060,
qca8k, realtek-smi, and vitesse-vsc73xx.
8<--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = (ptrval)
[00000000] *pgd=00000000
Internal error: Oops: 80000005 [#1] SMP ARM
Modules linked in: rtl8xxxu rtl8192cu rtl_usb rtl8192c_common rtlwifi mac80211 cfg80211
CPU: 1 PID: 134 Comm: kworker/1:2 Not tainted 5.3.0-rc1-00247-gd3519030752a #1
Hardware name: Allwinner sun7i (A20) Family
Workqueue: events switchdev_deferred_process_work
PC is at 0x0
LR is at dsa_switch_event+0x570/0x620
pc : [<00000000>] lr : [<c08533ec>] psr: 80070013
sp : ee871db8 ip : 00000000 fp : ee98d0a4
r10: 0000000c r9 : 00000008 r8 : ee89f710
r7 : ee98d040 r6 : ee98d088 r5 : c0f04c48 r4 : ee98d04c
r3 : 00000000 r2 : ee89f710 r1 : 00000008 r0 : ee98d040
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 6deb406a DAC: 00000051
Process kworker/1:2 (pid: 134, stack limit = 0x(ptrval))
Stack: (0xee871db8 to 0xee872000)
1da0: ee871e14 103ace2d
1dc0: 00000000 ffffffff 00000000 ee871e14 00000005 00000000 c08524a0 00000000
1de0: ffffe000 c014bdfc c0f04c48 ee871e98 c0f04c48 ee9e5000 c0851120 c014bef0
1e00: 00000000 b643aea2 ee9b4068 c08509a8 ee2bf940 ee89f710 ee871ecb 00000000
1e20: 00000008 103ace2d 00000000 c087e248 ee29c868 103ace2d 00000001 ffffffff
1e40: 00000000 ee871e98 00000006 00000000 c0fb2a50 c087e2d0 ffffffff c08523c4
1e60: ffffffff c014bdfc 00000006 c0fad2d0 ee871e98 ee89f710 00000000 c014c500
1e80: 00000000 ee89f3c0 c0f04c48 00000000 ee9e5000 c087dfb4 ee9e5000 00000000
1ea0: ee89f710 ee871ecb 00000001 103ace2d 00000000 c0f04c48 00000000 c087e0a8
1ec0: 00000000 efd9a3e0 0089f3c0 103ace2d ee89f700 ee89f710 ee9e5000 00000122
1ee0: 00000100 c087e130 ee89f700 c0fad2c8 c1003ef0 c087de4c 2e928000 c0fad2ec
1f00: c0fad2ec ee839580 ef7a62c0 ef7a9400 00000000 c087def8 c0fad2ec c01447dc
1f20: ef315640 ef7a62c0 00000008 ee839580 ee839594 ef7a62c0 00000008 c0f03d00
1f40: ef7a62d8 ef7a62c0 ffffe000 c0145b84 ffffe000 c0fb2420 c0bfaa8c 00000000
1f60: ffffe000 ee84b600 ee84b5c0 00000000 ee870000 ee839580 c0145b40 ef0e5ea4
1f80: ee84b61c c014a6f8 00000001 ee84b5c0 c014a5b0 00000000 00000000 00000000
1fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000
1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c08533ec>] (dsa_switch_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
[<c014bdfc>] (notifier_call_chain) from [<c014bef0>] (raw_notifier_call_chain+0x18/0x20)
[<c014bef0>] (raw_notifier_call_chain) from [<c08509a8>] (dsa_port_mdb_add+0x48/0x74)
[<c08509a8>] (dsa_port_mdb_add) from [<c087e248>] (__switchdev_handle_port_obj_add+0x54/0xd4)
[<c087e248>] (__switchdev_handle_port_obj_add) from [<c087e2d0>] (switchdev_handle_port_obj_add+0x8/0x14)
[<c087e2d0>] (switchdev_handle_port_obj_add) from [<c08523c4>] (dsa_slave_switchdev_blocking_event+0x94/0xa4)
[<c08523c4>] (dsa_slave_switchdev_blocking_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
[<c014bdfc>] (notifier_call_chain) from [<c014c500>] (blocking_notifier_call_chain+0x50/0x68)
[<c014c500>] (blocking_notifier_call_chain) from [<c087dfb4>] (switchdev_port_obj_notify+0x44/0xa8)
[<c087dfb4>] (switchdev_port_obj_notify) from [<c087e0a8>] (switchdev_port_obj_add_now+0x90/0x104)
[<c087e0a8>] (switchdev_port_obj_add_now) from [<c087e130>] (switchdev_port_obj_add_deferred+0x14/0x5c)
[<c087e130>] (switchdev_port_obj_add_deferred) from [<c087de4c>] (switchdev_deferred_process+0x64/0x104)
[<c087de4c>] (switchdev_deferred_process) from [<c087def8>] (switchdev_deferred_process_work+0xc/0x14)
[<c087def8>] (switchdev_deferred_process_work) from [<c01447dc>] (process_one_work+0x218/0x50c)
[<c01447dc>] (process_one_work) from [<c0145b84>] (worker_thread+0x44/0x5bc)
[<c0145b84>] (worker_thread) from [<c014a6f8>] (kthread+0x148/0x150)
[<c014a6f8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
Exception stack(0xee871fb0 to 0xee871ff8)
1fa0: 00000000 00000000 00000000 00000000
1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: bad PC value
---[ end trace 1292c61abd17b130 ]---
[<c08533ec>] (dsa_switch_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
corresponds to
$ arm-linux-gnueabihf-addr2line -C -i -e vmlinux c08533ec
linux/net/dsa/switch.c:156
linux/net/dsa/switch.c:178
linux/net/dsa/switch.c:328
Fixes: e6db98db8a95 ("net: dsa: add switch mdb bitmap functions")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
This piece of code was moved around in release 4.16, and probably
existed for even longer in some other form. Seems kind of odd that
I'm running into it just now. Maybe there's some other issue I'm
missing, or that it's specific to b53 only? Either way I get the
feeling that I missing something and this is only papering over it.
---
net/dsa/switch.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/net/dsa/switch.c b/net/dsa/switch.c
index 4ec5b7f85d51..13c7ef53e0de 100644
--- a/net/dsa/switch.c
+++ b/net/dsa/switch.c
@@ -147,14 +147,19 @@ dsa_switch_mdb_prepare_bitmap(struct dsa_switch *ds,
return 0;
}
-static void dsa_switch_mdb_add_bitmap(struct dsa_switch *ds,
- const struct switchdev_obj_port_mdb *mdb,
- const unsigned long *bitmap)
+static int dsa_switch_mdb_add_bitmap(struct dsa_switch *ds,
+ const struct switchdev_obj_port_mdb *mdb,
+ const unsigned long *bitmap)
{
int port;
+ if (!ds->ops->port_mdb_add)
+ return -EOPNOTSUPP;
+
for_each_set_bit(port, bitmap, ds->num_ports)
ds->ops->port_mdb_add(ds, port, mdb);
+
+ return 0;
}
static int dsa_switch_mdb_add(struct dsa_switch *ds,
@@ -175,9 +180,7 @@ static int dsa_switch_mdb_add(struct dsa_switch *ds,
if (switchdev_trans_ph_prepare(trans))
return dsa_switch_mdb_prepare_bitmap(ds, mdb, ds->bitmap);
- dsa_switch_mdb_add_bitmap(ds, mdb, ds->bitmap);
-
- return 0;
+ return dsa_switch_mdb_add_bitmap(ds, mdb, ds->bitmap);
}
static int dsa_switch_mdb_del(struct dsa_switch *ds,
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 11/11] net: hns3: add support for handling IMP error
From: Huazhong Tan @ 2019-07-24 3:18 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
Weihang Li, Peng Li, Huazhong Tan
In-Reply-To: <1563938327-9865-1-git-send-email-tanhuazhong@huawei.com>
From: Weihang Li <liweihang@hisilicon.com>
When IMP goes errors, the hardware reports a RAS to the driver,
the driver record this kind of error. Then a IMP reset will happen,
the driver checks the reason and takes the corresponding action
when doing IMP reset.
So this patch adds imp_err_state field to the struct hclge_dev
to record the error type, and handle_imp_error ops to handle it.
Signed-off-by: Weihang Li <liweihang@hisilicon.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 37 ++++++++++++++++++++--
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h | 4 +++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 29 +++++++++++++++++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 9 ++++++
5 files changed, 78 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index a4624db..3a1d6cc 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -515,6 +515,7 @@ struct hnae3_ae_ops {
int (*mac_connect_phy)(struct hnae3_handle *handle);
void (*mac_disconnect_phy)(struct hnae3_handle *handle);
void (*restore_vlan_table)(struct hnae3_handle *handle);
+ void (*handle_imp_error)(struct hnae3_handle *handle);
};
struct hnae3_dcb_ops {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
index 0a72438..25df66d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
@@ -683,6 +683,28 @@ static int hclge_cmd_query_error(struct hclge_dev *hdev,
return ret;
}
+static int hclge_check_imp_poison_err(struct hclge_dev *hdev)
+{
+ struct device *dev = &hdev->pdev->dev;
+ int ras_status;
+ int ret = false;
+
+ ras_status = hclge_read_dev(&hdev->hw, HCLGE_PF_OTHER_INT_REG);
+ if (ras_status & HCLGE_RAS_IMP_RD_POISON_MASK) {
+ set_bit(HCLGE_IMP_RD_POISON, &hdev->imp_err_state);
+ /* This error will be handle by IMP reset */
+ dev_info(dev, "IMP RD poison detected!\n");
+ ret = true;
+ } else if (ras_status & HCLGE_RAS_IMP_CMDQ_ERR_MASK) {
+ set_bit(HCLGE_IMP_CMDQ_ERROR, &hdev->imp_err_state);
+ /* This error will be handle by IMP reset */
+ dev_info(dev, "IMP CMDQ error detected!\n");
+ ret = true;
+ }
+
+ return ret;
+}
+
static int hclge_clear_mac_tnl_int(struct hclge_dev *hdev)
{
struct hclge_desc desc;
@@ -1321,10 +1343,12 @@ static int hclge_handle_pf_ras_error(struct hclge_dev *hdev,
/* log PPU(RCB) errors */
desc_data = (__le32 *)&desc[3];
status = le32_to_cpu(*desc_data) & HCLGE_PPU_PF_INT_RAS_MASK;
- if (status)
+ if (status) {
hclge_log_error(dev, "PPU_PF_ABNORMAL_INT_ST0",
&hclge_ppu_pf_abnormal_int[0], status,
&ae_dev->hw_err_reset_req);
+ hdev->ppu_poison_ras_err = true;
+ }
/* clear all PF RAS errors */
hclge_cmd_reuse_desc(&desc[0], false);
@@ -1632,6 +1656,7 @@ pci_ers_result_t hclge_handle_hw_ras_error(struct hnae3_ae_dev *ae_dev)
struct hclge_dev *hdev = ae_dev->priv;
struct device *dev = &hdev->pdev->dev;
u32 status;
+ int ret;
if (!test_bit(HCLGE_STATE_SERVICE_INITED, &hdev->state)) {
dev_err(dev,
@@ -1639,6 +1664,9 @@ pci_ers_result_t hclge_handle_hw_ras_error(struct hnae3_ae_dev *ae_dev)
return PCI_ERS_RESULT_NONE;
}
+ if (hclge_check_imp_poison_err(hdev))
+ return PCI_ERS_RESULT_RECOVERED;
+
status = hclge_read_dev(&hdev->hw, HCLGE_RAS_PF_OTHER_INT_STS_REG);
if (status & HCLGE_RAS_REG_NFE_MASK ||
@@ -1652,7 +1680,12 @@ pci_ers_result_t hclge_handle_hw_ras_error(struct hnae3_ae_dev *ae_dev)
dev_warn(dev,
"HNS Non-Fatal RAS error(status=0x%x) identified\n",
status);
- hclge_handle_all_ras_errors(hdev);
+ ret = hclge_handle_all_ras_errors(hdev);
+ if (ret) {
+ ret = hclge_check_imp_poison_err(hdev);
+ if (ret)
+ return PCI_ERS_RESULT_RECOVERED;
+ }
}
/* Handling Non-fatal Rocee RAS errors */
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h
index 7ea8bb2..4839fc4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h
@@ -12,6 +12,10 @@
#define HCLGE_PF_MSIX_INT_MIN_BD_NUM 4
#define HCLGE_RAS_PF_OTHER_INT_STS_REG 0x20B00
+#define HCLGE_RAS_IMP_RD_POISON_MASK \
+ BIT(HCLGE_VECTOR0_IMP_RD_POISON_B)
+#define HCLGE_RAS_IMP_CMDQ_ERR_MASK \
+ BIT(HCLGE_VECTOR0_IMP_CMDQ_ERR_B)
#define HCLGE_RAS_REG_NFE_MASK 0xFF00
#define HCLGE_RAS_REG_ROCEE_ERR_MASK 0x3000000
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 45acbc9..36a2b65 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3281,6 +3281,7 @@ static int hclge_reset_prepare_wait(struct hclge_dev *hdev)
{
#define HCLGE_RESET_SYNC_TIME 100
+ struct hnae3_handle *handle = &hdev->vport[0].nic;
u32 reg_val;
int ret = 0;
@@ -3315,6 +3316,8 @@ static int hclge_reset_prepare_wait(struct hclge_dev *hdev)
hdev->rst_stats.flr_rst_cnt++;
break;
case HNAE3_IMP_RESET:
+ if (handle && handle->ae_algo->ops->handle_imp_error)
+ handle->ae_algo->ops->handle_imp_error(handle);
reg_val = hclge_read_dev(&hdev->hw, HCLGE_PF_OTHER_INT_REG);
hclge_write_dev(&hdev->hw, HCLGE_PF_OTHER_INT_REG,
BIT(HCLGE_VECTOR0_IMP_RESET_INT_B) | reg_val);
@@ -3517,6 +3520,9 @@ static void hclge_reset_event(struct pci_dev *pdev, struct hnae3_handle *handle)
else if (time_after(jiffies, (hdev->last_reset_time + 4 * 5 * HZ)))
hdev->reset_level = HNAE3_FUNC_RESET;
+ if (hdev->ppu_poison_ras_err)
+ hdev->ppu_poison_ras_err = false;
+
dev_info(&hdev->pdev->dev, "received reset event , reset type is %d",
hdev->reset_level);
@@ -3545,6 +3551,27 @@ static void hclge_reset_timer(struct timer_list *t)
hclge_reset_event(hdev->pdev, NULL);
}
+void hclge_handle_imp_error(struct hnae3_handle *handle)
+{
+ struct hclge_vport *vport = hclge_get_vport(handle);
+ struct hclge_dev *hdev = vport->back;
+ u32 reg_val;
+
+ if (test_and_clear_bit(HCLGE_IMP_RD_POISON, &hdev->imp_err_state)) {
+ dev_err(&hdev->pdev->dev, "Detected IMP RD poison!\n");
+ reg_val = hclge_read_dev(&hdev->hw, HCLGE_PF_OTHER_INT_REG) &
+ ~BIT(HCLGE_VECTOR0_IMP_RD_POISON_B);
+ hclge_write_dev(&hdev->hw, HCLGE_PF_OTHER_INT_REG, reg_val);
+ }
+
+ if (test_and_clear_bit(HCLGE_IMP_CMDQ_ERROR, &hdev->imp_err_state)) {
+ dev_err(&hdev->pdev->dev, "Detected IMP CMDQ error!\n");
+ reg_val = hclge_read_dev(&hdev->hw, HCLGE_PF_OTHER_INT_REG) &
+ ~BIT(HCLGE_VECTOR0_IMP_CMDQ_ERR_B);
+ hclge_write_dev(&hdev->hw, HCLGE_PF_OTHER_INT_REG, reg_val);
+ }
+}
+
static void hclge_reset_subtask(struct hclge_dev *hdev)
{
struct hnae3_ae_dev *ae_dev = pci_get_drvdata(hdev->pdev);
@@ -3560,6 +3587,7 @@ static void hclge_reset_subtask(struct hclge_dev *hdev)
*/
hdev->last_reset_time = jiffies;
hdev->reset_type = hclge_get_reset_level(ae_dev, &hdev->reset_pending);
+
if (hdev->reset_type != HNAE3_NONE_RESET)
hclge_reset(hdev);
@@ -9516,6 +9544,7 @@ static const struct hnae3_ae_ops hclge_ops = {
.mac_connect_phy = hclge_mac_connect_phy,
.mac_disconnect_phy = hclge_mac_disconnect_phy,
.restore_vlan_table = hclge_restore_vlan_table,
+ .handle_imp_error = hclge_handle_imp_error,
};
static struct hnae3_ae_algo ae_algo = {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index 688e425..7b7ba30 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
@@ -178,6 +178,8 @@ enum HLCGE_PORT_TYPE {
#define HCLGE_VECTOR0_RX_CMDQ_INT_B 1
#define HCLGE_VECTOR0_IMP_RESET_INT_B 1
+#define HCLGE_VECTOR0_IMP_CMDQ_ERR_B 4
+#define HCLGE_VECTOR0_IMP_RD_POISON_B 5
#define HCLGE_MAC_DEFAULT_FRAME \
(ETH_HLEN + ETH_FCS_LEN + 2 * VLAN_HLEN + ETH_DATA_LEN)
@@ -676,6 +678,11 @@ enum HCLGE_MAC_ADDR_TYPE {
HCLGE_MAC_ADDR_MC
};
+enum HCLGE_IMP_ERR_TYPE {
+ HCLGE_IMP_RD_POISON,
+ HCLGE_IMP_CMDQ_ERROR,
+};
+
struct hclge_vport_vlan_cfg {
struct list_head node;
int hd_tbl_status;
@@ -777,6 +784,8 @@ struct hclge_dev {
u8 tc_num_last_time;
enum hclge_fc_mode fc_mode_last_time;
u8 support_sfp_query;
+ bool ppu_poison_ras_err;
+ unsigned long imp_err_state;
#define HCLGE_FLAG_TC_BASE_SCH_MODE 1
#define HCLGE_FLAG_VNET_BASE_SCH_MODE 2
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 04/11] net: hns3: fix mis-counting IRQ vector numbers issue
From: Huazhong Tan @ 2019-07-24 3:18 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
Yonglong Liu, Peng Li, Huazhong Tan
In-Reply-To: <1563938327-9865-1-git-send-email-tanhuazhong@huawei.com>
From: Yonglong Liu <liuyonglong@huawei.com>
The num_msi_left means the vector numbers of NIC, but if the
PF supported RoCE, it contains the vector numbers of NIC and
RoCE(Not expected).
This may cause interrupts lost in some case, because of the
NIC module used the vector resources which belongs to RoCE.
This patch corrects the value of num_msi_left to be equals to
the vector numbers of NIC, and adjust the default tqp numbers
according to the value of num_msi_left.
Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support")
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 5 ++++-
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 12 ++++++++++--
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 3c64d70..a59d13f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -1470,13 +1470,16 @@ static int hclge_vport_setup(struct hclge_vport *vport, u16 num_tqps)
{
struct hnae3_handle *nic = &vport->nic;
struct hclge_dev *hdev = vport->back;
+ u16 alloc_tqps;
int ret;
nic->pdev = hdev->pdev;
nic->ae_algo = &ae_algo;
nic->numa_node_mask = hdev->numa_node_mask;
- ret = hclge_knic_setup(vport, num_tqps,
+ alloc_tqps = min_t(u16, hdev->roce_base_msix_offset - 1, num_tqps);
+
+ ret = hclge_knic_setup(vport, alloc_tqps,
hdev->num_tx_desc, hdev->num_rx_desc);
if (ret)
dev_err(&hdev->pdev->dev, "knic setup failed %d\n", ret);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index a13a0e1..db84782 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -287,6 +287,14 @@ static int hclgevf_get_queue_info(struct hclgevf_dev *hdev)
memcpy(&hdev->rss_size_max, &resp_msg[2], sizeof(u16));
memcpy(&hdev->rx_buf_len, &resp_msg[4], sizeof(u16));
+ /* if irq is not enough, let tqps have the same value of irqs,
+ * to make sure one irq just bind to one tqp, this can improve
+ * the performance
+ */
+ hdev->num_tqps = min_t(u16, hdev->roce_base_msix_offset - 1,
+ hdev->num_tqps);
+ hdev->rss_size_max = min_t(u16, hdev->rss_size_max, hdev->num_tqps);
+
return 0;
}
@@ -2208,7 +2216,7 @@ static int hclgevf_init_msi(struct hclgevf_dev *hdev)
int vectors;
int i;
- if (hnae3_get_bit(hdev->ae_dev->flag, HNAE3_DEV_SUPPORT_ROCE_B))
+ if (hnae3_dev_roce_supported(hdev))
vectors = pci_alloc_irq_vectors(pdev,
hdev->roce_base_msix_offset + 1,
hdev->num_msi,
@@ -2495,7 +2503,7 @@ static int hclgevf_query_vf_resource(struct hclgevf_dev *hdev)
req = (struct hclgevf_query_res_cmd *)desc.data;
- if (hnae3_get_bit(hdev->ae_dev->flag, HNAE3_DEV_SUPPORT_ROCE_B)) {
+ if (hnae3_dev_roce_supported(hdev)) {
hdev->roce_base_msix_offset =
hnae3_get_field(__le16_to_cpu(req->msixcap_localid_ba_rocee),
HCLGEVF_MSIX_OFT_ROCEE_M,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 07/11] net: hns3: adds debug messages to identify eth down cause
From: Huazhong Tan @ 2019-07-24 3:18 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
Yonglong Liu, Peng Li, Huazhong Tan
In-Reply-To: <1563938327-9865-1-git-send-email-tanhuazhong@huawei.com>
From: Yonglong Liu <liuyonglong@huawei.com>
Some times just see the eth interface have been down/up via
dmesg, but can not know why the eth down. So adds some debug
messages to identify the cause for this.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 24 ++++++++++++++++++++
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 26 ++++++++++++++++++++++
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 14 ++++++++++++
3 files changed, 64 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 4d58c53..cff5d59 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -459,6 +459,10 @@ static int hns3_nic_net_open(struct net_device *netdev)
h->ae_algo->ops->set_timer_task(priv->ae_handle, true);
hns3_config_xps(priv);
+
+ if (netif_msg_ifup(h))
+ netdev_info(netdev, "net open\n");
+
return 0;
}
@@ -519,6 +523,9 @@ static int hns3_nic_net_stop(struct net_device *netdev)
if (test_and_set_bit(HNS3_NIC_STATE_DOWN, &priv->state))
return 0;
+ if (netif_msg_ifdown(h))
+ netdev_info(netdev, "net stop\n");
+
if (h->ae_algo->ops->set_timer_task)
h->ae_algo->ops->set_timer_task(priv->ae_handle, false);
@@ -1550,6 +1557,9 @@ static int hns3_setup_tc(struct net_device *netdev, void *type_data)
h = hns3_get_handle(netdev);
kinfo = &h->kinfo;
+ if (netif_msg_ifdown(h))
+ netdev_info(netdev, "setup tc: num_tc=%d\n", tc);
+
return (kinfo->dcb_ops && kinfo->dcb_ops->setup_tc) ?
kinfo->dcb_ops->setup_tc(h, tc, prio_tc) : -EOPNOTSUPP;
}
@@ -1593,6 +1603,11 @@ static int hns3_ndo_set_vf_vlan(struct net_device *netdev, int vf, u16 vlan,
struct hnae3_handle *h = hns3_get_handle(netdev);
int ret = -EIO;
+ if (netif_msg_ifdown(h))
+ netdev_info(netdev,
+ "set vf vlan: vf=%d, vlan=%d, qos=%d, vlan_proto=%d\n",
+ vf, vlan, qos, vlan_proto);
+
if (h->ae_algo->ops->set_vf_vlan_filter)
ret = h->ae_algo->ops->set_vf_vlan_filter(h, vf, vlan,
qos, vlan_proto);
@@ -1611,6 +1626,10 @@ static int hns3_nic_change_mtu(struct net_device *netdev, int new_mtu)
if (!h->ae_algo->ops->set_mtu)
return -EOPNOTSUPP;
+ if (netif_msg_ifdown(h))
+ netdev_info(netdev, "change mtu from %d to %d\n",
+ netdev->mtu, new_mtu);
+
ret = h->ae_algo->ops->set_mtu(h, new_mtu);
if (ret)
netdev_err(netdev, "failed to change MTU in hardware %d\n",
@@ -4395,6 +4414,11 @@ int hns3_set_channels(struct net_device *netdev,
if (kinfo->rss_size == new_tqp_num)
return 0;
+ if (netif_msg_ifdown(h))
+ netdev_info(netdev,
+ "set channels: tqp_num=%d, rxfh=%d\n",
+ new_tqp_num, rxfh_configured);
+
ret = hns3_reset_notify(h, HNAE3_DOWN_CLIENT);
if (ret)
return ret;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index e71c92b..edb9845 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -311,6 +311,9 @@ static void hns3_self_test(struct net_device *ndev,
if (eth_test->flags != ETH_TEST_FL_OFFLINE)
return;
+ if (netif_msg_ifdown(h))
+ netdev_info(ndev, "self test start\n");
+
st_param[HNAE3_LOOP_APP][0] = HNAE3_LOOP_APP;
st_param[HNAE3_LOOP_APP][1] =
h->flags & HNAE3_SUPPORT_APP_LOOPBACK;
@@ -374,6 +377,9 @@ static void hns3_self_test(struct net_device *ndev,
if (if_running)
ndev->netdev_ops->ndo_open(ndev);
+
+ if (netif_msg_ifdown(h))
+ netdev_info(ndev, "self test end\n");
}
static int hns3_get_sset_count(struct net_device *netdev, int stringset)
@@ -604,6 +610,11 @@ static int hns3_set_pauseparam(struct net_device *netdev,
{
struct hnae3_handle *h = hns3_get_handle(netdev);
+ if (netif_msg_ifdown(h))
+ netdev_info(netdev,
+ "set pauseparam: autoneg=%d, rx:%d, tx:%d\n",
+ param->autoneg, param->rx_pause, param->tx_pause);
+
if (h->ae_algo->ops->set_pauseparam)
return h->ae_algo->ops->set_pauseparam(h, param->autoneg,
param->rx_pause,
@@ -743,6 +754,13 @@ static int hns3_set_link_ksettings(struct net_device *netdev,
if (cmd->base.speed == SPEED_1000 && cmd->base.duplex == DUPLEX_HALF)
return -EINVAL;
+ if (netif_msg_ifdown(handle))
+ netdev_info(netdev,
+ "set link(%s): autoneg=%d, speed=%d, duplex=%d\n",
+ netdev->phydev ? "phy" : "mac",
+ cmd->base.autoneg, cmd->base.speed,
+ cmd->base.duplex);
+
/* Only support ksettings_set for netdev with phy attached for now */
if (netdev->phydev)
return phy_ethtool_ksettings_set(netdev->phydev, cmd);
@@ -984,6 +1002,10 @@ static int hns3_nway_reset(struct net_device *netdev)
return -EINVAL;
}
+ if (netif_msg_ifdown(handle))
+ netdev_info(netdev, "nway reset (using %s)\n",
+ phy ? "phy" : "mac");
+
if (phy)
return genphy_restart_aneg(phy);
@@ -1308,6 +1330,10 @@ static int hns3_set_fecparam(struct net_device *netdev,
if (!ops->set_fec)
return -EOPNOTSUPP;
fec_mode = eth_to_loc_fec(fec->fec);
+
+ if (netif_msg_ifdown(handle))
+ netdev_info(netdev, "set fecparam: mode=%d\n", fec_mode);
+
return ops->set_fec(handle, fec_mode);
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
index bac4ce1..133e7c6 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
@@ -201,6 +201,7 @@ static int hclge_client_setup_tc(struct hclge_dev *hdev)
static int hclge_ieee_setets(struct hnae3_handle *h, struct ieee_ets *ets)
{
struct hclge_vport *vport = hclge_get_vport(h);
+ struct net_device *netdev = h->kinfo.netdev;
struct hclge_dev *hdev = vport->back;
bool map_changed = false;
u8 num_tc = 0;
@@ -215,6 +216,9 @@ static int hclge_ieee_setets(struct hnae3_handle *h, struct ieee_ets *ets)
return ret;
if (map_changed) {
+ if (netif_msg_ifdown(h))
+ netdev_info(netdev, "set ets\n");
+
ret = hclge_notify_client(hdev, HNAE3_DOWN_CLIENT);
if (ret)
return ret;
@@ -300,6 +304,7 @@ static int hclge_ieee_getpfc(struct hnae3_handle *h, struct ieee_pfc *pfc)
static int hclge_ieee_setpfc(struct hnae3_handle *h, struct ieee_pfc *pfc)
{
struct hclge_vport *vport = hclge_get_vport(h);
+ struct net_device *netdev = h->kinfo.netdev;
struct hclge_dev *hdev = vport->back;
u8 i, j, pfc_map, *prio_tc;
@@ -325,6 +330,11 @@ static int hclge_ieee_setpfc(struct hnae3_handle *h, struct ieee_pfc *pfc)
hdev->tm_info.hw_pfc_map = pfc_map;
hdev->tm_info.pfc_en = pfc->pfc_en;
+ if (netif_msg_ifdown(h))
+ netdev_info(netdev,
+ "set pfc: pfc_en=%d, pfc_map=%d, num_tc=%d\n",
+ pfc->pfc_en, pfc_map, hdev->tm_info.num_tc);
+
hclge_tm_pfc_info_update(hdev);
return hclge_pause_setup_hw(hdev, false);
@@ -345,8 +355,12 @@ static u8 hclge_getdcbx(struct hnae3_handle *h)
static u8 hclge_setdcbx(struct hnae3_handle *h, u8 mode)
{
struct hclge_vport *vport = hclge_get_vport(h);
+ struct net_device *netdev = h->kinfo.netdev;
struct hclge_dev *hdev = vport->back;
+ if (netif_msg_drv(h))
+ netdev_info(netdev, "set dcbx: mode=%d\n", mode);
+
/* No support for LLD_MANAGED modes or CEE */
if ((mode & DCB_CAP_DCBX_LLD_MANAGED) ||
(mode & DCB_CAP_DCBX_VER_CEE) ||
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 05/11] net: hns3: change GFP flag during lock period
From: Huazhong Tan @ 2019-07-24 3:18 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
Yufeng Mo, lipeng 00277521, Huazhong Tan
In-Reply-To: <1563938327-9865-1-git-send-email-tanhuazhong@huawei.com>
From: Yufeng Mo <moyufeng@huawei.com>
When allocating memory, the GFP_KERNEL cannot be used during the
spin_lock period. This is because it may cause scheduling when holding
spin_lock. This patch changes GFP flag to GFP_ATOMIC in this case.
Fixes: dd74f815dd41 ("net: hns3: Add support for rule add/delete for flow director")
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: lipeng 00277521 <lipeng321@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 a59d13f..f345095 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -5799,7 +5799,7 @@ static int hclge_add_fd_entry_by_arfs(struct hnae3_handle *handle, u16 queue_id,
return -ENOSPC;
}
- rule = kzalloc(sizeof(*rule), GFP_KERNEL);
+ rule = kzalloc(sizeof(*rule), GFP_ATOMIC);
if (!rule) {
spin_unlock_bh(&hdev->fd_rule_lock);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 10/11] net: hns3: Add support for using order 1 pages with a 4K buffer
From: Huazhong Tan @ 2019-07-24 3:18 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
Yunsheng Lin, Huazhong Tan
In-Reply-To: <1563938327-9865-1-git-send-email-tanhuazhong@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
Hardware supports 0.5K, 1K, 2K, 4K RX buffer size, the
RX buffer can not be reused because the hns3_page_order
return 0 when page size and RX buffer size are both 4096.
So this patch changes the hns3_page_order to return 1 when
RX buffer is greater than half of the page size and page size
is less the 8192, and dev_alloc_pages has already been used
to allocate the compound page for RX buffer.
This patch also changes hnae3_* to hns3_* for page order
and RX buffer size calculation because they are used in
hns3 module.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Reviewed-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 10 +++++-----
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 15 ++++++++++++---
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index cff5d59..56af4be 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2086,7 +2086,7 @@ static void hns3_set_default_feature(struct net_device *netdev)
static int hns3_alloc_buffer(struct hns3_enet_ring *ring,
struct hns3_desc_cb *cb)
{
- unsigned int order = hnae3_page_order(ring);
+ unsigned int order = hns3_page_order(ring);
struct page *p;
p = dev_alloc_pages(order);
@@ -2097,7 +2097,7 @@ static int hns3_alloc_buffer(struct hns3_enet_ring *ring,
cb->page_offset = 0;
cb->reuse_flag = 0;
cb->buf = page_address(p);
- cb->length = hnae3_page_size(ring);
+ cb->length = hns3_page_size(ring);
cb->type = DESC_TYPE_PAGE;
return 0;
@@ -2400,7 +2400,7 @@ static void hns3_nic_reuse_page(struct sk_buff *skb, int i,
{
struct hns3_desc *desc = &ring->desc[ring->next_to_clean];
int size = le16_to_cpu(desc->rx.size);
- u32 truesize = hnae3_buf_size(ring);
+ u32 truesize = hns3_buf_size(ring);
skb_add_rx_frag(skb, i, desc_cb->priv, desc_cb->page_offset + pull_len,
size - pull_len, truesize);
@@ -2415,7 +2415,7 @@ static void hns3_nic_reuse_page(struct sk_buff *skb, int i,
/* Move offset up to the next cache line */
desc_cb->page_offset += truesize;
- if (desc_cb->page_offset + truesize <= hnae3_page_size(ring)) {
+ if (desc_cb->page_offset + truesize <= hns3_page_size(ring)) {
desc_cb->reuse_flag = 1;
/* Bump ref count on page before it is given */
get_page(desc_cb->priv);
@@ -2697,7 +2697,7 @@ static int hns3_add_frag(struct hns3_enet_ring *ring, struct hns3_desc *desc,
}
if (ring->tail_skb) {
- head_skb->truesize += hnae3_buf_size(ring);
+ head_skb->truesize += hns3_buf_size(ring);
head_skb->data_len += le16_to_cpu(desc->rx.size);
head_skb->len += le16_to_cpu(desc->rx.size);
skb = ring->tail_skb;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 848b866..1a17856 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -608,9 +608,18 @@ static inline bool hns3_nic_resetting(struct net_device *netdev)
#define tx_ring_data(priv, idx) ((priv)->ring_data[idx])
-#define hnae3_buf_size(_ring) ((_ring)->buf_size)
-#define hnae3_page_order(_ring) (get_order(hnae3_buf_size(_ring)))
-#define hnae3_page_size(_ring) (PAGE_SIZE << (u32)hnae3_page_order(_ring))
+#define hns3_buf_size(_ring) ((_ring)->buf_size)
+
+static inline unsigned int hns3_page_order(struct hns3_enet_ring *ring)
+{
+#if (PAGE_SIZE < 8192)
+ if (ring->buf_size > (PAGE_SIZE / 2))
+ return 1;
+#endif
+ return 0;
+}
+
+#define hns3_page_size(_ring) (PAGE_SIZE << hns3_page_order(_ring))
/* iterator for handling rings in ring group */
#define hns3_for_each_ring(pos, head) \
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 02/11] net: hns3: add a check for get_reset_level
From: Huazhong Tan @ 2019-07-24 3:18 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
Guangbin Huang, Huazhong Tan
In-Reply-To: <1563938327-9865-1-git-send-email-tanhuazhong@huawei.com>
From: Guangbin Huang <huangguangbin@huawei.com>
For some cases, ops->get_reset_level may not be implemented, so we
should check whether it is NULL before calling get_reset_level.
Signed-off-by: Guangbin Huang <huangguangbin@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 08af782..4d58c53 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1963,7 +1963,7 @@ static pci_ers_result_t hns3_slot_reset(struct pci_dev *pdev)
ops = ae_dev->ops;
/* request the reset */
- if (ops->reset_event) {
+ if (ops->reset_event && ops->get_reset_level) {
if (ae_dev->hw_err_reset_req) {
reset_type = ops->get_reset_level(ae_dev,
&ae_dev->hw_err_reset_req);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 01/11] net: hns3: add reset checking before set channels
From: Huazhong Tan @ 2019-07-24 3:18 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
Jian Shen, Huazhong Tan
In-Reply-To: <1563938327-9865-1-git-send-email-tanhuazhong@huawei.com>
From: Jian Shen <shenjian15@huawei.com>
hns3_set_channels() should check the resetting status firstly,
since the device will reinitialize when resetting. If the
reset has not completed, the hns3_set_channels() may access
invalid memory.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 69f7ef8..08af782 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -4378,6 +4378,9 @@ int hns3_set_channels(struct net_device *netdev,
u16 org_tqp_num;
int ret;
+ if (hns3_nic_resetting(netdev))
+ return -EBUSY;
+
if (ch->rx_count || ch->tx_count)
return -EINVAL;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 03/11] net: hns3: remove upgrade reset level when reset fail
From: Huazhong Tan @ 2019-07-24 3:18 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
Huazhong Tan
In-Reply-To: <1563938327-9865-1-git-send-email-tanhuazhong@huawei.com>
Currently, hclge_reset_err_handle() will assert a global reset
when the failing count is smaller than MAX_RESET_FAIL_CNT, which
will affect other running functions.
So this patch removes this upgrading, and uses re-scheduling reset
task to do it.
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com>
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 28 +++++++---------------
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 3fde5471..3c64d70 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3305,7 +3305,7 @@ static int hclge_reset_prepare_wait(struct hclge_dev *hdev)
return ret;
}
-static bool hclge_reset_err_handle(struct hclge_dev *hdev, bool is_timeout)
+static bool hclge_reset_err_handle(struct hclge_dev *hdev)
{
#define MAX_RESET_FAIL_CNT 5
@@ -3322,20 +3322,11 @@ static bool hclge_reset_err_handle(struct hclge_dev *hdev, bool is_timeout)
return false;
} else if (hdev->reset_fail_cnt < MAX_RESET_FAIL_CNT) {
hdev->reset_fail_cnt++;
- if (is_timeout) {
- set_bit(hdev->reset_type, &hdev->reset_pending);
- dev_info(&hdev->pdev->dev,
- "re-schedule to wait for hw reset done\n");
- return true;
- }
-
- dev_info(&hdev->pdev->dev, "Upgrade reset level\n");
- hclge_clear_reset_cause(hdev);
- set_bit(HNAE3_GLOBAL_RESET, &hdev->default_reset_request);
- mod_timer(&hdev->reset_timer,
- jiffies + HCLGE_RESET_INTERVAL);
-
- return false;
+ set_bit(hdev->reset_type, &hdev->reset_pending);
+ dev_info(&hdev->pdev->dev,
+ "re-schedule reset task(%d)\n",
+ hdev->reset_fail_cnt);
+ return true;
}
hclge_clear_reset_cause(hdev);
@@ -3382,7 +3373,6 @@ 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);
- bool is_timeout = false;
int ret;
/* Initialize ae_dev reset status as well, in case enet layer wants to
@@ -3410,10 +3400,8 @@ static void hclge_reset(struct hclge_dev *hdev)
if (ret)
goto err_reset;
- if (hclge_reset_wait(hdev)) {
- is_timeout = true;
+ if (hclge_reset_wait(hdev))
goto err_reset;
- }
hdev->rst_stats.hw_reset_done_cnt++;
@@ -3465,7 +3453,7 @@ static void hclge_reset(struct hclge_dev *hdev)
err_reset_lock:
rtnl_unlock();
err_reset:
- if (hclge_reset_err_handle(hdev, is_timeout))
+ if (hclge_reset_err_handle(hdev))
hclge_reset_task_schedule(hdev);
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 08/11] net: hns3: add interrupt affinity support for misc interrupt
From: Huazhong Tan @ 2019-07-24 3:18 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
Yunsheng Lin, Peng Li, Huazhong Tan
In-Reply-To: <1563938327-9865-1-git-send-email-tanhuazhong@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
The misc interrupt is used to schedule the reset and mailbox
subtask, and a 1 sec timer is used to schedule the service
subtask, which does periodic work.
This patch sets the above three subtask's affinity using the
misc interrupt' affinity.
Also this patch setups a affinity notify for misc interrupt to
allow user to change the above three subtask's affinity.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 59 ++++++++++++++++++++--
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 4 ++
2 files changed, 59 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 f345095..fe45986 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -1270,6 +1270,12 @@ static int hclge_configure(struct hclge_dev *hdev)
hclge_init_kdump_kernel_config(hdev);
+ /* Set the init affinity based on pci func number */
+ i = cpumask_weight(cpumask_of_node(dev_to_node(&hdev->pdev->dev)));
+ i = i ? PCI_FUNC(hdev->pdev->devfn) % i : 0;
+ cpumask_set_cpu(cpumask_local_spread(i, dev_to_node(&hdev->pdev->dev)),
+ &hdev->affinity_mask);
+
return ret;
}
@@ -2502,14 +2508,16 @@ static void hclge_mbx_task_schedule(struct hclge_dev *hdev)
{
if (!test_bit(HCLGE_STATE_CMD_DISABLE, &hdev->state) &&
!test_and_set_bit(HCLGE_STATE_MBX_SERVICE_SCHED, &hdev->state))
- schedule_work(&hdev->mbx_service_task);
+ queue_work_on(cpumask_first(&hdev->affinity_mask), system_wq,
+ &hdev->mbx_service_task);
}
static void hclge_reset_task_schedule(struct hclge_dev *hdev)
{
if (!test_bit(HCLGE_STATE_REMOVING, &hdev->state) &&
!test_and_set_bit(HCLGE_STATE_RST_SERVICE_SCHED, &hdev->state))
- schedule_work(&hdev->rst_service_task);
+ queue_work_on(cpumask_first(&hdev->affinity_mask), system_wq,
+ &hdev->rst_service_task);
}
static void hclge_task_schedule(struct hclge_dev *hdev)
@@ -2517,7 +2525,8 @@ static void hclge_task_schedule(struct hclge_dev *hdev)
if (!test_bit(HCLGE_STATE_DOWN, &hdev->state) &&
!test_bit(HCLGE_STATE_REMOVING, &hdev->state) &&
!test_and_set_bit(HCLGE_STATE_SERVICE_SCHED, &hdev->state))
- (void)schedule_work(&hdev->service_task);
+ queue_work_on(cpumask_first(&hdev->affinity_mask), system_wq,
+ &hdev->service_task);
}
static int hclge_get_mac_link_status(struct hclge_dev *hdev)
@@ -2921,6 +2930,39 @@ static void hclge_get_misc_vector(struct hclge_dev *hdev)
hdev->num_msi_used += 1;
}
+static void hclge_irq_affinity_notify(struct irq_affinity_notify *notify,
+ const cpumask_t *mask)
+{
+ struct hclge_dev *hdev = container_of(notify, struct hclge_dev,
+ affinity_notify);
+
+ cpumask_copy(&hdev->affinity_mask, mask);
+ del_timer_sync(&hdev->service_timer);
+ hdev->service_timer.expires = jiffies + HZ;
+ add_timer_on(&hdev->service_timer, cpumask_first(&hdev->affinity_mask));
+}
+
+static void hclge_irq_affinity_release(struct kref *ref)
+{
+}
+
+static void hclge_misc_affinity_setup(struct hclge_dev *hdev)
+{
+ irq_set_affinity_hint(hdev->misc_vector.vector_irq,
+ &hdev->affinity_mask);
+
+ hdev->affinity_notify.notify = hclge_irq_affinity_notify;
+ hdev->affinity_notify.release = hclge_irq_affinity_release;
+ irq_set_affinity_notifier(hdev->misc_vector.vector_irq,
+ &hdev->affinity_notify);
+}
+
+static void hclge_misc_affinity_teardown(struct hclge_dev *hdev)
+{
+ irq_set_affinity_notifier(hdev->misc_vector.vector_irq, NULL);
+ irq_set_affinity_hint(hdev->misc_vector.vector_irq, NULL);
+}
+
static int hclge_misc_irq_init(struct hclge_dev *hdev)
{
int ret;
@@ -6151,7 +6193,10 @@ static void hclge_set_timer_task(struct hnae3_handle *handle, bool enable)
struct hclge_dev *hdev = vport->back;
if (enable) {
- mod_timer(&hdev->service_timer, jiffies + HZ);
+ del_timer_sync(&hdev->service_timer);
+ hdev->service_timer.expires = jiffies + HZ;
+ add_timer_on(&hdev->service_timer,
+ cpumask_first(&hdev->affinity_mask));
} else {
del_timer_sync(&hdev->service_timer);
cancel_work_sync(&hdev->service_task);
@@ -8809,6 +8854,11 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
INIT_WORK(&hdev->rst_service_task, hclge_reset_service_task);
INIT_WORK(&hdev->mbx_service_task, hclge_mailbox_service_task);
+ /* Setup affinity after service timer setup because add_timer_on
+ * is called in affinity notify.
+ */
+ hclge_misc_affinity_setup(hdev);
+
hclge_clear_all_event_cause(hdev);
hclge_clear_resetting_state(hdev);
@@ -8970,6 +9020,7 @@ static void hclge_uninit_ae_dev(struct hnae3_ae_dev *ae_dev)
struct hclge_dev *hdev = ae_dev->priv;
struct hclge_mac *mac = &hdev->hw.mac;
+ hclge_misc_affinity_teardown(hdev);
hclge_state_uninit(hdev);
if (mac->phydev)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index 6a12285..14df23c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
@@ -864,6 +864,10 @@ struct hclge_dev {
DECLARE_KFIFO(mac_tnl_log, struct hclge_mac_tnl_stats,
HCLGE_MAC_TNL_LOG_SIZE);
+
+ /* affinity mask and notify for misc interrupt */
+ cpumask_t affinity_mask;
+ struct irq_affinity_notify affinity_notify;
};
/* VPort level vlan tag configuration for TX direction */
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 06/11] net: hns3: modify firmware version display format
From: Huazhong Tan @ 2019-07-24 3:18 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
Yufeng Mo, Peng Li, Huazhong Tan
In-Reply-To: <1563938327-9865-1-git-send-email-tanhuazhong@huawei.com>
From: Yufeng Mo <moyufeng@huawei.com>
This patch modifies firmware version display format in
hclge(vf)_cmd_init() and hns3_get_drvinfo(). Also, adds
some optimizations for firmware version display format.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 9 +++++++++
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 15 +++++++++++++--
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 10 +++++++++-
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 11 +++++++++--
4 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 48c7b70..a4624db 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -179,6 +179,15 @@ struct hnae3_vector_info {
#define HNAE3_RING_GL_RX 0
#define HNAE3_RING_GL_TX 1
+#define HNAE3_FW_VERSION_BYTE3_SHIFT 24
+#define HNAE3_FW_VERSION_BYTE3_MASK GENMASK(31, 24)
+#define HNAE3_FW_VERSION_BYTE2_SHIFT 16
+#define HNAE3_FW_VERSION_BYTE2_MASK GENMASK(23, 16)
+#define HNAE3_FW_VERSION_BYTE1_SHIFT 8
+#define HNAE3_FW_VERSION_BYTE1_MASK GENMASK(15, 8)
+#define HNAE3_FW_VERSION_BYTE0_SHIFT 0
+#define HNAE3_FW_VERSION_BYTE0_MASK GENMASK(7, 0)
+
struct hnae3_ring_chain_node {
struct hnae3_ring_chain_node *next;
u32 tqp_index;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 5bff98a..e71c92b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -527,6 +527,7 @@ static void hns3_get_drvinfo(struct net_device *netdev,
{
struct hns3_nic_priv *priv = netdev_priv(netdev);
struct hnae3_handle *h = priv->ae_handle;
+ u32 fw_version;
if (!h->ae_algo->ops->get_fw_version) {
netdev_err(netdev, "could not get fw version!\n");
@@ -545,8 +546,18 @@ static void hns3_get_drvinfo(struct net_device *netdev,
sizeof(drvinfo->bus_info));
drvinfo->bus_info[ETHTOOL_BUSINFO_LEN - 1] = '\0';
- snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version), "0x%08x",
- priv->ae_handle->ae_algo->ops->get_fw_version(h));
+ fw_version = priv->ae_handle->ae_algo->ops->get_fw_version(h);
+
+ snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
+ "%lu.%lu.%lu.%lu",
+ hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE3_MASK,
+ HNAE3_FW_VERSION_BYTE3_SHIFT),
+ hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE2_MASK,
+ HNAE3_FW_VERSION_BYTE2_SHIFT),
+ hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE1_MASK,
+ HNAE3_FW_VERSION_BYTE1_SHIFT),
+ hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE0_MASK,
+ HNAE3_FW_VERSION_BYTE0_SHIFT));
}
static u32 hns3_get_link(struct net_device *netdev)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index 22f6acd..c2320bf 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -419,7 +419,15 @@ int hclge_cmd_init(struct hclge_dev *hdev)
}
hdev->fw_version = version;
- dev_info(&hdev->pdev->dev, "The firmware version is %08x\n", version);
+ pr_info_once("The firmware version is %lu.%lu.%lu.%lu\n",
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE3_MASK,
+ HNAE3_FW_VERSION_BYTE3_SHIFT),
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE2_MASK,
+ HNAE3_FW_VERSION_BYTE2_SHIFT),
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE1_MASK,
+ HNAE3_FW_VERSION_BYTE1_SHIFT),
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE0_MASK,
+ HNAE3_FW_VERSION_BYTE0_SHIFT));
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
index 652b796..004125b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
@@ -405,8 +405,15 @@ int hclgevf_cmd_init(struct hclgevf_dev *hdev)
}
hdev->fw_version = version;
- dev_info(&hdev->pdev->dev, "The firmware version is %08x\n", version);
-
+ pr_info_once("The firmware version is %lu.%lu.%lu.%lu\n",
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE3_MASK,
+ HNAE3_FW_VERSION_BYTE3_SHIFT),
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE2_MASK,
+ HNAE3_FW_VERSION_BYTE2_SHIFT),
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE1_MASK,
+ HNAE3_FW_VERSION_BYTE1_SHIFT),
+ hnae3_get_field(version, HNAE3_FW_VERSION_BYTE0_MASK,
+ HNAE3_FW_VERSION_BYTE0_SHIFT));
return 0;
err_cmd_init:
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 09/11] net: hns3: make hclge_service use delayed workqueue
From: Huazhong Tan @ 2019-07-24 3:18 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
Yunsheng Lin, Huazhong Tan
In-Reply-To: <1563938327-9865-1-git-send-email-tanhuazhong@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
Use delayed work instead of using timers to trigger the
hclge_serive.
Simplify the code with one less middle function and in order
to support misc irq affinity.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Reviewed-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 60 ++++++++--------------
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 3 +-
2 files changed, 22 insertions(+), 41 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index fe45986..45acbc9 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2524,9 +2524,13 @@ static void hclge_task_schedule(struct hclge_dev *hdev)
{
if (!test_bit(HCLGE_STATE_DOWN, &hdev->state) &&
!test_bit(HCLGE_STATE_REMOVING, &hdev->state) &&
- !test_and_set_bit(HCLGE_STATE_SERVICE_SCHED, &hdev->state))
- queue_work_on(cpumask_first(&hdev->affinity_mask), system_wq,
- &hdev->service_task);
+ !test_and_set_bit(HCLGE_STATE_SERVICE_SCHED, &hdev->state)) {
+ hdev->hw_stats.stats_timer++;
+ hdev->fd_arfs_expire_timer++;
+ mod_delayed_work_on(cpumask_first(&hdev->affinity_mask),
+ system_wq, &hdev->service_task,
+ round_jiffies_relative(HZ));
+ }
}
static int hclge_get_mac_link_status(struct hclge_dev *hdev)
@@ -2741,25 +2745,6 @@ static int hclge_get_status(struct hnae3_handle *handle)
return hdev->hw.mac.link;
}
-static void hclge_service_timer(struct timer_list *t)
-{
- struct hclge_dev *hdev = from_timer(hdev, t, service_timer);
-
- mod_timer(&hdev->service_timer, jiffies + HZ);
- hdev->hw_stats.stats_timer++;
- hdev->fd_arfs_expire_timer++;
- hclge_task_schedule(hdev);
-}
-
-static void hclge_service_complete(struct hclge_dev *hdev)
-{
- WARN_ON(!test_bit(HCLGE_STATE_SERVICE_SCHED, &hdev->state));
-
- /* Flush memory before next watchdog */
- smp_mb__before_atomic();
- clear_bit(HCLGE_STATE_SERVICE_SCHED, &hdev->state);
-}
-
static u32 hclge_check_event_cause(struct hclge_dev *hdev, u32 *clearval)
{
u32 rst_src_reg, cmdq_src_reg, msix_src_reg;
@@ -2937,9 +2922,6 @@ static void hclge_irq_affinity_notify(struct irq_affinity_notify *notify,
affinity_notify);
cpumask_copy(&hdev->affinity_mask, mask);
- del_timer_sync(&hdev->service_timer);
- hdev->service_timer.expires = jiffies + HZ;
- add_timer_on(&hdev->service_timer, cpumask_first(&hdev->affinity_mask));
}
static void hclge_irq_affinity_release(struct kref *ref)
@@ -3639,7 +3621,9 @@ static void hclge_update_vport_alive(struct hclge_dev *hdev)
static void hclge_service_task(struct work_struct *work)
{
struct hclge_dev *hdev =
- container_of(work, struct hclge_dev, service_task);
+ container_of(work, struct hclge_dev, service_task.work);
+
+ clear_bit(HCLGE_STATE_SERVICE_SCHED, &hdev->state);
if (hdev->hw_stats.stats_timer >= HCLGE_STATS_TIMER_INTERVAL) {
hclge_update_stats_for_all(hdev);
@@ -3654,7 +3638,8 @@ static void hclge_service_task(struct work_struct *work)
hclge_rfs_filter_expire(hdev);
hdev->fd_arfs_expire_timer = 0;
}
- hclge_service_complete(hdev);
+
+ hclge_task_schedule(hdev);
}
struct hclge_vport *hclge_get_vport(struct hnae3_handle *handle)
@@ -6193,13 +6178,13 @@ static void hclge_set_timer_task(struct hnae3_handle *handle, bool enable)
struct hclge_dev *hdev = vport->back;
if (enable) {
- del_timer_sync(&hdev->service_timer);
- hdev->service_timer.expires = jiffies + HZ;
- add_timer_on(&hdev->service_timer,
- cpumask_first(&hdev->affinity_mask));
+ hclge_task_schedule(hdev);
} else {
- del_timer_sync(&hdev->service_timer);
- cancel_work_sync(&hdev->service_task);
+ /* Set the DOWN flag here to disable the service to be
+ * scheduled again
+ */
+ set_bit(HCLGE_STATE_DOWN, &hdev->state);
+ cancel_delayed_work_sync(&hdev->service_task);
clear_bit(HCLGE_STATE_SERVICE_SCHED, &hdev->state);
}
}
@@ -8638,12 +8623,10 @@ static void hclge_state_uninit(struct hclge_dev *hdev)
set_bit(HCLGE_STATE_DOWN, &hdev->state);
set_bit(HCLGE_STATE_REMOVING, &hdev->state);
- if (hdev->service_timer.function)
- del_timer_sync(&hdev->service_timer);
if (hdev->reset_timer.function)
del_timer_sync(&hdev->reset_timer);
- if (hdev->service_task.func)
- cancel_work_sync(&hdev->service_task);
+ if (hdev->service_task.work.func)
+ cancel_delayed_work_sync(&hdev->service_task);
if (hdev->rst_service_task.func)
cancel_work_sync(&hdev->rst_service_task);
if (hdev->mbx_service_task.func)
@@ -8848,9 +8831,8 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
hclge_dcb_ops_set(hdev);
- timer_setup(&hdev->service_timer, hclge_service_timer, 0);
timer_setup(&hdev->reset_timer, hclge_reset_timer, 0);
- INIT_WORK(&hdev->service_task, hclge_service_task);
+ INIT_DELAYED_WORK(&hdev->service_task, hclge_service_task);
INIT_WORK(&hdev->rst_service_task, hclge_reset_service_task);
INIT_WORK(&hdev->mbx_service_task, hclge_mailbox_service_task);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index 14df23c..688e425 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
@@ -806,9 +806,8 @@ struct hclge_dev {
u16 adminq_work_limit; /* Num of admin receive queue desc to process */
unsigned long service_timer_period;
unsigned long service_timer_previous;
- struct timer_list service_timer;
struct timer_list reset_timer;
- struct work_struct service_task;
+ struct delayed_work service_task;
struct work_struct rst_service_task;
struct work_struct mbx_service_task;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 00/11] net: hns3: some code optimizations & bugfixes & features
From: Huazhong Tan @ 2019-07-24 3:18 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
Huazhong Tan
This patch-set includes code optimizations, bugfixes and features for
the HNS3 ethernet controller driver.
[patch 1/11] checks reset status before setting channel.
[patch 2/11] adds a NULL pointer checking.
[patch 3/11] removes reset level upgrading when current reset fails.
[patch 4/11] fixes a bug related to IRQ vector number initialization.
[patch 5/11] fixes a GFP flags errors when holding spin_lock.
[patch 6/11] modifies firmware version format.
[patch 7/11] adds some print information.
[patch 8/11 - 9/11] adds two code optimizations about interrupt handler
and work task.
[patch 10/11] adds support for using order 1 pages with a 4K buffer.
[patch 11/11] adds a detection about the reason of IMP errors.
Guangbin Huang (1):
net: hns3: add a check for get_reset_level
Huazhong Tan (1):
net: hns3: remove upgrade reset level when reset fail
Jian Shen (1):
net: hns3: add reset checking before set channels
Weihang Li (1):
net: hns3: add support for handling IMP error
Yonglong Liu (2):
net: hns3: fix mis-counting IRQ vector numbers issue
net: hns3: adds debug messages to identify eth down cause
Yufeng Mo (2):
net: hns3: change GFP flag during lock period
net: hns3: modify firmware version display format
Yunsheng Lin (3):
net: hns3: add interrupt affinity support for misc interrupt
net: hns3: make hclge_service use delayed workqueue
net: hns3: Add support for using order 1 pages with a 4K buffer
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 10 ++
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 39 ++++-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 15 +-
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 41 ++++-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 10 +-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 14 ++
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 37 ++++-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h | 4 +
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 165 ++++++++++++++-------
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 16 +-
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 11 +-
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 12 +-
12 files changed, 298 insertions(+), 76 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: Reminder: 3 open syzbot bugs in vhost subsystem
From: Eric Biggers @ 2019-07-24 3:13 UTC (permalink / raw)
To: Jason Wang
Cc: kvm, virtualization, netdev, Michael S. Tsirkin, linux-kernel,
syzkaller-bugs
In-Reply-To: <fabf96ac-e472-c7fd-07ff-486fe03e6433@redhat.com>
On Wed, Jul 24, 2019 at 11:05:14AM +0800, Jason Wang wrote:
> > --------------------------------------------------------------------------------
> > Title: KASAN: use-after-free Write in tlb_finish_mmu
> > Last occurred: 5 days ago
> > Reported: 4 days ago
> > Branches: Mainline
> > Dashboard link: https://syzkaller.appspot.com/bug?id=d57b94f89e48c85ef7d95acc208209ea4bdc10de
> > Original thread: https://lkml.kernel.org/lkml/00000000000045e7a1058e02458a@google.com/T/#u
> >
> > This bug has a syzkaller reproducer only.
> >
> > This bug was bisected to:
> >
> > commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
> > Author: Jason Wang <jasowang@redhat.com>
> > Date: Fri May 24 08:12:18 2019 +0000
> >
> > vhost: access vq metadata through kernel virtual address
> >
> > No one has replied to the original thread for this bug yet.
> >
> > If you fix this bug, please add the following tag to the commit:
> > Reported-by: syzbot+8267e9af795434ffadad@syzkaller.appspotmail.com
> >
> > If you send any email or patch for this bug, please reply to the original
> > thread. For the git send-email command to use, or tips on how to reply if the
> > thread isn't in your mailbox, see the "Reply instructions" at
> > https://lkml.kernel.org/r/00000000000045e7a1058e02458a@google.com
> >
> > --------------------------------------------------------------------------------
> > Title: KASAN: use-after-free Read in finish_task_switch (2)
> > Last occurred: 5 days ago
> > Reported: 4 days ago
> > Branches: Mainline
> > Dashboard link: https://syzkaller.appspot.com/bug?id=9a98fcad6c8bd31f5c3afbdc6c75de9f082c0ffa
> > Original thread: https://lkml.kernel.org/lkml/000000000000490679058e0245ee@google.com/T/#u
> >
> > This bug has a syzkaller reproducer only.
> >
> > This bug was bisected to:
> >
> > commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
> > Author: Jason Wang <jasowang@redhat.com>
> > Date: Fri May 24 08:12:18 2019 +0000
> >
> > vhost: access vq metadata through kernel virtual address
> >
> > No one has replied to the original thread for this bug yet.
>
>
> Hi:
>
> We believe above two bugs are duplicated with the report "WARNING in
> __mmdrop". Can I just dup them with
>
> #syz dup "WARNING in __mmdrop"
>
> (If yes, just wonder how syzbot differ bugs, technically, several different
> bug can hit the same warning).
>
Yes, please mark them as duplicates; see https://goo.gl/tpsmEJ#status for
correct syntax. You need to send the command to the syzbot email address
specific to each bug. Easiest way is to reply to the original threads.
- Eric
^ permalink raw reply
* Re: Re: Reminder: 3 open syzbot bugs in vhost subsystem
From: syzbot @ 2019-07-24 3:05 UTC (permalink / raw)
To: Jason Wang
Cc: jasowang, kvm, linux-kernel, mst, netdev, syzkaller-bugs,
virtualization
In-Reply-To: <fabf96ac-e472-c7fd-07ff-486fe03e6433@redhat.com>
> On 2019/7/24 上午10:38, Eric Biggers wrote:
>> [This email was generated by a script. Let me know if you have any
>> suggestions
>> to make it better, or if you want it re-generated with the latest
>> status.]
>> Of the currently open syzbot reports against the upstream kernel, I've
>> manually
>> marked 3 of them as possibly being bugs in the vhost subsystem. I've
>> listed
>> these reports below, sorted by an algorithm that tries to list first the
>> reports
>> most likely to be still valid, important, and actionable.
>> Of these 3 bugs, 2 were seen in mainline in the last week.
>> Of these 3 bugs, 2 were bisected to commits from the following person:
>> Jason Wang <jasowang@redhat.com>
>> If you believe a bug is no longer valid, please close the syzbot report
>> by
>> sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to
>> the
>> original thread, as explained at https://goo.gl/tpsmEJ#status
>> If you believe I misattributed a bug to the vhost subsystem, please let
>> me know,
>> and if possible forward the report to the correct people or mailing list.
>> Here are the bugs:
>> --------------------------------------------------------------------------------
>> Title: KASAN: use-after-free Write in tlb_finish_mmu
>> Last occurred: 5 days ago
>> Reported: 4 days ago
>> Branches: Mainline
>> Dashboard link:
>> https://syzkaller.appspot.com/bug?id=d57b94f89e48c85ef7d95acc208209ea4bdc10de
>> Original thread:
>> https://lkml.kernel.org/lkml/00000000000045e7a1058e02458a@google.com/T/#u
>> This bug has a syzkaller reproducer only.
>> This bug was bisected to:
>> commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
>> Author: Jason Wang <jasowang@redhat.com>
>> Date: Fri May 24 08:12:18 2019 +0000
>> vhost: access vq metadata through kernel virtual address
>> No one has replied to the original thread for this bug yet.
>> If you fix this bug, please add the following tag to the commit:
>> Reported-by: syzbot+8267e9af795434ffadad@syzkaller.appspotmail.com
>> If you send any email or patch for this bug, please reply to the original
>> thread. For the git send-email command to use, or tips on how to reply
>> if the
>> thread isn't in your mailbox, see the "Reply instructions" at
>> https://lkml.kernel.org/r/00000000000045e7a1058e02458a@google.com
>> --------------------------------------------------------------------------------
>> Title: KASAN: use-after-free Read in finish_task_switch (2)
>> Last occurred: 5 days ago
>> Reported: 4 days ago
>> Branches: Mainline
>> Dashboard link:
>> https://syzkaller.appspot.com/bug?id=9a98fcad6c8bd31f5c3afbdc6c75de9f082c0ffa
>> Original thread:
>> https://lkml.kernel.org/lkml/000000000000490679058e0245ee@google.com/T/#u
>> This bug has a syzkaller reproducer only.
>> This bug was bisected to:
>> commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
>> Author: Jason Wang <jasowang@redhat.com>
>> Date: Fri May 24 08:12:18 2019 +0000
>> vhost: access vq metadata through kernel virtual address
>> No one has replied to the original thread for this bug yet.
> Hi:
> We believe above two bugs are duplicated with the report "WARNING in
> __mmdrop". Can I just dup them with
> #syz dup "WARNING in __mmdrop"
I see the command but can't find the corresponding bug.
Please resend the email to syzbot+HASH@syzkaller.appspotmail.com address
that is the sender of the bug report (also present in the Reported-by tag).
> (If yes, just wonder how syzbot differ bugs, technically, several
> different bug can hit the same warning).
>> If you fix this bug, please add the following tag to the commit:
>> Reported-by: syzbot+7f067c796eee2acbc57a@syzkaller.appspotmail.com
>> If you send any email or patch for this bug, please reply to the original
>> thread. For the git send-email command to use, or tips on how to reply
>> if the
>> thread isn't in your mailbox, see the "Reply instructions" at
>> https://lkml.kernel.org/r/000000000000490679058e0245ee@google.com
>> --------------------------------------------------------------------------------
>> Title: memory leak in vhost_net_ioctl
>> Last occurred: 22 days ago
>> Reported: 48 days ago
>> Branches: Mainline
>> Dashboard link:
>> https://syzkaller.appspot.com/bug?id=12ba349d7e26ccfe95317bc376e812ebbae2ee0f
>> Original thread:
>> https://lkml.kernel.org/lkml/000000000000188da1058a9c25e3@google.com/T/#u
>> This bug has a C reproducer.
>> The original thread for this bug has received 4 replies; the last was 39
>> days
>> ago.
>> If you fix this bug, please add the following tag to the commit:
>> Reported-by: syzbot+0789f0c7e45efd7bb643@syzkaller.appspotmail.com
> I do remember it can not be reproduced upstream, let me double check and
> close this one.
> Thanks
>> If you send any email or patch for this bug, please consider replying to
>> the
>> original thread. For the git send-email command to use, or tips on how
>> to reply
>> if the thread isn't in your mailbox, see the "Reply instructions" at
>> https://lkml.kernel.org/r/000000000000188da1058a9c25e3@google.com
> --
> You received this message because you are subscribed to the Google
> Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/fabf96ac-e472-c7fd-07ff-486fe03e6433%40redhat.com.
^ permalink raw reply
* Re: Reminder: 3 open syzbot bugs in vhost subsystem
From: Jason Wang @ 2019-07-24 3:05 UTC (permalink / raw)
To: kvm, virtualization, netdev, Michael S. Tsirkin, linux-kernel,
syzkaller-bugs
In-Reply-To: <20190724023835.GY643@sol.localdomain>
On 2019/7/24 上午10:38, Eric Biggers wrote:
> [This email was generated by a script. Let me know if you have any suggestions
> to make it better, or if you want it re-generated with the latest status.]
>
> Of the currently open syzbot reports against the upstream kernel, I've manually
> marked 3 of them as possibly being bugs in the vhost subsystem. I've listed
> these reports below, sorted by an algorithm that tries to list first the reports
> most likely to be still valid, important, and actionable.
>
> Of these 3 bugs, 2 were seen in mainline in the last week.
>
> Of these 3 bugs, 2 were bisected to commits from the following person:
>
> Jason Wang <jasowang@redhat.com>
>
> If you believe a bug is no longer valid, please close the syzbot report by
> sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
> original thread, as explained at https://goo.gl/tpsmEJ#status
>
> If you believe I misattributed a bug to the vhost subsystem, please let me know,
> and if possible forward the report to the correct people or mailing list.
>
> Here are the bugs:
>
> --------------------------------------------------------------------------------
> Title: KASAN: use-after-free Write in tlb_finish_mmu
> Last occurred: 5 days ago
> Reported: 4 days ago
> Branches: Mainline
> Dashboard link: https://syzkaller.appspot.com/bug?id=d57b94f89e48c85ef7d95acc208209ea4bdc10de
> Original thread: https://lkml.kernel.org/lkml/00000000000045e7a1058e02458a@google.com/T/#u
>
> This bug has a syzkaller reproducer only.
>
> This bug was bisected to:
>
> commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
> Author: Jason Wang <jasowang@redhat.com>
> Date: Fri May 24 08:12:18 2019 +0000
>
> vhost: access vq metadata through kernel virtual address
>
> No one has replied to the original thread for this bug yet.
>
> If you fix this bug, please add the following tag to the commit:
> Reported-by: syzbot+8267e9af795434ffadad@syzkaller.appspotmail.com
>
> If you send any email or patch for this bug, please reply to the original
> thread. For the git send-email command to use, or tips on how to reply if the
> thread isn't in your mailbox, see the "Reply instructions" at
> https://lkml.kernel.org/r/00000000000045e7a1058e02458a@google.com
>
> --------------------------------------------------------------------------------
> Title: KASAN: use-after-free Read in finish_task_switch (2)
> Last occurred: 5 days ago
> Reported: 4 days ago
> Branches: Mainline
> Dashboard link: https://syzkaller.appspot.com/bug?id=9a98fcad6c8bd31f5c3afbdc6c75de9f082c0ffa
> Original thread: https://lkml.kernel.org/lkml/000000000000490679058e0245ee@google.com/T/#u
>
> This bug has a syzkaller reproducer only.
>
> This bug was bisected to:
>
> commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
> Author: Jason Wang <jasowang@redhat.com>
> Date: Fri May 24 08:12:18 2019 +0000
>
> vhost: access vq metadata through kernel virtual address
>
> No one has replied to the original thread for this bug yet.
Hi:
We believe above two bugs are duplicated with the report "WARNING in
__mmdrop". Can I just dup them with
#syz dup "WARNING in __mmdrop"
(If yes, just wonder how syzbot differ bugs, technically, several
different bug can hit the same warning).
>
> If you fix this bug, please add the following tag to the commit:
> Reported-by: syzbot+7f067c796eee2acbc57a@syzkaller.appspotmail.com
>
> If you send any email or patch for this bug, please reply to the original
> thread. For the git send-email command to use, or tips on how to reply if the
> thread isn't in your mailbox, see the "Reply instructions" at
> https://lkml.kernel.org/r/000000000000490679058e0245ee@google.com
>
> --------------------------------------------------------------------------------
> Title: memory leak in vhost_net_ioctl
> Last occurred: 22 days ago
> Reported: 48 days ago
> Branches: Mainline
> Dashboard link: https://syzkaller.appspot.com/bug?id=12ba349d7e26ccfe95317bc376e812ebbae2ee0f
> Original thread: https://lkml.kernel.org/lkml/000000000000188da1058a9c25e3@google.com/T/#u
>
> This bug has a C reproducer.
>
> The original thread for this bug has received 4 replies; the last was 39 days
> ago.
>
> If you fix this bug, please add the following tag to the commit:
> Reported-by: syzbot+0789f0c7e45efd7bb643@syzkaller.appspotmail.com
I do remember it can not be reproduced upstream, let me double check and
close this one.
Thanks
>
> If you send any email or patch for this bug, please consider replying to the
> original thread. For the git send-email command to use, or tips on how to reply
> if the thread isn't in your mailbox, see the "Reply instructions" at
> https://lkml.kernel.org/r/000000000000188da1058a9c25e3@google.com
>
^ permalink raw reply
* Reminder: 1 open syzbot bug in "net/pfkey" subsystem
From: Eric Biggers @ 2019-07-24 2:52 UTC (permalink / raw)
To: netdev, Steffen Klassert, Herbert Xu, David S. Miller
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 1 of them as possibly being a bug in the "net/pfkey" subsystem.
If you believe this bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed this bug to the "net/pfkey" subsystem, please let
me know, and if possible forward the report to the correct people or mailing
list.
Here is the bug:
--------------------------------------------------------------------------------
Title: WARNING in pfkey_sock_destruct
Last occurred: 168 days ago
Reported: 300 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=6dc52e859d5ccc5fdce168973ab63b97ac7e41ba
Original thread: https://lkml.kernel.org/lkml/0000000000002b8eb70576c15840@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+4acf0d9092f91bb60431@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000002b8eb70576c15840@google.com
^ permalink raw reply
* Reminder: 1 open syzbot bug in "net/ppp" subsystem
From: Eric Biggers @ 2019-07-24 2:52 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 1 of them as possibly being a bug in the "net/ppp" subsystem.
If you believe this bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed this bug to the "net/ppp" subsystem, please let
me know, and if possible forward the report to the correct people or mailing
list.
Here is the bug:
--------------------------------------------------------------------------------
Title: memory leak in pppoe_sendmsg
Last occurred: 6 days ago
Reported: 53 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=68fe3119847862315e52aa14961144b5a909bc23
Original thread: https://lkml.kernel.org/lkml/000000000000d981f1058a26e1a8@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+6bdfd184eac7709e5cc9@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000d981f1058a26e1a8@google.com
^ permalink raw reply
* Reminder: 1 open syzbot bug in "net/strparser" subsystem
From: Eric Biggers @ 2019-07-24 2:51 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 1 of them as possibly being a bug in the "net/strparser" subsystem.
If you believe this bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed this bug to the "net/strparser" subsystem, please
let me know, and if possible forward the report to the correct people or mailing
list.
Here is the bug:
--------------------------------------------------------------------------------
Title: WARNING in strp_done (2)
Last occurred: 163 days ago
Reported: 174 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=95997d9e84b5e2f966ac13c3ccf01670e77ca4f6
Original thread: https://lkml.kernel.org/lkml/0000000000007c36aa0580b16b56@google.com/T/#u
This bug has a syzkaller reproducer only.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+ea38a133bb90dd367b6e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000007c36aa0580b16b56@google.com
^ permalink raw reply
* Reminder: 1 open syzbot bug in "net/sunrpc" subsystem
From: Eric Biggers @ 2019-07-24 2:51 UTC (permalink / raw)
To: linux-nfs, netdev, Trond Myklebust, Anna Schumaker,
J. Bruce Fields, Chuck Lever, David S. Miller
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 1 of them as possibly being a bug in the "net/sunrpc" subsystem.
If you believe this bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed this bug to the "net/sunrpc" subsystem, please
let me know, and if possible forward the report to the correct people or mailing
list.
Here is the bug:
--------------------------------------------------------------------------------
Title: linux-next test error: WARNING in remove_proc_entry
Last occurred: 69 days ago
Reported: 71 days ago
Branches: linux-next
Dashboard link: https://syzkaller.appspot.com/bug?id=0b23d0049d5af6699d68ff17e2db121569b78fd4
Original thread: https://lkml.kernel.org/lkml/00000000000055d6590588bf90bf@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+4887e9dd9042fae2a9c2@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000055d6590588bf90bf@google.com
^ permalink raw reply
* Reminder: 2 open syzbot bugs in "net/l2tp" subsystem
From: Eric Biggers @ 2019-07-24 2:45 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 2 of them as possibly being bugs in the "net/l2tp" subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
Of these 2 bugs, 1 was seen in mainline in the last week.
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/l2tp" subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: WARNING: locking bug in inet_autobind
Last occurred: 1 day ago
Reported: 68 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=a7d678fba80c34b5770cc1b5638b8a2709ae9f3f
Original thread: https://lkml.kernel.org/lkml/00000000000033a0120588fac894@google.com/T/#u
This bug has a syzkaller reproducer only.
syzbot has bisected this bug, but I think the bisection result is incorrect.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+94cc2a66fc228b23f360@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000033a0120588fac894@google.com
--------------------------------------------------------------------------------
Title: WARNING: locking bug in do_ipv6_setsockopt
Last occurred: 4 days ago
Reported: 62 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=6a970baf20aa5a64455be86fb920f468def703c6
Original thread: https://lkml.kernel.org/lkml/000000000000f7707805897c071f@google.com/T/#u
This bug has a syzkaller reproducer only.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+f28170ca1ee366e97283@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000f7707805897c071f@google.com
^ permalink raw reply
* Reminder: 2 open syzbot bugs in "net/rxrpc" subsystem
From: Eric Biggers @ 2019-07-24 2:44 UTC (permalink / raw)
To: linux-afs, netdev, David Howells, David S. Miller
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 2 of them as possibly being bugs in the "net/rxrpc" subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
Of these 2 bugs, 1 was seen in mainline in the last week.
Of these 2 bugs, 1 was bisected to a commit from the following person:
David Howells <dhowells@redhat.com>
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/rxrpc" subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: kernel BUG at net/rxrpc/local_object.c:LINE!
Last occurred: 2 days ago
Reported: 25 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=53b6555b27af2cae74e2fbdac6cadc73f9cb18aa
Original thread: https://lkml.kernel.org/lkml/0000000000004c2416058c594b30@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit 46894a13599a977ac35411b536fb3e0b2feefa95
Author: David Howells <dhowells@redhat.com>
Date: Thu Oct 4 08:32:28 2018 +0000
rxrpc: Use IPv4 addresses throught the IPv6
The original thread for this bug has received 3 replies; the last was 18 days
ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+1e0edc4b8b7494c28450@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000004c2416058c594b30@google.com
--------------------------------------------------------------------------------
Title: WARNING: locking bug in flush_workqueue_prep_pwqs
Last occurred: 30 days ago
Reported: 158 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=4ae48f9c43f87ccf9f2f270b14d5b9284dadd05c
Original thread: https://lkml.kernel.org/lkml/0000000000005c7e6f0581f1b86a@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+0c4264acb66ea0484d11@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000005c7e6f0581f1b86a@google.com
^ permalink raw reply
* Reminder: 3 open syzbot bugs in "net/ax25" subsystem
From: Eric Biggers @ 2019-07-24 2:40 UTC (permalink / raw)
To: linux-hams, netdev, Ralf Baechle, David S. Miller
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 3 of them as possibly being bugs in the "net/ax25" subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/ax25" subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: general protection fault in ax25_send_frame
Last occurred: 0 days ago
Reported: 204 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=1cdd5b120f129364fc8e9b2b027826cf99fa696e
Original thread: https://lkml.kernel.org/lkml/0000000000009ea37c057e58d787@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+e0b81535a27b8be39502@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009ea37c057e58d787@google.com
--------------------------------------------------------------------------------
Title: KASAN: stack-out-of-bounds Write in ax25_getname
Last occurred: 90 days ago
Reported: 206 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=fb195f91dc044978c1b186f1288b1eff61edcc20
Original thread: https://lkml.kernel.org/lkml/000000000000ed4120057e2df0c6@google.com/T/#u
This bug has a syzkaller reproducer only.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+6a29097222b4d3b8617c@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ed4120057e2df0c6@google.com
--------------------------------------------------------------------------------
Title: inconsistent lock state in ax25_std_heartbeat_expiry
Last occurred: 122 days ago
Reported: 120 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=9086a8eac930890b2730d6441093bd478e32913f
Original thread: https://lkml.kernel.org/lkml/0000000000001b07250584efbee3@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
The original thread for this bug received 2 replies; the last was 119 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+e350b81e95a6a214da8a@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000001b07250584efbee3@google.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox