* [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
* Reminder: 3 open syzbot bugs in "net/kcm" subsystem
From: Eric Biggers @ 2019-07-24 2:39 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 3 of them as possibly being bugs in the "net/kcm" 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 "net/kcm" 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 ip_tunnel_xmit (2)
Last occurred: 0 days ago
Reported: 347 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=b0e069ac9b03eab43b106c22fcc8bd778a7ccfb5
Original thread: https://lkml.kernel.org/lkml/0000000000005012b605731594e3@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug received 1 reply, 347 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+4a2c52677a8a1aa283cb@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/0000000000005012b605731594e3@google.com
--------------------------------------------------------------------------------
Title: general protection fault in skb_unlink
Last occurred: 182 days ago
Reported: 418 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=2d6d1853e26eb3b70cd558298ebf0c98157fcccf
Original thread: https://lkml.kernel.org/lkml/000000000000fdc15c056d7c13ae@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+278279efdd2730dd14bf@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/000000000000fdc15c056d7c13ae@google.com
--------------------------------------------------------------------------------
Title: general protection fault in requeue_rx_msgs
Last occurred: 419 days ago
Reported: 418 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=da9b672629747f28e76eca9949696c410cb75d7b
Original thread: https://lkml.kernel.org/lkml/0000000000000482ce056d7c1436@google.com/T/#u
This bug has a syzkaller reproducer only.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 1 reply, 418 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+554266c04a41d1f9754d@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/0000000000000482ce056d7c1436@google.com
^ permalink raw reply
* Reminder: 3 open syzbot bugs in "net/llc" subsystem
From: Eric Biggers @ 2019-07-24 2:39 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 3 of them as possibly being bugs in the "net/llc" 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, 3 were 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/llc" subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: memory leak in llc_conn_ac_send_sabme_cmd_p_set_x
Last occurred: 0 days ago
Reported: 63 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=1c2132cc5a2f0d05091adc4f2ed088020522f73a
Original thread: https://lkml.kernel.org/lkml/0000000000005974af0589660739@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+6b825a6494a04cc0e3f7@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/0000000000005974af0589660739@google.com
--------------------------------------------------------------------------------
Title: memory leak in llc_ui_sendmsg
Last occurred: 1 day ago
Reported: 63 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=4e8b3190d51a3b721b554f103da5399613748ea0
Original thread: https://lkml.kernel.org/lkml/0000000000009382e7058965fc65@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+31c16aa4202dace3812e@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/0000000000009382e7058965fc65@google.com
--------------------------------------------------------------------------------
Title: memory leak in llc_ui_create (2)
Last occurred: 6 days ago
Reported: 32 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=ecc7f04cd94b5c062c000865d43bfb682d718b8e
Original thread: https://lkml.kernel.org/lkml/000000000000058a0f058bd50068@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+6bf095f9becf5efef645@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/000000000000058a0f058bd50068@google.com
^ permalink raw reply
* Reminder: 3 open syzbot bugs in "net/rose" subsystem
From: Eric Biggers @ 2019-07-24 2:39 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/rose" 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 "net/rose" 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 rose_send_frame
Last occurred: 2 days ago
Reported: 194 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=f46c94afb217ab49c75350adbd467d86ae2b59a6
Original thread: https://lkml.kernel.org/lkml/00000000000089904d057f1e0ae0@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+7078ae989d857fe17988@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/00000000000089904d057f1e0ae0@google.com
--------------------------------------------------------------------------------
Title: INFO: rcu detected stall in rose_loopback_timer (2)
Last occurred: 46 days ago
Reported: 44 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=42c06438fe5956ab9978486a1898ca2f23b1fc1f
Original thread: https://lkml.kernel.org/lkml/000000000000cf98fa058adf3615@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+d37efb0ca1b82682326e@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/000000000000cf98fa058adf3615@google.com
--------------------------------------------------------------------------------
Title: INFO: rcu detected stall in rose_connect
Last occurred: 52 days ago
Reported: 49 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=0b258dc8ece5bb93dfb5a137ae25a6db300d5892
Original thread: https://lkml.kernel.org/lkml/00000000000017b026058a785790@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+af81c7a21a31b18bec0e@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/00000000000017b026058a785790@google.com
^ permalink raw reply
* Reminder: 3 open syzbot bugs in vhost subsystem
From: Eric Biggers @ 2019-07-24 2:38 UTC (permalink / raw)
To: kvm, virtualization, netdev, Michael S. Tsirkin, Jason Wang
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 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.
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
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
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