This is a note to let you know that I've just added the patch titled
r8152: fix the list rx_done may be used without initialization
to the 4.4-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:
r8152-fix-the-list-rx_done-may-be-used-without-initialization.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: hayeswang <hayeswang(a)realtek.com>
Date: Tue, 14 Mar 2017 14:15:20 +0800
Subject: r8152: fix the list rx_done may be used without initialization
From: hayeswang <hayeswang(a)realtek.com>
[ Upstream commit 98d068ab52b4b11d403995ed14154660797e7136 ]
The list rx_done would be initialized when the linking on occurs.
Therefore, if a napi is scheduled without any linking on before,
the following kernel panic would happen.
BUG: unable to handle kernel NULL pointer dereference at 000000000000008
IP: [<ffffffffc085efde>] r8152_poll+0xe1e/0x1210 [r8152]
PGD 0
Oops: 0002 [#1] SMP
Signed-off-by: Hayes Wang <hayeswang(a)realtek.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/usb/r8152.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1277,6 +1277,7 @@ static int alloc_all_mem(struct r8152 *t
spin_lock_init(&tp->rx_lock);
spin_lock_init(&tp->tx_lock);
INIT_LIST_HEAD(&tp->tx_free);
+ INIT_LIST_HEAD(&tp->rx_done);
skb_queue_head_init(&tp->tx_queue);
skb_queue_head_init(&tp->rx_queue);
Patches currently in stable-queue which might be from hayeswang(a)realtek.com are
queue-4.4/r8152-fix-the-list-rx_done-may-be-used-without-initialization.patch
queue-4.4/r8152-prevent-the-driver-from-transmitting-packets-with-carrier-off.patch
This is a note to let you know that I've just added the patch titled
percpu: don't forget to free the temporary struct pcpu_alloc_info
to the 4.4-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:
percpu-don-t-forget-to-free-the-temporary-struct-pcpu_alloc_info.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Nicolas Pitre <nicolas.pitre(a)linaro.org>
Date: Tue, 3 Oct 2017 18:29:49 -0400
Subject: percpu: don't forget to free the temporary struct pcpu_alloc_info
From: Nicolas Pitre <nicolas.pitre(a)linaro.org>
[ Upstream commit 438a50618095061920d3a30d4c5ca1ef2e0ff860 ]
Unlike the SMP case, the !SMP case does not free the memory for struct
pcpu_alloc_info allocated in setup_per_cpu_areas(). And to give it a
chance of being reused by the page allocator later, align it to a page
boundary just like its size.
Signed-off-by: Nicolas Pitre <nico(a)linaro.org>
Acked-by: Dennis Zhou <dennisszhou(a)gmail.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/percpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1402,7 +1402,7 @@ struct pcpu_alloc_info * __init pcpu_all
__alignof__(ai->groups[0].cpu_map[0]));
ai_size = base_size + nr_units * sizeof(ai->groups[0].cpu_map[0]);
- ptr = memblock_virt_alloc_nopanic(PFN_ALIGN(ai_size), 0);
+ ptr = memblock_virt_alloc_nopanic(PFN_ALIGN(ai_size), PAGE_SIZE);
if (!ptr)
return NULL;
ai = ptr;
@@ -2265,6 +2265,7 @@ void __init setup_per_cpu_areas(void)
if (pcpu_setup_first_chunk(ai, fc) < 0)
panic("Failed to initialize percpu areas.");
+ pcpu_free_alloc_info(ai);
}
#endif /* CONFIG_SMP */
Patches currently in stable-queue which might be from nicolas.pitre(a)linaro.org are
queue-4.4/percpu-don-t-forget-to-free-the-temporary-struct-pcpu_alloc_info.patch
This is a note to let you know that I've just added the patch titled
PCI: Avoid bus reset if bridge itself is broken
to the 4.4-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-avoid-bus-reset-if-bridge-itself-is-broken.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: David Daney <david.daney(a)cavium.com>
Date: Fri, 8 Sep 2017 10:10:31 +0200
Subject: PCI: Avoid bus reset if bridge itself is broken
From: David Daney <david.daney(a)cavium.com>
[ Upstream commit 357027786f3523d26f42391aa4c075b8495e5d28 ]
When checking to see if a PCI bus can safely be reset, we previously
checked to see if any of the children had their PCI_DEV_FLAGS_NO_BUS_RESET
flag set. Children marked with that flag are known not to behave well
after a bus reset.
Some PCIe root port bridges also do not behave well after a bus reset,
sometimes causing the devices behind the bridge to become unusable.
Add a check for PCI_DEV_FLAGS_NO_BUS_RESET being set in the bridge device
to allow these bridges to be flagged, and prevent their secondary buses
from being reset.
Signed-off-by: David Daney <david.daney(a)cavium.com>
[jglauber(a)cavium.com: fixed typo]
Signed-off-by: Jan Glauber <jglauber(a)cavium.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Reviewed-by: Alex Williamson <alex.williamson(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/pci.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3850,6 +3850,10 @@ static bool pci_bus_resetable(struct pci
{
struct pci_dev *dev;
+
+ if (bus->self && (bus->self->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET))
+ return false;
+
list_for_each_entry(dev, &bus->devices, bus_list) {
if (dev->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET ||
(dev->subordinate && !pci_bus_resetable(dev->subordinate)))
Patches currently in stable-queue which might be from david.daney(a)cavium.com are
queue-4.4/pci-avoid-bus-reset-if-bridge-itself-is-broken.patch
This is a note to let you know that I've just added the patch titled
PCI: Create SR-IOV virtfn/physfn links before attaching driver
to the 4.4-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-create-sr-iov-virtfn-physfn-links-before-attaching-driver.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Stuart Hayes <stuart.w.hayes(a)gmail.com>
Date: Wed, 4 Oct 2017 10:57:52 -0500
Subject: PCI: Create SR-IOV virtfn/physfn links before attaching driver
From: Stuart Hayes <stuart.w.hayes(a)gmail.com>
[ Upstream commit 27d6162944b9b34c32cd5841acd21786637ee743 ]
When creating virtual functions, create the "virtfn%u" and "physfn" links
in sysfs *before* attaching the driver instead of after. When we attach
the driver to the new virtual network interface first, there is a race when
the driver attaches to the new sends out an "add" udev event, and the
network interface naming software (biosdevname or systemd, for example)
tries to look at these links.
Signed-off-by: Stuart Hayes <stuart.w.hayes(a)gmail.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/iov.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -161,7 +161,6 @@ static int virtfn_add(struct pci_dev *de
pci_device_add(virtfn, virtfn->bus);
mutex_unlock(&iov->dev->sriov->lock);
- pci_bus_add_device(virtfn);
sprintf(buf, "virtfn%u", id);
rc = sysfs_create_link(&dev->dev.kobj, &virtfn->dev.kobj, buf);
if (rc)
@@ -172,6 +171,8 @@ static int virtfn_add(struct pci_dev *de
kobject_uevent(&virtfn->dev.kobj, KOBJ_CHANGE);
+ pci_bus_add_device(virtfn);
+
return 0;
failed2:
Patches currently in stable-queue which might be from stuart.w.hayes(a)gmail.com are
queue-4.4/pci-create-sr-iov-virtfn-physfn-links-before-attaching-driver.patch
This is a note to let you know that I've just added the patch titled
PCI/AER: Report non-fatal errors only to the affected endpoint
to the 4.4-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-aer-report-non-fatal-errors-only-to-the-affected-endpoint.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Gabriele Paoloni <gabriele.paoloni(a)huawei.com>
Date: Thu, 28 Sep 2017 15:33:05 +0100
Subject: PCI/AER: Report non-fatal errors only to the affected endpoint
From: Gabriele Paoloni <gabriele.paoloni(a)huawei.com>
[ Upstream commit 86acc790717fb60fb51ea3095084e331d8711c74 ]
Previously, if an non-fatal error was reported by an endpoint, we
called report_error_detected() for the endpoint, every sibling on the
bus, and their descendents. If any of them did not implement the
.error_detected() method, do_recovery() failed, leaving all these
devices unrecovered.
For example, the system described in the bugzilla below has two devices:
0000:74:02.0 [19e5:a230] SAS controller, driver has .error_detected()
0000:74:03.0 [19e5:a235] SATA controller, driver lacks .error_detected()
When a device such as 74:02.0 reported a non-fatal error, do_recovery()
failed because 74:03.0 lacked an .error_detected() method. But per PCIe
r3.1, sec 6.2.2.2.2, such an error does not compromise the Link and
does not affect 74:03.0:
Non-fatal errors are uncorrectable errors which cause a particular
transaction to be unreliable but the Link is otherwise fully functional.
Isolating Non-fatal from Fatal errors provides Requester/Receiver logic
in a device or system management software the opportunity to recover from
the error without resetting the components on the Link and disturbing
other transactions in progress. Devices not associated with the
transaction in error are not impacted by the error.
Report non-fatal errors only to the endpoint that reported them. We really
want to check for AER_NONFATAL here, but the current code structure doesn't
allow that. Looking for pci_channel_io_normal is the best we can do now.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=197055
Fixes: 6c2b374d7485 ("PCI-Express AER implemetation: AER core and aerdriver")
Signed-off-by: Gabriele Paoloni <gabriele.paoloni(a)huawei.com>
Signed-off-by: Dongdong Liu <liudongdong3(a)huawei.com>
[bhelgaas: changelog]
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/pcie/aer/aerdrv_core.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -388,7 +388,14 @@ static pci_ers_result_t broadcast_error_
* If the error is reported by an end point, we think this
* error is related to the upstream link of the end point.
*/
- pci_walk_bus(dev->bus, cb, &result_data);
+ if (state == pci_channel_io_normal)
+ /*
+ * the error is non fatal so the bus is ok, just invoke
+ * the callback for the function that logged the error.
+ */
+ cb(dev, &result_data);
+ else
+ pci_walk_bus(dev->bus, cb, &result_data);
}
return result_data.result;
Patches currently in stable-queue which might be from gabriele.paoloni(a)huawei.com are
queue-4.4/pci-aer-report-non-fatal-errors-only-to-the-affected-endpoint.patch
This is a note to let you know that I've just added the patch titled
netfilter: nfnl_cthelper: Fix memory leak
to the 4.4-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-nfnl_cthelper-fix-memory-leak.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Jeffy Chen <jeffy.chen(a)rock-chips.com>
Date: Tue, 21 Mar 2017 15:07:10 +0800
Subject: netfilter: nfnl_cthelper: Fix memory leak
From: Jeffy Chen <jeffy.chen(a)rock-chips.com>
[ Upstream commit f83bf8da1135ca635aac8f062cad3f001fcf3a26 ]
We have memory leaks of nf_conntrack_helper & expect_policy.
Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com>
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/nfnetlink_cthelper.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/net/netfilter/nfnetlink_cthelper.c
+++ b/net/netfilter/nfnetlink_cthelper.c
@@ -216,7 +216,7 @@ nfnl_cthelper_create(const struct nlattr
ret = nfnl_cthelper_parse_expect_policy(helper, tb[NFCTH_POLICY]);
if (ret < 0)
- goto err;
+ goto err1;
strncpy(helper->name, nla_data(tb[NFCTH_NAME]), NF_CT_HELPER_NAME_LEN);
helper->data_len = ntohl(nla_get_be32(tb[NFCTH_PRIV_DATA_LEN]));
@@ -247,10 +247,12 @@ nfnl_cthelper_create(const struct nlattr
ret = nf_conntrack_helper_register(helper);
if (ret < 0)
- goto err;
+ goto err2;
return 0;
-err:
+err2:
+ kfree(helper->expect_policy);
+err1:
kfree(helper);
return ret;
}
@@ -696,6 +698,8 @@ nfnl_cthelper_del(struct sock *nfnl, str
found = true;
nf_conntrack_helper_unregister(cur);
+ kfree(cur->expect_policy);
+ kfree(cur);
}
}
/* Make sure we return success if we flush and there is no helpers */
@@ -759,6 +763,8 @@ static void __exit nfnl_cthelper_exit(vo
continue;
nf_conntrack_helper_unregister(cur);
+ kfree(cur->expect_policy);
+ kfree(cur);
}
}
}
Patches currently in stable-queue which might be from jeffy.chen(a)rock-chips.com are
queue-4.4/netfilter-nfnl_cthelper-fix-memory-leak.patch
This is a note to let you know that I've just added the patch titled
netfilter: nfnetlink_queue: fix secctx memory leak
to the 4.4-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-nfnetlink_queue-fix-secctx-memory-leak.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Liping Zhang <zlpnobody(a)gmail.com>
Date: Tue, 28 Mar 2017 22:59:25 +0800
Subject: netfilter: nfnetlink_queue: fix secctx memory leak
From: Liping Zhang <zlpnobody(a)gmail.com>
[ Upstream commit 77c1c03c5b8ef28e55bb0aff29b1e006037ca645 ]
We must call security_release_secctx to free the memory returned by
security_secid_to_secctx, otherwise memory may be leaked forever.
Fixes: ef493bd930ae ("netfilter: nfnetlink_queue: add security context information")
Signed-off-by: Liping Zhang <zlpnobody(a)gmail.com>
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/nfnetlink_queue.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/net/netfilter/nfnetlink_queue.c
+++ b/net/netfilter/nfnetlink_queue.c
@@ -390,7 +390,7 @@ nfqnl_build_packet_message(struct net *n
GFP_ATOMIC);
if (!skb) {
skb_tx_error(entskb);
- return NULL;
+ goto nlmsg_failure;
}
nlh = nlmsg_put(skb, 0, 0,
@@ -399,7 +399,7 @@ nfqnl_build_packet_message(struct net *n
if (!nlh) {
skb_tx_error(entskb);
kfree_skb(skb);
- return NULL;
+ goto nlmsg_failure;
}
nfmsg = nlmsg_data(nlh);
nfmsg->nfgen_family = entry->state.pf;
@@ -542,12 +542,17 @@ nfqnl_build_packet_message(struct net *n
}
nlh->nlmsg_len = skb->len;
+ if (seclen)
+ security_release_secctx(secdata, seclen);
return skb;
nla_put_failure:
skb_tx_error(entskb);
kfree_skb(skb);
net_err_ratelimited("nf_queue: error creating packet message\n");
+nlmsg_failure:
+ if (seclen)
+ security_release_secctx(secdata, seclen);
return NULL;
}
Patches currently in stable-queue which might be from zlpnobody(a)gmail.com are
queue-4.4/netfilter-nfnetlink_queue-fix-secctx-memory-leak.patch
queue-4.4/netfilter-nfnl_cthelper-fix-runtime-expectation-policy-updates.patch
queue-4.4/netfilter-nfnl_cthelper-fix-a-race-when-walk-the-nf_ct_helper_hash-table.patch
This is a note to let you know that I've just added the patch titled
netfilter: nf_nat_snmp: Fix panic when snmp_trap_helper fails to register
to the 4.4-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-nf_nat_snmp-fix-panic-when-snmp_trap_helper-fails-to-register.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Gao Feng <fgao(a)ikuai8.com>
Date: Sat, 25 Mar 2017 18:24:36 +0800
Subject: netfilter: nf_nat_snmp: Fix panic when snmp_trap_helper fails to register
From: Gao Feng <fgao(a)ikuai8.com>
[ Upstream commit 75c689dca98851d65ef5a27e5ce26b625b68751c ]
In the commit 93557f53e1fb ("netfilter: nf_conntrack: nf_conntrack snmp
helper"), the snmp_helper is replaced by nf_nat_snmp_hook. So the
snmp_helper is never registered. But it still tries to unregister the
snmp_helper, it could cause the panic.
Now remove the useless snmp_helper and the unregister call in the
error handler.
Fixes: 93557f53e1fb ("netfilter: nf_conntrack: nf_conntrack snmp helper")
Signed-off-by: Gao Feng <fgao(a)ikuai8.com>
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/ipv4/netfilter/nf_nat_snmp_basic.c | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
--- a/net/ipv4/netfilter/nf_nat_snmp_basic.c
+++ b/net/ipv4/netfilter/nf_nat_snmp_basic.c
@@ -1260,16 +1260,6 @@ static const struct nf_conntrack_expect_
.timeout = 180,
};
-static struct nf_conntrack_helper snmp_helper __read_mostly = {
- .me = THIS_MODULE,
- .help = help,
- .expect_policy = &snmp_exp_policy,
- .name = "snmp",
- .tuple.src.l3num = AF_INET,
- .tuple.src.u.udp.port = cpu_to_be16(SNMP_PORT),
- .tuple.dst.protonum = IPPROTO_UDP,
-};
-
static struct nf_conntrack_helper snmp_trap_helper __read_mostly = {
.me = THIS_MODULE,
.help = help,
@@ -1288,17 +1278,10 @@ static struct nf_conntrack_helper snmp_t
static int __init nf_nat_snmp_basic_init(void)
{
- int ret = 0;
-
BUG_ON(nf_nat_snmp_hook != NULL);
RCU_INIT_POINTER(nf_nat_snmp_hook, help);
- ret = nf_conntrack_helper_register(&snmp_trap_helper);
- if (ret < 0) {
- nf_conntrack_helper_unregister(&snmp_helper);
- return ret;
- }
- return ret;
+ return nf_conntrack_helper_register(&snmp_trap_helper);
}
static void __exit nf_nat_snmp_basic_fini(void)
Patches currently in stable-queue which might be from fgao(a)ikuai8.com are
queue-4.4/netfilter-nf_nat_snmp-fix-panic-when-snmp_trap_helper-fails-to-register.patch
This is a note to let you know that I've just added the patch titled
net: qmi_wwan: Add USB IDs for MDM6600 modem on Motorola Droid 4
to the 4.4-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-qmi_wwan-add-usb-ids-for-mdm6600-modem-on-motorola-droid-4.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Tony Lindgren <tony(a)atomide.com>
Date: Sun, 19 Mar 2017 09:19:57 -0700
Subject: net: qmi_wwan: Add USB IDs for MDM6600 modem on Motorola Droid 4
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit 4071898bf0f4d79ff353db327af2a15123272548 ]
This gets qmicli working with the MDM6600 modem.
Cc: Bjørn Mork <bjorn(a)mork.no>
Reviewed-by: Sebastian Reichel <sre(a)kernel.org>
Tested-by: Sebastian Reichel <sre(a)kernel.org>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Acked-by: Bjørn Mork <bjorn(a)mork.no>
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/usb/qmi_wwan.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -410,6 +410,10 @@ static const struct usb_device_id produc
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 0x01, 0x69),
.driver_info = (unsigned long)&qmi_wwan_info,
},
+ { /* Motorola Mapphone devices with MDM6600 */
+ USB_VENDOR_AND_INTERFACE_INFO(0x22b8, USB_CLASS_VENDOR_SPEC, 0xfb, 0xff),
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
/* 2. Combined interface devices matching on class+protocol */
{ /* Huawei E367 and possibly others in "Windows mode" */
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.4/net-qmi_wwan-add-usb-ids-for-mdm6600-modem-on-motorola-droid-4.patch
queue-4.4/arm-dts-am335x-evmsk-adjust-mmc2-param-to-allow-suspend.patch
queue-4.4/arm-dts-ti-fix-pci-bus-dtc-warnings.patch
This is a note to let you know that I've just added the patch titled
net: phy: at803x: Change error to EINVAL for invalid MAC
to the 4.4-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-phy-at803x-change-error-to-einval-for-invalid-mac.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Dan Murphy <dmurphy(a)ti.com>
Date: Tue, 10 Oct 2017 12:42:56 -0500
Subject: net: phy: at803x: Change error to EINVAL for invalid MAC
From: Dan Murphy <dmurphy(a)ti.com>
[ Upstream commit fc7556877d1748ac00958822a0a3bba1d4bd9e0d ]
Change the return error code to EINVAL if the MAC
address is not valid in the set_wol function.
Signed-off-by: Dan Murphy <dmurphy(a)ti.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/phy/at803x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -105,7 +105,7 @@ static int at803x_set_wol(struct phy_dev
mac = (const u8 *) ndev->dev_addr;
if (!is_valid_ether_addr(mac))
- return -EFAULT;
+ return -EINVAL;
for (i = 0; i < 3; i++) {
phy_write(phydev, AT803X_MMD_ACCESS_CONTROL,
Patches currently in stable-queue which might be from dmurphy(a)ti.com are
queue-4.4/net-phy-at803x-change-error-to-einval-for-invalid-mac.patch
This is a note to let you know that I've just added the patch titled
net: Do not allow negative values for busy_read and busy_poll sysctl interfaces
to the 4.4-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-do-not-allow-negative-values-for-busy_read-and-busy_poll-sysctl-interfaces.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
Date: Fri, 24 Mar 2017 09:38:03 -0700
Subject: net: Do not allow negative values for busy_read and busy_poll sysctl interfaces
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
[ Upstream commit 95f255211396958c718aef8c45e3923b5211ea7b ]
This change basically codifies what I think was already the limitations on
the busy_poll and busy_read sysctl interfaces. We weren't checking the
lower bounds and as such could input negative values. The behavior when
that was used was dependent on the architecture. In order to prevent any
issues with that I am just disabling support for values less than 0 since
this way we don't have to worry about any odd behaviors.
By limiting the sysctl values this way it also makes it consistent with how
we handle the SO_BUSY_POLL socket option since the value appears to be
reported as a signed integer value and negative values are rejected.
Signed-off-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
Acked-by: Eric Dumazet <edumazet(a)google.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>
---
net/core/sysctl_net_core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -360,14 +360,16 @@ static struct ctl_table net_core_table[]
.data = &sysctl_net_busy_poll,
.maxlen = sizeof(unsigned int),
.mode = 0644,
- .proc_handler = proc_dointvec
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
},
{
.procname = "busy_read",
.data = &sysctl_net_busy_read,
.maxlen = sizeof(unsigned int),
.mode = 0644,
- .proc_handler = proc_dointvec
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
},
#endif
#ifdef CONFIG_NET_SCHED
Patches currently in stable-queue which might be from alexander.h.duyck(a)intel.com are
queue-4.4/i40e-do-not-enable-napi-on-q_vectors-that-have-no-rings.patch
queue-4.4/net-do-not-allow-negative-values-for-busy_read-and-busy_poll-sysctl-interfaces.patch
This is a note to let you know that I've just added the patch titled
mm/rmap: batched invalidations should use existing api
to the 4.4-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:
mm-rmap-batched-invalidations-should-use-existing-api.patch
and it can be found in the queue-4.4 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 858eaaa711700ce4595e039441e239e56d7b9514 Mon Sep 17 00:00:00 2001
From: Nadav Amit <namit(a)vmware.com>
Date: Fri, 1 Apr 2016 14:31:26 -0700
Subject: mm/rmap: batched invalidations should use existing api
From: Nadav Amit <namit(a)vmware.com>
commit 858eaaa711700ce4595e039441e239e56d7b9514 upstream.
The recently introduced batched invalidations mechanism uses its own
mechanism for shootdown. However, it does wrong accounting of
interrupts (e.g., inc_irq_stat is called for local invalidations),
trace-points (e.g., TLB_REMOTE_SHOOTDOWN for local invalidations) and
may break some platforms as it bypasses the invalidation mechanisms of
Xen and SGI UV.
This patch reuses the existing TLB flushing mechnaisms instead. We use
NULL as mm to indicate a global invalidation is required.
Fixes 72b252aed506b8 ("mm: send one IPI per CPU to TLB flush all entries after unmapping pages")
Signed-off-by: Nadav Amit <namit(a)vmware.com>
Cc: Mel Gorman <mgorman(a)suse.de>
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Dave Hansen <dave.hansen(a)intel.com>
Cc: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/tlbflush.h | 6 ------
arch/x86/mm/tlb.c | 2 +-
mm/rmap.c | 28 +++++++---------------------
3 files changed, 8 insertions(+), 28 deletions(-)
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -325,12 +325,6 @@ static inline void reset_lazy_tlbstate(v
#endif /* SMP */
-/* Not inlined due to inc_irq_stat not being defined yet */
-#define flush_tlb_local() { \
- inc_irq_stat(irq_tlb_count); \
- local_flush_tlb(); \
-}
-
#ifndef CONFIG_PARAVIRT
#define flush_tlb_others(mask, mm, start, end) \
native_flush_tlb_others(mask, mm, start, end)
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -104,7 +104,7 @@ static void flush_tlb_func(void *info)
inc_irq_stat(irq_tlb_count);
- if (f->flush_mm != this_cpu_read(cpu_tlbstate.active_mm))
+ if (f->flush_mm && f->flush_mm != this_cpu_read(cpu_tlbstate.active_mm))
return;
count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -587,19 +587,6 @@ vma_address(struct page *page, struct vm
}
#ifdef CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
-static void percpu_flush_tlb_batch_pages(void *data)
-{
- /*
- * All TLB entries are flushed on the assumption that it is
- * cheaper to flush all TLBs and let them be refilled than
- * flushing individual PFNs. Note that we do not track mm's
- * to flush as that might simply be multiple full TLB flushes
- * for no gain.
- */
- count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
- flush_tlb_local();
-}
-
/*
* Flush TLB entries for recently unmapped pages from remote CPUs. It is
* important if a PTE was dirty when it was unmapped that it's flushed
@@ -616,15 +603,14 @@ void try_to_unmap_flush(void)
cpu = get_cpu();
- trace_tlb_flush(TLB_REMOTE_SHOOTDOWN, -1UL);
-
- if (cpumask_test_cpu(cpu, &tlb_ubc->cpumask))
- percpu_flush_tlb_batch_pages(&tlb_ubc->cpumask);
-
- if (cpumask_any_but(&tlb_ubc->cpumask, cpu) < nr_cpu_ids) {
- smp_call_function_many(&tlb_ubc->cpumask,
- percpu_flush_tlb_batch_pages, (void *)tlb_ubc, true);
+ if (cpumask_test_cpu(cpu, &tlb_ubc->cpumask)) {
+ count_vm_tlb_event(NR_TLB_LOCAL_FLUSH_ALL);
+ local_flush_tlb();
+ trace_tlb_flush(TLB_LOCAL_SHOOTDOWN, TLB_FLUSH_ALL);
}
+
+ if (cpumask_any_but(&tlb_ubc->cpumask, cpu) < nr_cpu_ids)
+ flush_tlb_others(&tlb_ubc->cpumask, NULL, 0, TLB_FLUSH_ALL);
cpumask_clear(&tlb_ubc->cpumask);
tlb_ubc->flush_required = false;
tlb_ubc->writable = false;
Patches currently in stable-queue which might be from namit(a)vmware.com are
queue-4.4/mm-rmap-batched-invalidations-should-use-existing-api.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: correct async page present tracepoint
to the 4.4-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:
kvm-x86-correct-async-page-present-tracepoint.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
Date: Mon, 20 Mar 2017 21:18:55 -0700
Subject: KVM: x86: correct async page present tracepoint
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
[ Upstream commit 24dccf83a121b8a4ad5c2ad383a8184ef6c266ee ]
After async pf setup successfully, there is a broadcast wakeup w/ special
token 0xffffffff which tells vCPU that it should wake up all processes
waiting for APFs though there is no real process waiting at the moment.
The async page present tracepoint print prematurely and fails to catch the
special token setup. This patch fixes it by moving the async page present
tracepoint after the special token setup.
Before patch:
qemu-system-x86-8499 [006] ...1 5973.473292: kvm_async_pf_ready: token 0x0 gva 0x0
After patch:
qemu-system-x86-8499 [006] ...1 5973.473292: kvm_async_pf_ready: token 0xffffffff gva 0x0
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8230,11 +8230,11 @@ void kvm_arch_async_page_present(struct
{
struct x86_exception fault;
- trace_kvm_async_pf_ready(work->arch.token, work->gva);
if (work->wakeup_all)
work->arch.token = ~0; /* broadcast wakeup */
else
kvm_del_async_pf_gfn(vcpu, work->arch.gfn);
+ trace_kvm_async_pf_ready(work->arch.token, work->gva);
if ((vcpu->arch.apf.msr_val & KVM_ASYNC_PF_ENABLED) &&
!apf_put_user(vcpu, KVM_PV_REASON_PAGE_READY)) {
Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are
queue-4.4/kvm-x86-correct-async-page-present-tracepoint.patch
queue-4.4/kvm-vmx-fix-enable-vpid-conditions.patch
This is a note to let you know that I've just added the patch titled
mm/mmu_context, sched/core: Fix mmu_context.h assumption
to the 4.4-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:
mm-mmu_context-sched-core-fix-mmu_context.h-assumption.patch
and it can be found in the queue-4.4 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 8efd755ac2fe262d4c8d5c9bbe054bb67dae93da Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo(a)kernel.org>
Date: Thu, 28 Apr 2016 11:39:12 +0200
Subject: mm/mmu_context, sched/core: Fix mmu_context.h assumption
From: Ingo Molnar <mingo(a)kernel.org>
commit 8efd755ac2fe262d4c8d5c9bbe054bb67dae93da upstream.
Some architectures (such as Alpha) rely on include/linux/sched.h definitions
in their mmu_context.h files.
So include sched.h before mmu_context.h.
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: linux-kernel(a)vger.kernel.org
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/mmu_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/mmu_context.c
+++ b/mm/mmu_context.c
@@ -4,9 +4,9 @@
*/
#include <linux/mm.h>
+#include <linux/sched.h>
#include <linux/mmu_context.h>
#include <linux/export.h>
-#include <linux/sched.h>
#include <asm/mmu_context.h>
Patches currently in stable-queue which might be from mingo(a)kernel.org are
queue-4.4/x86-mm-sched-core-uninline-switch_mm.patch
queue-4.4/x86-mm-add-a-noinvpcid-boot-option-to-turn-off-invpcid.patch
queue-4.4/x86-irq-do-not-substract-irq_tlb_count-from-irq_call_count.patch
queue-4.4/x86-mm-if-invpcid-is-available-use-it-to-flush-global-mappings.patch
queue-4.4/x86-mm-add-invpcid-helpers.patch
queue-4.4/mm-rmap-batched-invalidations-should-use-existing-api.patch
queue-4.4/sched-core-add-switch_mm_irqs_off-and-use-it-in-the-scheduler.patch
queue-4.4/arm-hide-finish_arch_post_lock_switch-from-modules.patch
queue-4.4/x86-mm-sched-core-turn-off-irqs-in-switch_mm.patch
queue-4.4/mm-mmu_context-sched-core-fix-mmu_context.h-assumption.patch
queue-4.4/x86-mm-fix-invpcid-asm-constraint.patch
queue-4.4/x86-mm-build-arch-x86-mm-tlb.c-even-on-smp.patch
queue-4.4/sched-core-idle_task_exit-shouldn-t-use-switch_mm_irqs_off.patch
This is a note to let you know that I've just added the patch titled
KVM: VMX: Fix enable VPID conditions
to the 4.4-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:
kvm-vmx-fix-enable-vpid-conditions.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
Date: Thu, 23 Mar 2017 05:30:08 -0700
Subject: KVM: VMX: Fix enable VPID conditions
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
[ Upstream commit 08d839c4b134b8328ec42f2157a9ca4b93227c03 ]
This can be reproduced by running L2 on L1, and disable VPID on L0
if w/o commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2
crash as below:
KVM: entry failed, hardware error 0x7
EAX=00000000 EBX=00000000 ECX=00000000 EDX=000306c3
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT= 00000000 0000ffff
IDT= 00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
Reference SDM 30.3 INVVPID:
Protected Mode Exceptions
- #UD
- If not in VMX operation.
- If the logical processor does not support VPIDs (IA32_VMX_PROCBASED_CTLS2[37]=0).
- If the logical processor supports VPIDs (IA32_VMX_PROCBASED_CTLS2[37]=1) but does
not support the INVVPID instruction (IA32_VMX_EPT_VPID_CAP[32]=0).
So we should check both VPID enable bit in vmx exec control and INVVPID support bit
in vmx capability MSRs to enable VPID. This patch adds the guarantee to not enable
VPID if either INVVPID or single-context/all-context invalidation is not exposed in
vmx capability MSRs.
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Reviewed-by: Jim Mattson <jmattson(a)google.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1107,6 +1107,11 @@ static inline bool cpu_has_vmx_invvpid_g
return vmx_capability.vpid & VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT;
}
+static inline bool cpu_has_vmx_invvpid(void)
+{
+ return vmx_capability.vpid & VMX_VPID_INVVPID_BIT;
+}
+
static inline bool cpu_has_vmx_ept(void)
{
return vmcs_config.cpu_based_2nd_exec_ctrl &
@@ -6199,8 +6204,10 @@ static __init int hardware_setup(void)
if (boot_cpu_has(X86_FEATURE_NX))
kvm_enable_efer_bits(EFER_NX);
- if (!cpu_has_vmx_vpid())
+ if (!cpu_has_vmx_vpid() || !cpu_has_vmx_invvpid() ||
+ !(cpu_has_vmx_invvpid_single() || cpu_has_vmx_invvpid_global()))
enable_vpid = 0;
+
if (!cpu_has_vmx_shadow_vmcs())
enable_shadow_vmcs = 0;
if (enable_shadow_vmcs)
Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are
queue-4.4/kvm-x86-correct-async-page-present-tracepoint.patch
queue-4.4/kvm-vmx-fix-enable-vpid-conditions.patch
This is a note to let you know that I've just added the patch titled
ixgbe: fix use of uninitialized padding
to the 4.4-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:
ixgbe-fix-use-of-uninitialized-padding.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Emil Tantilov <emil.s.tantilov(a)intel.com>
Date: Mon, 11 Sep 2017 14:21:31 -0700
Subject: ixgbe: fix use of uninitialized padding
From: Emil Tantilov <emil.s.tantilov(a)intel.com>
[ Upstream commit dcfd6b839c998bc9838e2a47f44f37afbdf3099c ]
This patch is resolving Coverity hits where padding in a structure could
be used uninitialized.
- Initialize fwd_cmd.pad/2 before ixgbe_calculate_checksum()
- Initialize buffer.pad2/3 before ixgbe_hic_unlocked()
Signed-off-by: Emil Tantilov <emil.s.tantilov(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 4 ++--
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -3620,10 +3620,10 @@ s32 ixgbe_set_fw_drv_ver_generic(struct
fw_cmd.ver_build = build;
fw_cmd.ver_sub = sub;
fw_cmd.hdr.checksum = 0;
- fw_cmd.hdr.checksum = ixgbe_calculate_checksum((u8 *)&fw_cmd,
- (FW_CEM_HDR_LEN + fw_cmd.hdr.buf_len));
fw_cmd.pad = 0;
fw_cmd.pad2 = 0;
+ fw_cmd.hdr.checksum = ixgbe_calculate_checksum((u8 *)&fw_cmd,
+ (FW_CEM_HDR_LEN + fw_cmd.hdr.buf_len));
for (i = 0; i <= FW_CEM_MAX_RETRIES; i++) {
ret_val = ixgbe_host_interface_command(hw, (u32 *)&fw_cmd,
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -564,6 +564,8 @@ static s32 ixgbe_read_ee_hostif_buffer_X
/* convert offset from words to bytes */
buffer.address = cpu_to_be32((offset + current_word) * 2);
buffer.length = cpu_to_be16(words_to_read * 2);
+ buffer.pad2 = 0;
+ buffer.pad3 = 0;
status = ixgbe_host_interface_command(hw, (u32 *)&buffer,
sizeof(buffer),
Patches currently in stable-queue which might be from emil.s.tantilov(a)intel.com are
queue-4.4/ixgbe-fix-use-of-uninitialized-padding.patch
This is a note to let you know that I've just added the patch titled
KVM: pci-assign: do not map smm memory slot pages in vt-d page tables
to the 4.4-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:
kvm-pci-assign-do-not-map-smm-memory-slot-pages-in-vt-d-page-tables.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: "Herongguang (Stephen)" <herongguang.he(a)huawei.com>
Date: Mon, 27 Mar 2017 15:21:17 +0800
Subject: KVM: pci-assign: do not map smm memory slot pages in vt-d page tables
From: "Herongguang (Stephen)" <herongguang.he(a)huawei.com>
[ Upstream commit 0292e169b2d9c8377a168778f0b16eadb1f578fd ]
or VM memory are not put thus leaked in kvm_iommu_unmap_memslots() when
destroy VM.
This is consistent with current vfio implementation.
Signed-off-by: herongguang <herongguang.he(a)huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
virt/kvm/kvm_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -986,7 +986,7 @@ int __kvm_set_memory_region(struct kvm *
* changes) is disallowed above, so any other attribute changes getting
* here can be skipped.
*/
- if ((change == KVM_MR_CREATE) || (change == KVM_MR_MOVE)) {
+ if (as_id == 0 && (change == KVM_MR_CREATE || change == KVM_MR_MOVE)) {
r = kvm_iommu_map_pages(kvm, &new);
return r;
}
Patches currently in stable-queue which might be from herongguang.he(a)huawei.com are
queue-4.4/kvm-pci-assign-do-not-map-smm-memory-slot-pages-in-vt-d-page-tables.patch
This is a note to let you know that I've just added the patch titled
isdn: kcapi: avoid uninitialized data
to the 4.4-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:
isdn-kcapi-avoid-uninitialized-data.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 28 Mar 2017 12:11:07 +0200
Subject: isdn: kcapi: avoid uninitialized data
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit af109a2cf6a9a6271fa420ae2d64d72d86c92b7d ]
gcc-7 points out that the AVMB1_ADDCARD ioctl results in an unintialized
value ending up in the cardnr parameter:
drivers/isdn/capi/kcapi.c: In function 'old_capi_manufacturer':
drivers/isdn/capi/kcapi.c:1042:24: error: 'cdef.cardnr' may be used uninitialized in this function [-Werror=maybe-uninitialized]
cparams.cardnr = cdef.cardnr;
This has been broken since before the start of the git history, so
either the value is not used for anything important, or the ioctl
command doesn't get called in practice.
Setting the cardnr to zero avoids the warning and makes sure
we have consistent behavior.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
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/isdn/capi/kcapi.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/isdn/capi/kcapi.c
+++ b/drivers/isdn/capi/kcapi.c
@@ -1032,6 +1032,7 @@ static int old_capi_manufacturer(unsigne
sizeof(avmb1_carddef))))
return -EFAULT;
cdef.cardtype = AVM_CARDTYPE_B1;
+ cdef.cardnr = 0;
} else {
if ((retval = copy_from_user(&cdef, data,
sizeof(avmb1_extcarddef))))
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/hwmon-asus_atk0110-fix-uninitialized-data-access.patch
queue-4.4/arm-hide-finish_arch_post_lock_switch-from-modules.patch
queue-4.4/bna-avoid-writing-uninitialized-data-into-hw-registers.patch
queue-4.4/isdn-kcapi-avoid-uninitialized-data.patch
This is a note to let you know that I've just added the patch titled
irda: vlsi_ir: fix check for DMA mapping errors
to the 4.4-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:
irda-vlsi_ir-fix-check-for-dma-mapping-errors.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Date: Sat, 25 Mar 2017 01:48:08 +0300
Subject: irda: vlsi_ir: fix check for DMA mapping errors
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
[ Upstream commit 6ac3b77a6ffff7513ff86b684aa256ea01c0e5b5 ]
vlsi_alloc_ring() checks for DMA mapping errors by comparing
returned address with zero, while pci_dma_mapping_error() should be used.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
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/irda/vlsi_ir.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/net/irda/vlsi_ir.c
+++ b/drivers/net/irda/vlsi_ir.c
@@ -418,8 +418,9 @@ static struct vlsi_ring *vlsi_alloc_ring
memset(rd, 0, sizeof(*rd));
rd->hw = hwmap + i;
rd->buf = kmalloc(len, GFP_KERNEL|GFP_DMA);
- if (rd->buf == NULL ||
- !(busaddr = pci_map_single(pdev, rd->buf, len, dir))) {
+ if (rd->buf)
+ busaddr = pci_map_single(pdev, rd->buf, len, dir);
+ if (rd->buf == NULL || pci_dma_mapping_error(pdev, busaddr)) {
if (rd->buf) {
net_err_ratelimited("%s: failed to create PCI-MAP for %p\n",
__func__, rd->buf);
@@ -430,8 +431,7 @@ static struct vlsi_ring *vlsi_alloc_ring
rd = r->rd + j;
busaddr = rd_get_addr(rd);
rd_set_addr_status(rd, 0, 0);
- if (busaddr)
- pci_unmap_single(pdev, busaddr, len, dir);
+ pci_unmap_single(pdev, busaddr, len, dir);
kfree(rd->buf);
rd->buf = NULL;
}
Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are
queue-4.4/irda-vlsi_ir-fix-check-for-dma-mapping-errors.patch
This is a note to let you know that I've just added the patch titled
igb: check memory allocation failure
to the 4.4-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:
igb-check-memory-allocation-failure.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sun, 27 Aug 2017 08:39:51 +0200
Subject: igb: check memory allocation failure
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 18eb86362a52f0af933cc0fd5e37027317eb2d1c ]
Check memory allocation failures and return -ENOMEM in such cases, as
already done for other memory allocations in this function.
This avoids NULL pointers dereference.
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com
Acked-by: PJ Waskiewicz <peter.waskiewicz.jr(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3005,6 +3005,8 @@ static int igb_sw_init(struct igb_adapte
/* Setup and initialize a copy of the hw vlan table array */
adapter->shadow_vfta = kcalloc(E1000_VLAN_FILTER_TBL_SIZE, sizeof(u32),
GFP_ATOMIC);
+ if (!adapter->shadow_vfta)
+ return -ENOMEM;
/* This call may decrease the number of queues */
if (igb_init_interrupt_scheme(adapter, true)) {
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.4/igb-check-memory-allocation-failure.patch
This is a note to let you know that I've just added the patch titled
i40e: Do not enable NAPI on q_vectors that have no rings
to the 4.4-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:
i40e-do-not-enable-napi-on-q_vectors-that-have-no-rings.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
Date: Fri, 24 Mar 2017 15:01:42 -0700
Subject: i40e: Do not enable NAPI on q_vectors that have no rings
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
[ Upstream commit 13a8cd191a2b470cfd435b3b57dbd21aa65ff78c ]
When testing the epoll w/ busy poll code I found that I could get into a
state where the i40e driver had q_vectors w/ active NAPI that had no rings.
This was resulting in a divide by zero error. To correct it I am updating
the driver code so that we only support NAPI on q_vectors that have 1 or
more rings allocated to them.
Signed-off-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.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/intel/i40e/i40e_main.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -4201,8 +4201,12 @@ static void i40e_napi_enable_all(struct
if (!vsi->netdev)
return;
- for (q_idx = 0; q_idx < vsi->num_q_vectors; q_idx++)
- napi_enable(&vsi->q_vectors[q_idx]->napi);
+ for (q_idx = 0; q_idx < vsi->num_q_vectors; q_idx++) {
+ struct i40e_q_vector *q_vector = vsi->q_vectors[q_idx];
+
+ if (q_vector->rx.ring || q_vector->tx.ring)
+ napi_enable(&q_vector->napi);
+ }
}
/**
@@ -4216,8 +4220,12 @@ static void i40e_napi_disable_all(struct
if (!vsi->netdev)
return;
- for (q_idx = 0; q_idx < vsi->num_q_vectors; q_idx++)
- napi_disable(&vsi->q_vectors[q_idx]->napi);
+ for (q_idx = 0; q_idx < vsi->num_q_vectors; q_idx++) {
+ struct i40e_q_vector *q_vector = vsi->q_vectors[q_idx];
+
+ if (q_vector->rx.ring || q_vector->tx.ring)
+ napi_disable(&q_vector->napi);
+ }
}
/**
Patches currently in stable-queue which might be from alexander.h.duyck(a)intel.com are
queue-4.4/i40e-do-not-enable-napi-on-q_vectors-that-have-no-rings.patch
queue-4.4/net-do-not-allow-negative-values-for-busy_read-and-busy_poll-sysctl-interfaces.patch
This is a note to let you know that I've just added the patch titled
i2c: mux: pca954x: Add missing pca9546 definition to chip_desc
to the 4.4-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:
i2c-mux-pca954x-add-missing-pca9546-definition-to-chip_desc.patch
and it can be found in the queue-4.4 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 Thu Dec 21 10:35:49 CET 2017
From: Mike Looijmans <mike.looijmans(a)topic.nl>
Date: Thu, 23 Mar 2017 10:00:36 +0100
Subject: i2c: mux: pca954x: Add missing pca9546 definition to chip_desc
From: Mike Looijmans <mike.looijmans(a)topic.nl>
[ Upstream commit dbe4d69d252e9e65c6c46826980b77b11a142065 ]
The spec for the pca9546 was missing. This chip is the same as the pca9545
except that it lacks interrupt lines. While the i2c_device_id table mapped
the pca9546 to the pca9545 definition the compatible table did not.
Signed-off-by: Mike Looijmans <mike.looijmans(a)topic.nl>
Signed-off-by: Peter Rosin <peda(a)axentia.se>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -94,6 +94,10 @@ static const struct chip_desc chips[] =
.nchans = 4,
.muxtype = pca954x_isswi,
},
+ [pca_9546] = {
+ .nchans = 4,
+ .muxtype = pca954x_isswi,
+ },
[pca_9547] = {
.nchans = 8,
.enable = 0x8,
@@ -111,7 +115,7 @@ static const struct i2c_device_id pca954
{ "pca9543", pca_9543 },
{ "pca9544", pca_9544 },
{ "pca9545", pca_9545 },
- { "pca9546", pca_9545 },
+ { "pca9546", pca_9546 },
{ "pca9547", pca_9547 },
{ "pca9548", pca_9548 },
{ }
Patches currently in stable-queue which might be from mike.looijmans(a)topic.nl are
queue-4.4/i2c-mux-pca954x-add-missing-pca9546-definition-to-chip_desc.patch