This is a note to let you know that I've just added the patch titled
PCI: Detach driver before procfs & sysfs teardown on device remove
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-detach-driver-before-procfs-sysfs-teardown-on-device-remove.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Alex Williamson <alex.williamson(a)redhat.com>
Date: Wed, 11 Oct 2017 15:35:56 -0600
Subject: PCI: Detach driver before procfs & sysfs teardown on device remove
From: Alex Williamson <alex.williamson(a)redhat.com>
[ Upstream commit 16b6c8bb687cc3bec914de09061fcb8411951fda ]
When removing a device, for example a VF being removed due to SR-IOV
teardown, a "soft" hot-unplug via 'echo 1 > remove' in sysfs, or an actual
hot-unplug, we first remove the procfs and sysfs attributes for the device
before attempting to release the device from any driver bound to it.
Unbinding the driver from the device can take time. The device might need
to write out data or it might be actively in use. If it's in use by
userspace through a vfio driver, the unbind might block until the user
releases the device. This leads to a potentially non-trivial amount of
time where the device exists, but we've torn down the interfaces that
userspace uses to examine devices, for instance lspci might generate this
sort of error:
pcilib: Cannot open /sys/bus/pci/devices/0000:01:0a.3/config
lspci: Unable to read the standard configuration space header of device 0000:01:0a.3
We don't seem to have any dependence on this teardown ordering in the
kernel, so let's unbind the driver first, which is also more symmetric with
the instantiation of the device in pci_bus_add_device().
Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/remove.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -19,9 +19,9 @@ static void pci_stop_dev(struct pci_dev
pci_pme_active(dev, false);
if (dev->is_added) {
+ device_release_driver(&dev->dev);
pci_proc_detach_device(dev);
pci_remove_sysfs_dev_files(dev);
- device_release_driver(&dev->dev);
dev->is_added = 0;
}
Patches currently in stable-queue which might be from alex.williamson(a)redhat.com are
queue-4.14/pci-detach-driver-before-procfs-sysfs-teardown-on-device-remove.patch
queue-4.14/iommu-amd-limit-the-iova-page-range-to-the-specified-addresses.patch
queue-4.14/iommu-mediatek-fix-driver-name.patch
This is a note to let you know that I've just added the patch titled
nvme: use kref_get_unless_zero in nvme_find_get_ns
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nvme-use-kref_get_unless_zero-in-nvme_find_get_ns.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Christoph Hellwig <hch(a)lst.de>
Date: Wed, 18 Oct 2017 13:20:01 +0200
Subject: nvme: use kref_get_unless_zero in nvme_find_get_ns
From: Christoph Hellwig <hch(a)lst.de>
[ Upstream commit 2dd4122854f697afc777582d18548dded03ce5dd ]
For kref_get_unless_zero to protect against lookup vs free races we need
to use it in all places where we aren't guaranteed to already hold a
reference. There is no such guarantee in nvme_find_get_ns, so switch to
kref_get_unless_zero in this function.
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Reviewed-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nvme/host/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2299,7 +2299,8 @@ static struct nvme_ns *nvme_find_get_ns(
mutex_lock(&ctrl->namespaces_mutex);
list_for_each_entry(ns, &ctrl->namespaces, list) {
if (ns->ns_id == nsid) {
- kref_get(&ns->kref);
+ if (!kref_get_unless_zero(&ns->kref))
+ continue;
ret = ns;
break;
}
Patches currently in stable-queue which might be from hch(a)lst.de are
queue-4.14/xfs-fix-incorrect-extent-state-in-xfs_bmap_add_extent_unwritten_real.patch
queue-4.14/nvme-use-kref_get_unless_zero-in-nvme_find_get_ns.patch
queue-4.14/target-iscsi-detect-conn_cmd_list-corruption-early.patch
queue-4.14/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch
queue-4.14/scsi-core-fix-a-scsi_show_rq-null-pointer-dereference.patch
queue-4.14/scsi-libsas-fix-length-error-in-sas_smp_handler.patch
queue-4.14/blk-mq-sched-dispatch-from-scheduler-iff-progress-is-made-in-dispatch.patch
This is a note to let you know that I've just added the patch titled
nullb: fix error return code in null_init()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nullb-fix-error-return-code-in-null_init.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:29:00 CET 2017
From: Wei Yongjun <weiyongjun1(a)huawei.com>
Date: Tue, 17 Oct 2017 12:11:46 +0000
Subject: nullb: fix error return code in null_init()
From: Wei Yongjun <weiyongjun1(a)huawei.com>
[ Upstream commit 30c516d750396c5f3ec9cb04c9e025c25e91495e ]
Fix to return error code -ENOMEM from the null_alloc_dev() error
handling case instead of 0, as done elsewhere in this function.
Fixes: 2984c8684f96 ("nullb: factor disk parameters")
Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/null_blk.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/block/null_blk.c
+++ b/drivers/block/null_blk.c
@@ -1985,8 +1985,10 @@ static int __init null_init(void)
for (i = 0; i < nr_devices; i++) {
dev = null_alloc_dev();
- if (!dev)
+ if (!dev) {
+ ret = -ENOMEM;
goto err_dev;
+ }
ret = null_add_dev(dev);
if (ret) {
null_free_dev(dev);
Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are
queue-4.14/nullb-fix-error-return-code-in-null_init.patch
queue-4.14/mlxsw-spectrum-fix-error-return-code-in-mlxsw_sp_port_create.patch
This is a note to let you know that I've just added the patch titled
netfilter: ipvs: Fix inappropriate output of procfs
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-ipvs-fix-inappropriate-output-of-procfs.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: KUWAZAWA Takuya <albatross0(a)gmail.com>
Date: Sun, 15 Oct 2017 20:54:10 +0900
Subject: netfilter: ipvs: Fix inappropriate output of procfs
From: KUWAZAWA Takuya <albatross0(a)gmail.com>
[ Upstream commit c5504f724c86ee925e7ffb80aa342cfd57959b13 ]
Information about ipvs in different network namespace can be seen via procfs.
How to reproduce:
# ip netns add ns01
# ip netns add ns02
# ip netns exec ns01 ip a add dev lo 127.0.0.1/8
# ip netns exec ns02 ip a add dev lo 127.0.0.1/8
# ip netns exec ns01 ipvsadm -A -t 10.1.1.1:80
# ip netns exec ns02 ipvsadm -A -t 10.1.1.2:80
The ipvsadm displays information about its own network namespace only.
# ip netns exec ns01 ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.1.1.1:80 wlc
# ip netns exec ns02 ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.1.1.2:80 wlc
But I can see information about other network namespace via procfs.
# ip netns exec ns01 cat /proc/net/ip_vs
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 0A010101:0050 wlc
TCP 0A010102:0050 wlc
# ip netns exec ns02 cat /proc/net/ip_vs
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 0A010102:0050 wlc
Signed-off-by: KUWAZAWA Takuya <albatross0(a)gmail.com>
Acked-by: Julian Anastasov <ja(a)ssi.bg>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/ipvs/ip_vs_ctl.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -2034,12 +2034,16 @@ static int ip_vs_info_seq_show(struct se
seq_puts(seq,
" -> RemoteAddress:Port Forward Weight ActiveConn InActConn\n");
} else {
+ struct net *net = seq_file_net(seq);
+ struct netns_ipvs *ipvs = net_ipvs(net);
const struct ip_vs_service *svc = v;
const struct ip_vs_iter *iter = seq->private;
const struct ip_vs_dest *dest;
struct ip_vs_scheduler *sched = rcu_dereference(svc->scheduler);
char *sched_name = sched ? sched->name : "none";
+ if (svc->ipvs != ipvs)
+ return 0;
if (iter->table == ip_vs_svc_table) {
#ifdef CONFIG_IP_VS_IPV6
if (svc->af == AF_INET6)
Patches currently in stable-queue which might be from albatross0(a)gmail.com are
queue-4.14/netfilter-ipvs-fix-inappropriate-output-of-procfs.patch
This is a note to let you know that I've just added the patch titled
net: hns3: fix the TX/RX ring.queue_index in hns3_ring_get_cfg
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-hns3-fix-the-tx-rx-ring.queue_index-in-hns3_ring_get_cfg.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Lipeng <lipeng321(a)huawei.com>
Date: Mon, 23 Oct 2017 19:51:05 +0800
Subject: net: hns3: fix the TX/RX ring.queue_index in hns3_ring_get_cfg
From: Lipeng <lipeng321(a)huawei.com>
[ Upstream commit 66b447301ac710ee237dba8b653244018fbb6168 ]
The interface hns3_ring_get_cfg only update TX ring queue_index,
but do not update RX ring queue_index. This patch fixes it.
Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC)
Signed-off-by: Lipeng <lipeng321(a)huawei.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -2488,16 +2488,16 @@ static int hns3_ring_get_cfg(struct hnae
if (ring_type == HNAE3_RING_TYPE_TX) {
ring_data[q->tqp_index].ring = ring;
+ ring_data[q->tqp_index].queue_index = q->tqp_index;
ring->io_base = (u8 __iomem *)q->io_base + HNS3_TX_REG_OFFSET;
} else {
ring_data[q->tqp_index + queue_num].ring = ring;
+ ring_data[q->tqp_index + queue_num].queue_index = q->tqp_index;
ring->io_base = q->io_base;
}
hnae_set_bit(ring->flag, HNAE3_RING_TYPE_B, ring_type);
- ring_data[q->tqp_index].queue_index = q->tqp_index;
-
ring->tqp = q;
ring->desc = NULL;
ring->desc_cb = NULL;
Patches currently in stable-queue which might be from lipeng321(a)huawei.com are
queue-4.14/net-hns3-fix-the-tx-rx-ring.queue_index-in-hns3_ring_get_cfg.patch
queue-4.14/net-hns3-fix-the-bug-when-map-buffer-fail.patch
queue-4.14/net-hns3-fix-a-bug-when-alloc-new-buffer.patch
queue-4.14/net-hns3-fix-the-bug-of-hns3_set_txbd_baseinfo.patch
queue-4.14/net-hns3-fix-a-bug-in-hclge_uninit_client_instance.patch
queue-4.14/net-hns3-fix-a-misuse-to-devm_free_irq.patch
queue-4.14/net-hns3-fix-for-getting-advertised_caps-in-hns3_get_link_ksettings.patch
queue-4.14/net-hns3-add-nic_client-check-when-initialize-roce-base-information.patch
This is a note to let you know that I've just added the patch titled
net: hns3: fix the bug when map buffer fail
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-hns3-fix-the-bug-when-map-buffer-fail.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Lipeng <lipeng321(a)huawei.com>
Date: Mon, 23 Oct 2017 19:51:02 +0800
Subject: net: hns3: fix the bug when map buffer fail
From: Lipeng <lipeng321(a)huawei.com>
[ Upstream commit 564883bb4dc1a4f3cba6344e77743175694b0761 ]
If one buffer had been recieved to stack, driver will alloc a new buffer,
map the buffer to device and replace the old buffer. When map fail, should
only free the new alloced buffer, but not free all buffers in the ring.
Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC)
Signed-off-by: Lipeng <lipeng321(a)huawei.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -1546,7 +1546,7 @@ static int hns3_reserve_buffer_map(struc
return 0;
out_with_buf:
- hns3_free_buffers(ring);
+ hns3_free_buffer(ring, cb);
out:
return ret;
}
Patches currently in stable-queue which might be from lipeng321(a)huawei.com are
queue-4.14/net-hns3-fix-the-tx-rx-ring.queue_index-in-hns3_ring_get_cfg.patch
queue-4.14/net-hns3-fix-the-bug-when-map-buffer-fail.patch
queue-4.14/net-hns3-fix-a-bug-when-alloc-new-buffer.patch
queue-4.14/net-hns3-fix-the-bug-of-hns3_set_txbd_baseinfo.patch
queue-4.14/net-hns3-fix-a-bug-in-hclge_uninit_client_instance.patch
queue-4.14/net-hns3-fix-a-misuse-to-devm_free_irq.patch
queue-4.14/net-hns3-fix-for-getting-advertised_caps-in-hns3_get_link_ksettings.patch
queue-4.14/net-hns3-add-nic_client-check-when-initialize-roce-base-information.patch
This is a note to let you know that I've just added the patch titled
net: hns3: fix the bug of hns3_set_txbd_baseinfo
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-hns3-fix-the-bug-of-hns3_set_txbd_baseinfo.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Lipeng <lipeng321(a)huawei.com>
Date: Tue, 24 Oct 2017 21:02:09 +0800
Subject: net: hns3: fix the bug of hns3_set_txbd_baseinfo
From: Lipeng <lipeng321(a)huawei.com>
[ Upstream commit 7036d26f328f12a323069eb16d965055b4cb3795 ]
The SC bits of TX BD mean switch control. For this area, value 0
indicates no switch control, the packet is routed according to the
forwarding table. Value 1 indicates that the packet is transmitted
to the network bypassing the forwarding table.
As HNS3 driver need support VF later, VF conmunicate with its own
PF need forwarding table. This patch sets SC bits of TX BD 0 and use
forwarding table.
Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC)
Signed-off-by: Lipeng <lipeng321(a)huawei.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -721,7 +721,7 @@ static void hns3_set_txbd_baseinfo(u16 *
HNS3_TXD_BDTYPE_M, 0);
hnae_set_bit(*bdtp_fe_sc_vld_ra_ri, HNS3_TXD_FE_B, !!frag_end);
hnae_set_bit(*bdtp_fe_sc_vld_ra_ri, HNS3_TXD_VLD_B, 1);
- hnae_set_field(*bdtp_fe_sc_vld_ra_ri, HNS3_TXD_SC_M, HNS3_TXD_SC_S, 1);
+ hnae_set_field(*bdtp_fe_sc_vld_ra_ri, HNS3_TXD_SC_M, HNS3_TXD_SC_S, 0);
}
static int hns3_fill_desc(struct hns3_enet_ring *ring, void *priv,
Patches currently in stable-queue which might be from lipeng321(a)huawei.com are
queue-4.14/net-hns3-fix-the-tx-rx-ring.queue_index-in-hns3_ring_get_cfg.patch
queue-4.14/net-hns3-fix-the-bug-when-map-buffer-fail.patch
queue-4.14/net-hns3-fix-a-bug-when-alloc-new-buffer.patch
queue-4.14/net-hns3-fix-the-bug-of-hns3_set_txbd_baseinfo.patch
queue-4.14/net-hns3-fix-a-bug-in-hclge_uninit_client_instance.patch
queue-4.14/net-hns3-fix-a-misuse-to-devm_free_irq.patch
queue-4.14/net-hns3-fix-for-getting-advertised_caps-in-hns3_get_link_ksettings.patch
queue-4.14/net-hns3-add-nic_client-check-when-initialize-roce-base-information.patch
This is a note to let you know that I've just added the patch titled
net: hns3: fix for getting advertised_caps in hns3_get_link_ksettings
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-hns3-fix-for-getting-advertised_caps-in-hns3_get_link_ksettings.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Fuyun Liang <liangfuyun1(a)huawei.com>
Date: Fri, 3 Nov 2017 12:18:26 +0800
Subject: net: hns3: fix for getting advertised_caps in hns3_get_link_ksettings
From: Fuyun Liang <liangfuyun1(a)huawei.com>
[ Upstream commit 2b39cabb2a283cea0c3d96d9370575371726164f ]
This patch fixes a bug for ethtool's get_link_ksettings().
The advertising for autoneg is always added to advertised_caps
whether autoneg is enable or disable. This patch fixes it.
Fixes: 496d03e (net: hns3: Add Ethtool support to HNS3 driver)
Signed-off-by: Fuyun Liang <liangfuyun1(a)huawei.com>
Signed-off-by: Lipeng <lipeng321(a)huawei.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
@@ -375,6 +375,9 @@ static int hns3_get_link_ksettings(struc
break;
}
+ if (!cmd->base.autoneg)
+ advertised_caps &= ~HNS3_LM_AUTONEG_BIT;
+
/* now, map driver link modes to ethtool link modes */
hns3_driv_to_eth_caps(supported_caps, cmd, false);
hns3_driv_to_eth_caps(advertised_caps, cmd, true);
Patches currently in stable-queue which might be from liangfuyun1(a)huawei.com are
queue-4.14/net-hns3-fix-for-getting-advertised_caps-in-hns3_get_link_ksettings.patch
This is a note to let you know that I've just added the patch titled
net: hns3: Fix a misuse to devm_free_irq
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-hns3-fix-a-misuse-to-devm_free_irq.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: qumingguang <qumingguang(a)huawei.com>
Date: Thu, 2 Nov 2017 20:45:22 +0800
Subject: net: hns3: Fix a misuse to devm_free_irq
From: qumingguang <qumingguang(a)huawei.com>
[ Upstream commit ae064e6123f89f90af7e4ea190cc0c612643ca93 ]
we should use free_irq to free the nic irq during the unloading time.
because we use request_irq to apply it when nic up. It will crash if
up net device after reset the port. This patch fixes the issue.
Signed-off-by: qumingguang <qumingguang(a)huawei.com>
Signed-off-by: Lipeng <lipeng321(a)huawei.com>
Signed-off-by: Yunsheng Lin <linyunsheng(a)huawei.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -2460,9 +2460,8 @@ static int hns3_nic_uninit_vector_data(s
(void)irq_set_affinity_hint(
priv->tqp_vector[i].vector_irq,
NULL);
- devm_free_irq(&pdev->dev,
- priv->tqp_vector[i].vector_irq,
- &priv->tqp_vector[i]);
+ free_irq(priv->tqp_vector[i].vector_irq,
+ &priv->tqp_vector[i]);
}
priv->ring_data[i].ring->irq_init_flag = HNS3_VECTOR_NOT_INITED;
Patches currently in stable-queue which might be from qumingguang(a)huawei.com are
queue-4.14/net-hns3-fix-a-misuse-to-devm_free_irq.patch
This is a note to let you know that I've just added the patch titled
net: hns3: fix a bug when alloc new buffer
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-hns3-fix-a-bug-when-alloc-new-buffer.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Lipeng <lipeng321(a)huawei.com>
Date: Mon, 23 Oct 2017 19:51:01 +0800
Subject: net: hns3: fix a bug when alloc new buffer
From: Lipeng <lipeng321(a)huawei.com>
[ Upstream commit b9077428ec5569aacb2952d8a2ffb51c8988d3c2 ]
When alloce new buffer to HW, should unmap the old buffer first.
This old code map the old buffer but not unmap the old buffer,
this patch fixes it.
Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC)
Signed-off-by: Lipeng <lipeng321(a)huawei.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -1586,7 +1586,7 @@ out_buffer_fail:
static void hns3_replace_buffer(struct hns3_enet_ring *ring, int i,
struct hns3_desc_cb *res_cb)
{
- hns3_map_buffer(ring, &ring->desc_cb[i]);
+ hns3_unmap_buffer(ring, &ring->desc_cb[i]);
ring->desc_cb[i] = *res_cb;
ring->desc[i].addr = cpu_to_le64(ring->desc_cb[i].dma);
}
Patches currently in stable-queue which might be from lipeng321(a)huawei.com are
queue-4.14/net-hns3-fix-the-tx-rx-ring.queue_index-in-hns3_ring_get_cfg.patch
queue-4.14/net-hns3-fix-the-bug-when-map-buffer-fail.patch
queue-4.14/net-hns3-fix-a-bug-when-alloc-new-buffer.patch
queue-4.14/net-hns3-fix-the-bug-of-hns3_set_txbd_baseinfo.patch
queue-4.14/net-hns3-fix-a-bug-in-hclge_uninit_client_instance.patch
queue-4.14/net-hns3-fix-a-misuse-to-devm_free_irq.patch
queue-4.14/net-hns3-fix-for-getting-advertised_caps-in-hns3_get_link_ksettings.patch
queue-4.14/net-hns3-add-nic_client-check-when-initialize-roce-base-information.patch