This is a note to let you know that I've just added the patch titled
powerpc/powernv/ioda2: Gracefully fail if too many TCE levels requested
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:
powerpc-powernv-ioda2-gracefully-fail-if-too-many-tce-levels-requested.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 Tue Dec 12 13:38:50 CET 2017
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Date: Wed, 22 Feb 2017 15:43:59 +1100
Subject: powerpc/powernv/ioda2: Gracefully fail if too many TCE levels requested
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
[ Upstream commit 7aafac11e308d37ed3c509829bb43d80c1811ac3 ]
The IODA2 specification says that a 64 DMA address cannot use top 4 bits
(3 are reserved and one is a "TVE select"); bottom page_shift bits
cannot be used for multilevel table addressing either.
The existing IODA2 table allocation code aligns the minimum TCE table
size to PAGE_SIZE so in the case of 64K system pages and 4K IOMMU pages,
we have 64-4-12=48 bits. Since 64K page stores 8192 TCEs, i.e. needs
13 bits, the maximum number of levels is 48/13 = 3 so we physically
cannot address more and EEH happens on DMA accesses.
This adds a check that too many levels were requested.
It is still possible to have 5 levels in the case of 4K system page size.
Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Acked-by: Gavin Shan <gwshan(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 3 +++
1 file changed, 3 insertions(+)
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2270,6 +2270,9 @@ static long pnv_pci_ioda2_table_alloc_pa
level_shift = entries_shift + 3;
level_shift = max_t(unsigned, level_shift, PAGE_SHIFT);
+ if ((level_shift - 3) * levels + page_shift >= 60)
+ return -EINVAL;
+
/* Allocate TCE table */
addr = pnv_pci_ioda2_table_do_alloc_pages(nid, level_shift,
levels, tce_table_size, &offset, &total_allocated);
Patches currently in stable-queue which might be from aik(a)ozlabs.ru are
queue-4.4/powerpc-powernv-ioda2-gracefully-fail-if-too-many-tce-levels-requested.patch
This is a note to let you know that I've just added the patch titled
NFS: Fix a typo in nfs_rename()
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:
nfs-fix-a-typo-in-nfs_rename.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 Tue Dec 12 13:38:50 CET 2017
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Mon, 6 Nov 2017 15:28:04 -0500
Subject: NFS: Fix a typo in nfs_rename()
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
[ Upstream commit d803224c84be067754db7fa58a93f36f61566493 ]
On successful rename, the "old_dentry" is retained and is attached to
the "new_dir", so we need to call nfs_set_verifier() accordingly.
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -2051,7 +2051,7 @@ out:
if (new_inode != NULL)
nfs_drop_nlink(new_inode);
d_move(old_dentry, new_dentry);
- nfs_set_verifier(new_dentry,
+ nfs_set_verifier(old_dentry,
nfs_save_change_attribute(new_dir));
} else if (error == -ENOENT)
nfs_dentry_handle_enoent(old_dentry);
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.4/nfs-fix-a-typo-in-nfs_rename.patch
This is a note to let you know that I've just added the patch titled
netfilter: don't track fragmented packets
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-don-t-track-fragmented-packets.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 Tue Dec 12 13:38:50 CET 2017
From: Florian Westphal <fw(a)strlen.de>
Date: Fri, 3 Mar 2017 21:44:00 +0100
Subject: netfilter: don't track fragmented packets
From: Florian Westphal <fw(a)strlen.de>
[ Upstream commit 7b4fdf77a450ec0fdcb2f677b080ddbf2c186544 ]
Andrey reports syzkaller splat caused by
NF_CT_ASSERT(!ip_is_fragment(ip_hdr(skb)));
in ipv4 nat. But this assertion (and the comment) are wrong, this function
does see fragments when IP_NODEFRAG setsockopt is used.
As conntrack doesn't track packets without complete l4 header, only the
first fragment is tracked.
Because applying nat to first packet but not the rest makes no sense this
also turns off tracking of all fragments.
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
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_conntrack_l3proto_ipv4.c | 4 ++++
net/ipv4/netfilter/nf_nat_l3proto_ipv4.c | 5 -----
2 files changed, 4 insertions(+), 5 deletions(-)
--- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
@@ -158,6 +158,10 @@ static unsigned int ipv4_conntrack_local
if (skb->len < sizeof(struct iphdr) ||
ip_hdrlen(skb) < sizeof(struct iphdr))
return NF_ACCEPT;
+
+ if (ip_is_fragment(ip_hdr(skb))) /* IP_NODEFRAG setsockopt set */
+ return NF_ACCEPT;
+
return nf_conntrack_in(state->net, PF_INET, state->hook, skb);
}
--- a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
@@ -268,11 +268,6 @@ nf_nat_ipv4_fn(void *priv, struct sk_buf
/* maniptype == SRC for postrouting. */
enum nf_nat_manip_type maniptype = HOOK2MANIP(state->hook);
- /* We never see fragments: conntrack defrags on pre-routing
- * and local-out, and nf_nat_out protects post-routing.
- */
- NF_CT_ASSERT(!ip_is_fragment(ip_hdr(skb)));
-
ct = nf_ct_get(skb, &ctinfo);
/* Can't track? It's not due to stress, or conntrack would
* have dropped it. Hence it's the user's responsibilty to
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.4/netfilter-don-t-track-fragmented-packets.patch
This is a note to let you know that I've just added the patch titled
module: set __jump_table alignment to 8
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:
module-set-__jump_table-alignment-to-8.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 Tue Dec 12 13:38:50 CET 2017
From: David Daney <david.daney(a)cavium.com>
Date: Wed, 1 Mar 2017 14:04:53 -0800
Subject: module: set __jump_table alignment to 8
From: David Daney <david.daney(a)cavium.com>
[ Upstream commit ab42632156becd35d3884ee5c14da2bedbf3149a ]
For powerpc the __jump_table section in modules is not aligned, this
causes a WARN_ON() splat when loading a module containing a __jump_table.
Strict alignment became necessary with commit 3821fd35b58d
("jump_label: Reduce the size of struct static_key"), currently in
linux-next, which uses the two least significant bits of pointers to
__jump_table elements.
Fix by forcing __jump_table to 8, which is the same alignment used for
this section in the kernel proper.
Link: http://lkml.kernel.org/r/20170301220453.4756-1-david.daney@cavium.com
Reviewed-by: Jason Baron <jbaron(a)akamai.com>
Acked-by: Jessica Yu <jeyu(a)redhat.com>
Acked-by: Michael Ellerman <mpe(a)ellerman.id.au> (powerpc)
Tested-by: Sachin Sant <sachinp(a)linux.vnet.ibm.com>
Signed-off-by: David Daney <david.daney(a)cavium.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
scripts/module-common.lds | 2 ++
1 file changed, 2 insertions(+)
--- a/scripts/module-common.lds
+++ b/scripts/module-common.lds
@@ -19,4 +19,6 @@ SECTIONS {
. = ALIGN(8);
.init_array 0 : { *(SORT(.init_array.*)) *(.init_array) }
+
+ __jump_table 0 : ALIGN(8) { KEEP(*(__jump_table)) }
}
Patches currently in stable-queue which might be from david.daney(a)cavium.com are
queue-4.4/module-set-__jump_table-alignment-to-8.patch
This is a note to let you know that I've just added the patch titled
libata: drop WARN from protocol error in ata_sff_qc_issue()
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:
libata-drop-warn-from-protocol-error-in-ata_sff_qc_issue.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 Tue Dec 12 13:38:50 CET 2017
From: Tejun Heo <tj(a)kernel.org>
Date: Mon, 6 Mar 2017 15:26:54 -0500
Subject: libata: drop WARN from protocol error in ata_sff_qc_issue()
From: Tejun Heo <tj(a)kernel.org>
[ Upstream commit 0580b762a4d6b70817476b90042813f8573283fa ]
ata_sff_qc_issue() expects upper layers to never issue commands on a
command protocol that it doesn't implement. While the assumption
holds fine with the usual IO path, nothing filters based on the
command protocol in the passthrough path (which was added later),
allowing the warning to be tripped with a passthrough command with the
right (well, wrong) protocol.
Failing with AC_ERR_SYSTEM is the right thing to do anyway. Remove
the unnecessary WARN.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Link: http://lkml.kernel.org/r/CACT4Y+bXkvevNZU8uP6X0QVqsj6wNoUA_1exfTSOzc+SmUtMO…
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>
---
drivers/ata/libata-sff.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -1480,7 +1480,6 @@ unsigned int ata_sff_qc_issue(struct ata
break;
default:
- WARN_ON_ONCE(1);
return AC_ERR_SYSTEM;
}
Patches currently in stable-queue which might be from tj(a)kernel.org are
queue-4.4/libata-drop-warn-from-protocol-error-in-ata_sff_qc_issue.patch
queue-4.4/workqueue-trigger-warn-if-queue_delayed_work-is-called-with-null-wq.patch
This is a note to let you know that I've just added the patch titled
mac80211_hwsim: Fix memory leak in hwsim_new_radio_nl()
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:
mac80211_hwsim-fix-memory-leak-in-hwsim_new_radio_nl.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 Tue Dec 12 13:38:50 CET 2017
From: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Date: Fri, 10 Nov 2017 18:48:50 +0000
Subject: mac80211_hwsim: Fix memory leak in hwsim_new_radio_nl()
From: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
[ Upstream commit 67bd52386125ce1159c0581cbcd2740addf33cd4 ]
hwsim_new_radio_nl() now copies the name attribute in order to add a
null-terminator. mac80211_hwsim_new_radio() (indirectly) copies it
again into the net_device structure, so the first copy is not used or
freed later. Free the first copy before returning.
Fixes: ff4dd73dd2b4 ("mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length")
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Johannes Berg <johannes.berg(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/wireless/mac80211_hwsim.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2885,6 +2885,7 @@ static int hwsim_new_radio_nl(struct sk_
{
struct hwsim_new_radio_params param = { 0 };
const char *hwname = NULL;
+ int ret;
param.reg_strict = info->attrs[HWSIM_ATTR_REG_STRICT_REG];
param.p2p_device = info->attrs[HWSIM_ATTR_SUPPORT_P2P_DEVICE];
@@ -2924,7 +2925,9 @@ static int hwsim_new_radio_nl(struct sk_
param.regd = hwsim_world_regdom_custom[idx];
}
- return mac80211_hwsim_new_radio(info, ¶m);
+ ret = mac80211_hwsim_new_radio(info, ¶m);
+ kfree(hwname);
+ return ret;
}
static int hwsim_del_radio_nl(struct sk_buff *msg, struct genl_info *info)
Patches currently in stable-queue which might be from ben.hutchings(a)codethink.co.uk are
queue-4.4/mac80211_hwsim-fix-memory-leak-in-hwsim_new_radio_nl.patch
This is a note to let you know that I've just added the patch titled
lib/genalloc.c: make the avail variable an atomic_long_t
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:
lib-genalloc.c-make-the-avail-variable-an-atomic_long_t.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 Tue Dec 12 13:38:50 CET 2017
From: Stephen Bates <sbates(a)raithlin.com>
Date: Fri, 17 Nov 2017 15:28:16 -0800
Subject: lib/genalloc.c: make the avail variable an atomic_long_t
From: Stephen Bates <sbates(a)raithlin.com>
[ Upstream commit 36a3d1dd4e16bcd0d2ddfb4a2ec7092f0ae0d931 ]
If the amount of resources allocated to a gen_pool exceeds 2^32 then the
avail atomic overflows and this causes problems when clients try and
borrow resources from the pool. This is only expected to be an issue on
64 bit systems.
Add the <linux/atomic.h> header to pull in atomic_long* operations. So
that 32 bit systems continue to use atomic32_t but 64 bit systems can
use atomic64_t.
Link: http://lkml.kernel.org/r/1509033843-25667-1-git-send-email-sbates@raithlin.…
Signed-off-by: Stephen Bates <sbates(a)raithlin.com>
Reviewed-by: Logan Gunthorpe <logang(a)deltatee.com>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com>
Reviewed-by: Daniel Mentz <danielmentz(a)google.com>
Cc: Jonathan Corbet <corbet(a)lwn.net>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/genalloc.h | 3 ++-
lib/genalloc.c | 10 +++++-----
2 files changed, 7 insertions(+), 6 deletions(-)
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -31,6 +31,7 @@
#define __GENALLOC_H__
#include <linux/spinlock_types.h>
+#include <linux/atomic.h>
struct device;
struct device_node;
@@ -68,7 +69,7 @@ struct gen_pool {
*/
struct gen_pool_chunk {
struct list_head next_chunk; /* next chunk in pool */
- atomic_t avail;
+ atomic_long_t avail;
phys_addr_t phys_addr; /* physical starting address of memory chunk */
unsigned long start_addr; /* start address of memory chunk */
unsigned long end_addr; /* end address of memory chunk (inclusive) */
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -194,7 +194,7 @@ int gen_pool_add_virt(struct gen_pool *p
chunk->phys_addr = phys;
chunk->start_addr = virt;
chunk->end_addr = virt + size - 1;
- atomic_set(&chunk->avail, size);
+ atomic_long_set(&chunk->avail, size);
spin_lock(&pool->lock);
list_add_rcu(&chunk->next_chunk, &pool->chunks);
@@ -285,7 +285,7 @@ unsigned long gen_pool_alloc(struct gen_
nbits = (size + (1UL << order) - 1) >> order;
rcu_read_lock();
list_for_each_entry_rcu(chunk, &pool->chunks, next_chunk) {
- if (size > atomic_read(&chunk->avail))
+ if (size > atomic_long_read(&chunk->avail))
continue;
start_bit = 0;
@@ -305,7 +305,7 @@ retry:
addr = chunk->start_addr + ((unsigned long)start_bit << order);
size = nbits << order;
- atomic_sub(size, &chunk->avail);
+ atomic_long_sub(size, &chunk->avail);
break;
}
rcu_read_unlock();
@@ -371,7 +371,7 @@ void gen_pool_free(struct gen_pool *pool
remain = bitmap_clear_ll(chunk->bits, start_bit, nbits);
BUG_ON(remain);
size = nbits << order;
- atomic_add(size, &chunk->avail);
+ atomic_long_add(size, &chunk->avail);
rcu_read_unlock();
return;
}
@@ -445,7 +445,7 @@ size_t gen_pool_avail(struct gen_pool *p
rcu_read_lock();
list_for_each_entry_rcu(chunk, &pool->chunks, next_chunk)
- avail += atomic_read(&chunk->avail);
+ avail += atomic_long_read(&chunk->avail);
rcu_read_unlock();
return avail;
}
Patches currently in stable-queue which might be from sbates(a)raithlin.com are
queue-4.4/lib-genalloc.c-make-the-avail-variable-an-atomic_long_t.patch
This is a note to let you know that I've just added the patch titled
kvm: nVMX: VMCLEAR should not cause the vCPU to shut down
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-nvmx-vmclear-should-not-cause-the-vcpu-to-shut-down.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 Tue Dec 12 13:38:50 CET 2017
From: Jim Mattson <jmattson(a)google.com>
Date: Thu, 2 Mar 2017 12:41:48 -0800
Subject: kvm: nVMX: VMCLEAR should not cause the vCPU to shut down
From: Jim Mattson <jmattson(a)google.com>
[ Upstream commit 587d7e72aedca91cee80c0a56811649c3efab765 ]
VMCLEAR should silently ignore a failure to clear the launch state of
the VMCS referenced by the operand.
Signed-off-by: Jim Mattson <jmattson(a)google.com>
[Changed "kvm_write_guest(vcpu->kvm" to "kvm_vcpu_write_guest(vcpu".]
Signed-off-by: Radim Krčmář <rkrcmar(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 | 22 ++++------------------
1 file changed, 4 insertions(+), 18 deletions(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6924,9 +6924,8 @@ static int handle_vmoff(struct kvm_vcpu
static int handle_vmclear(struct kvm_vcpu *vcpu)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
+ u32 zero = 0;
gpa_t vmptr;
- struct vmcs12 *vmcs12;
- struct page *page;
if (!nested_vmx_check_permission(vcpu))
return 1;
@@ -6937,22 +6936,9 @@ static int handle_vmclear(struct kvm_vcp
if (vmptr == vmx->nested.current_vmptr)
nested_release_vmcs12(vmx);
- page = nested_get_page(vcpu, vmptr);
- if (page == NULL) {
- /*
- * For accurate processor emulation, VMCLEAR beyond available
- * physical memory should do nothing at all. However, it is
- * possible that a nested vmx bug, not a guest hypervisor bug,
- * resulted in this case, so let's shut down before doing any
- * more damage:
- */
- kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
- return 1;
- }
- vmcs12 = kmap(page);
- vmcs12->launch_state = 0;
- kunmap(page);
- nested_release_page(page);
+ kvm_vcpu_write_guest(vcpu,
+ vmptr + offsetof(struct vmcs12, launch_state),
+ &zero, sizeof(zero));
nested_free_vmcs02(vmx, vmptr);
Patches currently in stable-queue which might be from jmattson(a)google.com are
queue-4.4/kvm-nvmx-reset-nested_run_pending-if-the-vcpu-is-going-to-be-reset.patch
queue-4.4/kvm-nvmx-vmclear-should-not-cause-the-vcpu-to-shut-down.patch
queue-4.4/kvm-vmx-remove-i-o-port-0x80-bypass-on-intel-hosts.patch
This is a note to let you know that I've just added the patch titled
KVM: nVMX: reset nested_run_pending if the vCPU is going to be reset
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-nvmx-reset-nested_run_pending-if-the-vcpu-is-going-to-be-reset.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 Tue Dec 12 13:38:50 CET 2017
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
Date: Mon, 6 Mar 2017 04:03:28 -0800
Subject: KVM: nVMX: reset nested_run_pending if the vCPU is going to be reset
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
[ Upstream commit 2f707d97982286b307ef2a9b034e19aabc1abb56 ]
Reported by syzkaller:
WARNING: CPU: 1 PID: 27742 at arch/x86/kvm/vmx.c:11029
nested_vmx_vmexit+0x5c35/0x74d0 arch/x86/kvm/vmx.c:11029
CPU: 1 PID: 27742 Comm: a.out Not tainted 4.10.0+ #229
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:15 [inline]
dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
panic+0x1fb/0x412 kernel/panic.c:179
__warn+0x1c4/0x1e0 kernel/panic.c:540
warn_slowpath_null+0x2c/0x40 kernel/panic.c:583
nested_vmx_vmexit+0x5c35/0x74d0 arch/x86/kvm/vmx.c:11029
vmx_leave_nested arch/x86/kvm/vmx.c:11136 [inline]
vmx_set_msr+0x1565/0x1910 arch/x86/kvm/vmx.c:3324
kvm_set_msr+0xd4/0x170 arch/x86/kvm/x86.c:1099
do_set_msr+0x11e/0x190 arch/x86/kvm/x86.c:1128
__msr_io arch/x86/kvm/x86.c:2577 [inline]
msr_io+0x24b/0x450 arch/x86/kvm/x86.c:2614
kvm_arch_vcpu_ioctl+0x35b/0x46a0 arch/x86/kvm/x86.c:3497
kvm_vcpu_ioctl+0x232/0x1120 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2721
vfs_ioctl fs/ioctl.c:43 [inline]
do_vfs_ioctl+0x1bf/0x1790 fs/ioctl.c:683
SYSC_ioctl fs/ioctl.c:698 [inline]
SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689
entry_SYSCALL_64_fastpath+0x1f/0xc2
The syzkaller folks reported a nested_run_pending warning during userspace
clear VMX capability which is exposed to L1 before.
The warning gets thrown while doing
(*(uint32_t*)0x20aecfe8 = (uint32_t)0x1);
(*(uint32_t*)0x20aecfec = (uint32_t)0x0);
(*(uint32_t*)0x20aecff0 = (uint32_t)0x3a);
(*(uint32_t*)0x20aecff4 = (uint32_t)0x0);
(*(uint64_t*)0x20aecff8 = (uint64_t)0x0);
r[29] = syscall(__NR_ioctl, r[4], 0x4008ae89ul,
0x20aecfe8ul, 0, 0, 0, 0, 0, 0);
i.e. KVM_SET_MSR ioctl with
struct kvm_msrs {
.nmsrs = 1,
.pad = 0,
.entries = {
{.index = MSR_IA32_FEATURE_CONTROL,
.reserved = 0,
.data = 0}
}
}
The VMLANCH/VMRESUME emulation should be stopped since the CPU is going to
reset here. This patch resets the nested_run_pending since the CPU is going
to be reset hence there should be nothing pending.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Suggested-by: Radim Krčmář <rkrcmar(a)redhat.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: David Hildenbrand <david(a)redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Reviewed-by: Jim Mattson <jmattson(a)google.com>
Signed-off-by: Radim Krčmář <rkrcmar(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 | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -10555,8 +10555,10 @@ static void nested_vmx_vmexit(struct kvm
*/
static void vmx_leave_nested(struct kvm_vcpu *vcpu)
{
- if (is_guest_mode(vcpu))
+ if (is_guest_mode(vcpu)) {
+ to_vmx(vcpu)->nested.nested_run_pending = 0;
nested_vmx_vmexit(vcpu, -1, 0, 0);
+ }
free_nested(to_vmx(vcpu));
}
Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are
queue-4.4/kvm-nvmx-reset-nested_run_pending-if-the-vcpu-is-going-to-be-reset.patch
This is a note to let you know that I've just added the patch titled
kbuild: pkg: use --transform option to prefix paths in tar
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:
kbuild-pkg-use-transform-option-to-prefix-paths-in-tar.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 Tue Dec 12 13:38:50 CET 2017
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Date: Wed, 15 Nov 2017 18:17:07 +0900
Subject: kbuild: pkg: use --transform option to prefix paths in tar
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
[ Upstream commit 2dbc644ac62bbcb9ee78e84719953f611be0413d ]
For rpm-pkg and deb-pkg, a source tar file is created. All paths in
the archive must be prefixed with the base name of the tar so that
everything is contained in the directory when you extract it.
Currently, scripts/package/Makefile uses a symlink for that, and
removes it after the tar is created.
If you terminate the build during the tar creation, the symlink is
left over. Then, at the next package build, you will see a warning
like follows:
ln: '.' and 'kernel-4.14.0+/.' are the same file
It is possible to fix it by adding -n (--no-dereference) option to
the "ln" command, but a cleaner way is to use --transform option
of "tar" command. This option is GNU extension, but it should not
hurt to use it in the Linux build system.
The 'S' flag is needed to exclude symlinks from the path fixup.
Without it, symlinks in the kernel are broken.
Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
scripts/package/Makefile | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/scripts/package/Makefile
+++ b/scripts/package/Makefile
@@ -39,10 +39,9 @@ if test "$(objtree)" != "$(srctree)"; th
false; \
fi ; \
$(srctree)/scripts/setlocalversion --save-scmversion; \
-ln -sf $(srctree) $(2); \
tar -cz $(RCS_TAR_IGNORE) -f $(2).tar.gz \
- $(addprefix $(2)/,$(TAR_CONTENT) $(3)); \
-rm -f $(2) $(objtree)/.scmversion
+ --transform 's:^:$(2)/:S' $(TAR_CONTENT) $(3); \
+rm -f $(objtree)/.scmversion
# rpm-pkg
# ---------------------------------------------------------------------------
Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are
queue-4.4/kbuild-pkg-use-transform-option-to-prefix-paths-in-tar.patch
This is a note to let you know that I've just added the patch titled
jump_label: Invoke jump_label_test() via early_initcall()
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:
jump_label-invoke-jump_label_test-via-early_initcall.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 Tue Dec 12 13:38:50 CET 2017
From: Jason Baron <jbaron(a)akamai.com>
Date: Mon, 13 Nov 2017 16:48:47 -0500
Subject: jump_label: Invoke jump_label_test() via early_initcall()
From: Jason Baron <jbaron(a)akamai.com>
[ Upstream commit 92ee46efeb505ead3ab06d3c5ce695637ed5f152 ]
Fengguang Wu reported that running the rcuperf test during boot can cause
the jump_label_test() to hit a WARN_ON(). The issue is that the core jump
label code relies on kernel_text_address() to detect when it can no longer
update branches that may be contained in __init sections. The
kernel_text_address() in turn assumes that if the system_state variable is
greter than or equal to SYSTEM_RUNNING then __init sections are no longer
valid (since the assumption is that they have been freed). However, when
rcuperf is setup to run in early boot it can call kernel_power_off() which
sets the system_state to SYSTEM_POWER_OFF.
Since rcuperf initialization is invoked via a module_init(), we can make
the dependency of jump_label_test() needing to complete before rcuperf
explicit by calling it via early_initcall().
Reported-by: Fengguang Wu <fengguang.wu(a)intel.com>
Signed-off-by: Jason Baron <jbaron(a)akamai.com>
Acked-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/1510609727-2238-1-git-send-email-jbaron@akamai.com
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/jump_label.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -553,7 +553,7 @@ static __init int jump_label_test(void)
return 0;
}
-late_initcall(jump_label_test);
+early_initcall(jump_label_test);
#endif /* STATIC_KEYS_SELFTEST */
#endif /* HAVE_JUMP_LABEL */
Patches currently in stable-queue which might be from jbaron(a)akamai.com are
queue-4.4/module-set-__jump_table-alignment-to-8.patch
queue-4.4/jump_label-invoke-jump_label_test-via-early_initcall.patch
queue-4.4/dynamic-debug-howto-fix-optional-omitted-ending-line-number-to-be-large-instead-of-0.patch
This is a note to let you know that I've just added the patch titled
irqchip/crossbar: Fix incorrect type of register size
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:
irqchip-crossbar-fix-incorrect-type-of-register-size.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 Tue Dec 12 13:38:50 CET 2017
From: Franck Demathieu <fdemathieu(a)gmail.com>
Date: Mon, 6 Mar 2017 14:41:06 +0100
Subject: irqchip/crossbar: Fix incorrect type of register size
From: Franck Demathieu <fdemathieu(a)gmail.com>
[ Upstream commit 4b9de5da7e120c7f02395da729f0ec77ce7a6044 ]
The 'size' variable is unsigned according to the dt-bindings.
As this variable is used as integer in other places, create a new variable
that allows to fix the following sparse issue (-Wtypesign):
drivers/irqchip/irq-crossbar.c:279:52: warning: incorrect type in argument 3 (different signedness)
drivers/irqchip/irq-crossbar.c:279:52: expected unsigned int [usertype] *out_value
drivers/irqchip/irq-crossbar.c:279:52: got int *<noident>
Signed-off-by: Franck Demathieu <fdemathieu(a)gmail.com>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-crossbar.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -199,7 +199,7 @@ static const struct irq_domain_ops cross
static int __init crossbar_of_init(struct device_node *node)
{
int i, size, reserved = 0;
- u32 max = 0, entry;
+ u32 max = 0, entry, reg_size;
const __be32 *irqsr;
int ret = -ENOMEM;
@@ -276,9 +276,9 @@ static int __init crossbar_of_init(struc
if (!cb->register_offsets)
goto err_irq_map;
- of_property_read_u32(node, "ti,reg-size", &size);
+ of_property_read_u32(node, "ti,reg-size", ®_size);
- switch (size) {
+ switch (reg_size) {
case 1:
cb->write = crossbar_writeb;
break;
@@ -304,7 +304,7 @@ static int __init crossbar_of_init(struc
continue;
cb->register_offsets[i] = reserved;
- reserved += size;
+ reserved += reg_size;
}
of_property_read_u32(node, "ti,irqs-safe-map", &cb->safe_map);
Patches currently in stable-queue which might be from fdemathieu(a)gmail.com are
queue-4.4/irqchip-crossbar-fix-incorrect-type-of-register-size.patch
This is a note to let you know that I've just added the patch titled
ipv6: reorder icmpv6_init() and ip6_mr_init()
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:
ipv6-reorder-icmpv6_init-and-ip6_mr_init.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 Tue Dec 12 13:38:50 CET 2017
From: WANG Cong <xiyou.wangcong(a)gmail.com>
Date: Sun, 5 Mar 2017 12:34:53 -0800
Subject: ipv6: reorder icmpv6_init() and ip6_mr_init()
From: WANG Cong <xiyou.wangcong(a)gmail.com>
[ Upstream commit 15e668070a64bb97f102ad9cf3bccbca0545cda8 ]
Andrey reported the following kernel crash:
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 14446 Comm: syz-executor6 Not tainted 4.10.0+ #82
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88001f311700 task.stack: ffff88001f6e8000
RIP: 0010:ip6mr_sk_done+0x15a/0x3d0 net/ipv6/ip6mr.c:1618
RSP: 0018:ffff88001f6ef418 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 1ffff10003edde8c RCX: ffffc900043ee000
RDX: 0000000000000004 RSI: ffffffff83e3b3f8 RDI: 0000000000000020
RBP: ffff88001f6ef508 R08: fffffbfff0dcc5d8 R09: 0000000000000000
R10: ffffffff86e62ec0 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: ffff88001f6ef4e0 R15: ffff8800380a0040
FS: 00007f7a52cec700(0000) GS:ffff88003ec00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000061c500 CR3: 000000001f1ae000 CR4: 00000000000006f0
DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Call Trace:
rawv6_close+0x4c/0x80 net/ipv6/raw.c:1217
inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
inet6_release+0x50/0x70 net/ipv6/af_inet6.c:432
sock_release+0x8d/0x1e0 net/socket.c:597
__sock_create+0x39d/0x880 net/socket.c:1226
sock_create_kern+0x3f/0x50 net/socket.c:1243
inet_ctl_sock_create+0xbb/0x280 net/ipv4/af_inet.c:1526
icmpv6_sk_init+0x163/0x500 net/ipv6/icmp.c:954
ops_init+0x10a/0x550 net/core/net_namespace.c:115
setup_net+0x261/0x660 net/core/net_namespace.c:291
copy_net_ns+0x27e/0x540 net/core/net_namespace.c:396
9pnet_virtio: no channels available for device ./file1
create_new_namespaces+0x437/0x9b0 kernel/nsproxy.c:106
unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:205
SYSC_unshare kernel/fork.c:2281 [inline]
SyS_unshare+0x64e/0x1000 kernel/fork.c:2231
entry_SYSCALL_64_fastpath+0x1f/0xc2
This is because net->ipv6.mr6_tables is not initialized at that point,
ip6mr_rules_init() is not called yet, therefore on the error path when
we iterator the list, we trigger this oops. Fix this by reordering
ip6mr_rules_init() before icmpv6_sk_init().
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.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/ipv6/af_inet6.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -893,12 +893,12 @@ static int __init inet6_init(void)
err = register_pernet_subsys(&inet6_net_ops);
if (err)
goto register_pernet_fail;
- err = icmpv6_init();
- if (err)
- goto icmp_fail;
err = ip6_mr_init();
if (err)
goto ipmr_fail;
+ err = icmpv6_init();
+ if (err)
+ goto icmp_fail;
err = ndisc_init();
if (err)
goto ndisc_fail;
@@ -1016,10 +1016,10 @@ igmp_fail:
ndisc_cleanup();
ndisc_fail:
ip6_mr_cleanup();
-ipmr_fail:
- icmpv6_cleanup();
icmp_fail:
unregister_pernet_subsys(&inet6_net_ops);
+ipmr_fail:
+ icmpv6_cleanup();
register_pernet_fail:
sock_unregister(PF_INET6);
rtnl_unregister_all(PF_INET6);
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.4/ipv6-reorder-icmpv6_init-and-ip6_mr_init.patch
This is a note to let you know that I've just added the patch titled
ipvlan: fix ipv6 outbound device
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:
ipvlan-fix-ipv6-outbound-device.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 Tue Dec 12 13:38:50 CET 2017
From: Keefe Liu <liuqifa(a)huawei.com>
Date: Thu, 9 Nov 2017 20:09:31 +0800
Subject: ipvlan: fix ipv6 outbound device
From: Keefe Liu <liuqifa(a)huawei.com>
[ Upstream commit ca29fd7cce5a6444d57fb86517589a1a31c759e1 ]
When process the outbound packet of ipv6, we should assign the master
device to output device other than input device.
Signed-off-by: Keefe Liu <liuqifa(a)huawei.com>
Acked-by: Mahesh Bandewar <maheshb(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>
---
drivers/net/ipvlan/ipvlan_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -388,7 +388,7 @@ static int ipvlan_process_v6_outbound(st
struct dst_entry *dst;
int err, ret = NET_XMIT_DROP;
struct flowi6 fl6 = {
- .flowi6_iif = dev->ifindex,
+ .flowi6_oif = dev->ifindex,
.daddr = ip6h->daddr,
.saddr = ip6h->saddr,
.flowi6_flags = FLOWI_FLAG_ANYSRC,
Patches currently in stable-queue which might be from liuqifa(a)huawei.com are
queue-4.4/ipvlan-fix-ipv6-outbound-device.patch
This is a note to let you know that I've just added the patch titled
IB/mlx5: Assign send CQ and recv CQ of UMR QP
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:
ib-mlx5-assign-send-cq-and-recv-cq-of-umr-qp.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 Tue Dec 12 13:38:50 CET 2017
From: Majd Dibbiny <majd(a)mellanox.com>
Date: Mon, 30 Oct 2017 14:23:13 +0200
Subject: IB/mlx5: Assign send CQ and recv CQ of UMR QP
From: Majd Dibbiny <majd(a)mellanox.com>
[ Upstream commit 31fde034a8bd964a5c7c1a5663fc87a913158db2 ]
The UMR's QP is created by calling mlx5_ib_create_qp directly, and
therefore the send CQ and the recv CQ on the ibqp weren't assigned.
Assign them right after calling the mlx5_ib_create_qp to assure
that any access to those pointers will work as expected and won't
crash the system as might happen as part of reset flow.
Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Signed-off-by: Majd Dibbiny <majd(a)mellanox.com>
Reviewed-by: Yishai Hadas <yishaih(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx5/main.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -1123,6 +1123,8 @@ static int create_umr_res(struct mlx5_ib
qp->real_qp = qp;
qp->uobject = NULL;
qp->qp_type = MLX5_IB_QPT_REG_UMR;
+ qp->send_cq = init_attr->send_cq;
+ qp->recv_cq = init_attr->recv_cq;
attr->qp_state = IB_QPS_INIT;
attr->port_num = 1;
Patches currently in stable-queue which might be from majd(a)mellanox.com are
queue-4.4/ib-mlx5-assign-send-cq-and-recv-cq-of-umr-qp.patch
queue-4.4/ib-mlx4-increase-maximal-message-size-under-ud-qp.patch
This is a note to let you know that I've just added the patch titled
IB/mlx4: Increase maximal message size under UD QP
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:
ib-mlx4-increase-maximal-message-size-under-ud-qp.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 Tue Dec 12 13:38:50 CET 2017
From: Mark Bloch <markb(a)mellanox.com>
Date: Thu, 2 Nov 2017 15:22:26 +0200
Subject: IB/mlx4: Increase maximal message size under UD QP
From: Mark Bloch <markb(a)mellanox.com>
[ Upstream commit 5f22a1d87c5315a98981ecf93cd8de226cffe6ca ]
Maximal message should be used as a limit to the max message payload allowed,
without the headers. The ConnectX-3 check is done against this value includes
the headers. When the payload is 4K this will cause the NIC to drop packets.
Increase maximal message to 8K as workaround, this shouldn't change current
behaviour because we continue to set the MTU to 4k.
To reproduce;
set MTU to 4296 on the corresponding interface, for example:
ifconfig eth0 mtu 4296 (both server and client)
On server:
ib_send_bw -c UD -d mlx4_0 -s 4096 -n 1000000 -i1 -m 4096
On client:
ib_send_bw -d mlx4_0 -c UD <server_ip> -s 4096 -n 1000000 -i 1 -m 4096
Fixes: 6e0d733d9215 ("IB/mlx4: Allow 4K messages for UD QPs")
Signed-off-by: Mark Bloch <markb(a)mellanox.com>
Reviewed-by: Majd Dibbiny <majd(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx4/qp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -1564,7 +1564,7 @@ static int __mlx4_ib_modify_qp(struct ib
context->mtu_msgmax = (IB_MTU_4096 << 5) |
ilog2(dev->dev->caps.max_gso_sz);
else
- context->mtu_msgmax = (IB_MTU_4096 << 5) | 12;
+ context->mtu_msgmax = (IB_MTU_4096 << 5) | 13;
} else if (attr_mask & IB_QP_PATH_MTU) {
if (attr->path_mtu < IB_MTU_256 || attr->path_mtu > IB_MTU_4096) {
pr_err("path MTU (%u) is invalid\n",
Patches currently in stable-queue which might be from markb(a)mellanox.com are
queue-4.4/ib-mlx4-increase-maximal-message-size-under-ud-qp.patch
This is a note to let you know that I've just added the patch titled
i2c: riic: fix restart condition
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-riic-fix-restart-condition.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 Tue Dec 12 13:38:50 CET 2017
From: Chris Brandt <chris.brandt(a)renesas.com>
Date: Mon, 6 Mar 2017 15:20:51 -0500
Subject: i2c: riic: fix restart condition
From: Chris Brandt <chris.brandt(a)renesas.com>
[ Upstream commit 2501c1bb054290679baad0ff7f4f07c714251f4c ]
While modifying the driver to use the STOP interrupt, the completion of the
intermediate transfers need to wake the driver back up in order to initiate
the next transfer (restart condition). Otherwise you get never ending
interrupts and only the first transfer sent.
Fixes: 71ccea095ea1 ("i2c: riic: correctly finish transfers")
Reported-by: Simon Horman <horms(a)verge.net.au>
Signed-off-by: Chris Brandt <chris.brandt(a)renesas.com>
Tested-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Wolfram Sang <wsa(a)the-dreams.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/i2c/busses/i2c-riic.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/i2c/busses/i2c-riic.c
+++ b/drivers/i2c/busses/i2c-riic.c
@@ -218,8 +218,12 @@ static irqreturn_t riic_tend_isr(int irq
}
if (riic->is_last || riic->err) {
- riic_clear_set_bit(riic, 0, ICIER_SPIE, RIIC_ICIER);
+ riic_clear_set_bit(riic, ICIER_TEIE, ICIER_SPIE, RIIC_ICIER);
writeb(ICCR2_SP, riic->base + RIIC_ICCR2);
+ } else {
+ /* Transfer is complete, but do not send STOP */
+ riic_clear_set_bit(riic, ICIER_TEIE, 0, RIIC_ICIER);
+ complete(&riic->msg_done);
}
return IRQ_HANDLED;
Patches currently in stable-queue which might be from chris.brandt(a)renesas.com are
queue-4.4/i2c-riic-fix-restart-condition.patch
This is a note to let you know that I've just added the patch titled
gpio: altera: Use handle_level_irq when configured as a level_high
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:
gpio-altera-use-handle_level_irq-when-configured-as-a-level_high.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 Tue Dec 12 13:38:50 CET 2017
From: Phil Reid <preid(a)electromag.com.au>
Date: Mon, 20 Feb 2017 09:41:45 +0800
Subject: gpio: altera: Use handle_level_irq when configured as a level_high
From: Phil Reid <preid(a)electromag.com.au>
[ Upstream commit f759921cfbf4847319d197a6ed7c9534d593f8bc ]
When a threaded irq handler is chained attached to one of the gpio
pins when configure for level irq the altera_gpio_irq_leveL_high_handler
does not mask the interrupt while being handled by the chained irq.
This resulting in the threaded irq not getting enough cycles to complete
quickly enough before the irq was disabled as faulty. handle_level_irq
should be used in this situation instead of handle_simple_irq.
In gpiochip_irqchip_add set default handler to handle_bad_irq as
per Documentation/gpio/driver.txt. Then set the correct handler in
the set_type callback.
Signed-off-by: Phil Reid <preid(a)electromag.com.au>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-altera.c | 26 +++++++++++---------------
1 file changed, 11 insertions(+), 15 deletions(-)
--- a/drivers/gpio/gpio-altera.c
+++ b/drivers/gpio/gpio-altera.c
@@ -94,21 +94,18 @@ static int altera_gpio_irq_set_type(stru
altera_gc = to_altera(irq_data_get_irq_chip_data(d));
- if (type == IRQ_TYPE_NONE)
+ if (type == IRQ_TYPE_NONE) {
+ irq_set_handler_locked(d, handle_bad_irq);
return 0;
- if (type == IRQ_TYPE_LEVEL_HIGH &&
- altera_gc->interrupt_trigger == IRQ_TYPE_LEVEL_HIGH)
- return 0;
- if (type == IRQ_TYPE_EDGE_RISING &&
- altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_RISING)
- return 0;
- if (type == IRQ_TYPE_EDGE_FALLING &&
- altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_FALLING)
- return 0;
- if (type == IRQ_TYPE_EDGE_BOTH &&
- altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_BOTH)
+ }
+ if (type == altera_gc->interrupt_trigger) {
+ if (type == IRQ_TYPE_LEVEL_HIGH)
+ irq_set_handler_locked(d, handle_level_irq);
+ else
+ irq_set_handler_locked(d, handle_simple_irq);
return 0;
-
+ }
+ irq_set_handler_locked(d, handle_bad_irq);
return -EINVAL;
}
@@ -234,7 +231,6 @@ static void altera_gpio_irq_edge_handler
chained_irq_exit(chip, desc);
}
-
static void altera_gpio_irq_leveL_high_handler(struct irq_desc *desc)
{
struct altera_gpio_chip *altera_gc;
@@ -314,7 +310,7 @@ static int altera_gpio_probe(struct plat
altera_gc->interrupt_trigger = reg;
ret = gpiochip_irqchip_add(&altera_gc->mmchip.gc, &altera_irq_chip, 0,
- handle_simple_irq, IRQ_TYPE_NONE);
+ handle_bad_irq, IRQ_TYPE_NONE);
if (ret) {
dev_info(&pdev->dev, "could not add irqchip\n");
Patches currently in stable-queue which might be from preid(a)electromag.com.au are
queue-4.4/gpio-altera-use-handle_level_irq-when-configured-as-a-level_high.patch
This is a note to let you know that I've just added the patch titled
HID: chicony: Add support for another ASUS Zen AiO keyboard
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:
hid-chicony-add-support-for-another-asus-zen-aio-keyboard.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 Tue Dec 12 13:38:50 CET 2017
From: Daniel Drake <drake(a)endlessm.com>
Date: Fri, 17 Feb 2017 07:40:52 -0600
Subject: HID: chicony: Add support for another ASUS Zen AiO keyboard
From: Daniel Drake <drake(a)endlessm.com>
[ Upstream commit f2f10b7e722a75c6d75a7f7cd06b0eee3ae20f7c ]
Add support for media keys on the keyboard that comes with the
Asus V221ID and ZN241IC All In One computers.
The keys to support here are WLAN, BRIGHTNESSDOWN and BRIGHTNESSUP.
This device is not visibly branded as Chicony, and the USB Vendor ID
suggests that it is a JESS device. However this seems like the right place
to put it: the usage codes are identical to the currently supported
devices, and this driver already supports the ASUS AIO keyboard AK1D.
Signed-off-by: Daniel Drake <drake(a)endlessm.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/Kconfig | 4 ++--
drivers/hid/hid-chicony.c | 1 +
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 1 +
4 files changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -165,11 +165,11 @@ config HID_CHERRY
Support for Cherry Cymotion keyboard.
config HID_CHICONY
- tristate "Chicony Tactical pad"
+ tristate "Chicony devices"
depends on HID
default !EXPERT
---help---
- Support for Chicony Tactical pad.
+ Support for Chicony Tactical pad and special keys on Chicony keyboards.
config HID_CORSAIR
tristate "Corsair devices"
--- a/drivers/hid/hid-chicony.c
+++ b/drivers/hid/hid-chicony.c
@@ -86,6 +86,7 @@ static const struct hid_device_id ch_dev
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_WIRELESS2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_AK1D) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_ACER_SWITCH12) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_JESS_ZEN_AIO_KBD) },
{ }
};
MODULE_DEVICE_TABLE(hid, ch_devices);
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1867,6 +1867,7 @@ static const struct hid_device_id hid_ha
{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A081) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A0C2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HUION, USB_DEVICE_ID_HUION_TABLET) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_JESS_ZEN_AIO_KBD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_JESS2, USB_DEVICE_ID_JESS2_COLOR_RUMBLE_PAD) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ION, USB_DEVICE_ID_ICADE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KENSINGTON, USB_DEVICE_ID_KS_SLIMBLADE) },
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -523,6 +523,7 @@
#define USB_VENDOR_ID_JESS 0x0c45
#define USB_DEVICE_ID_JESS_YUREX 0x1010
+#define USB_DEVICE_ID_JESS_ZEN_AIO_KBD 0x5112
#define USB_VENDOR_ID_JESS2 0x0f30
#define USB_DEVICE_ID_JESS2_COLOR_RUMBLE_PAD 0x0111
Patches currently in stable-queue which might be from drake(a)endlessm.com are
queue-4.4/hid-chicony-add-support-for-another-asus-zen-aio-keyboard.patch
This is a note to let you know that I've just added the patch titled
dynamic-debug-howto: fix optional/omitted ending line number to be LARGE instead of 0
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:
dynamic-debug-howto-fix-optional-omitted-ending-line-number-to-be-large-instead-of-0.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 Tue Dec 12 13:38:50 CET 2017
From: Randy Dunlap <rdunlap(a)infradead.org>
Date: Fri, 17 Nov 2017 15:27:35 -0800
Subject: dynamic-debug-howto: fix optional/omitted ending line number to be LARGE instead of 0
From: Randy Dunlap <rdunlap(a)infradead.org>
[ Upstream commit 1f3c790bd5989fcfec9e53ad8fa09f5b740c958f ]
line-range is supposed to treat "1-" as "1-endoffile", so
handle the special case by setting last_lineno to UINT_MAX.
Fixes this error:
dynamic_debug:ddebug_parse_query: last-line:0 < 1st-line:1
dynamic_debug:ddebug_exec_query: query parse failed
Link: http://lkml.kernel.org/r/10a6a101-e2be-209f-1f41-54637824788e@infradead.org
Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
Acked-by: Jason Baron <jbaron(a)akamai.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/dynamic_debug.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -353,6 +353,10 @@ static int ddebug_parse_query(char *word
if (parse_lineno(last, &query->last_lineno) < 0)
return -EINVAL;
+ /* special case for last lineno not specified */
+ if (query->last_lineno == 0)
+ query->last_lineno = UINT_MAX;
+
if (query->last_lineno < query->first_lineno) {
pr_err("last-line:%d < 1st-line:%d\n",
query->last_lineno,
Patches currently in stable-queue which might be from rdunlap(a)infradead.org are
queue-4.4/dynamic-debug-howto-fix-optional-omitted-ending-line-number-to-be-large-instead-of-0.patch
This is a note to let you know that I've just added the patch titled
crypto: s5p-sss - Fix completing crypto request in IRQ handler
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:
crypto-s5p-sss-fix-completing-crypto-request-in-irq-handler.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 Tue Dec 12 13:38:50 CET 2017
From: Krzysztof Kozlowski <krzk(a)kernel.org>
Date: Sun, 5 Mar 2017 19:14:07 +0200
Subject: crypto: s5p-sss - Fix completing crypto request in IRQ handler
From: Krzysztof Kozlowski <krzk(a)kernel.org>
[ Upstream commit 07de4bc88ce6a4d898cad9aa4c99c1df7e87702d ]
In a regular interrupt handler driver was finishing the crypt/decrypt
request by calling complete on crypto request. This is disallowed since
converting to skcipher in commit b286d8b1a690 ("crypto: skcipher - Add
skcipher walk interface") and causes a warning:
WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430 skcipher_walk_first+0x13c/0x14c
The interrupt is marked shared but in fact there are no other users
sharing it. Thus the simplest solution seems to be to just use a
threaded interrupt handler, after converting it to oneshot.
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/s5p-sss.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -664,8 +664,9 @@ static int s5p_aes_probe(struct platform
dev_warn(dev, "feed control interrupt is not available.\n");
goto err_irq;
}
- err = devm_request_irq(dev, pdata->irq_fc, s5p_aes_interrupt,
- IRQF_SHARED, pdev->name, pdev);
+ err = devm_request_threaded_irq(dev, pdata->irq_fc, NULL,
+ s5p_aes_interrupt, IRQF_ONESHOT,
+ pdev->name, pdev);
if (err < 0) {
dev_warn(dev, "feed control interrupt is not available.\n");
goto err_irq;
Patches currently in stable-queue which might be from krzk(a)kernel.org are
queue-4.4/crypto-s5p-sss-fix-completing-crypto-request-in-irq-handler.patch
This is a note to let you know that I've just added the patch titled
bnx2x: prevent crash when accessing PTP with interface down
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:
bnx2x-prevent-crash-when-accessing-ptp-with-interface-down.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 Tue Dec 12 13:38:50 CET 2017
From: Michal Schmidt <mschmidt(a)redhat.com>
Date: Fri, 3 Mar 2017 17:08:28 +0100
Subject: bnx2x: prevent crash when accessing PTP with interface down
From: Michal Schmidt <mschmidt(a)redhat.com>
[ Upstream commit 466e8bf10ac104d96e1ea813e8126e11cb72ea20 ]
It is possible to crash the kernel by accessing a PTP device while its
associated bnx2x interface is down. Before the interface is brought up,
the timecounter is not initialized, so accessing it results in NULL
dereference.
Fix it by checking if the interface is up.
Use -ENETDOWN as the error code when the interface is down.
-EFAULT in bnx2x_ptp_adjfreq() did not seem right.
Tested using phc_ctl get/set/adj/freq commands.
Signed-off-by: Michal Schmidt <mschmidt(a)redhat.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/broadcom/bnx2x/bnx2x_main.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13646,7 +13646,7 @@ static int bnx2x_ptp_adjfreq(struct ptp_
if (!netif_running(bp->dev)) {
DP(BNX2X_MSG_PTP,
"PTP adjfreq called while the interface is down\n");
- return -EFAULT;
+ return -ENETDOWN;
}
if (ppb < 0) {
@@ -13705,6 +13705,12 @@ static int bnx2x_ptp_adjtime(struct ptp_
{
struct bnx2x *bp = container_of(ptp, struct bnx2x, ptp_clock_info);
+ if (!netif_running(bp->dev)) {
+ DP(BNX2X_MSG_PTP,
+ "PTP adjtime called while the interface is down\n");
+ return -ENETDOWN;
+ }
+
DP(BNX2X_MSG_PTP, "PTP adjtime called, delta = %llx\n", delta);
timecounter_adjtime(&bp->timecounter, delta);
@@ -13717,6 +13723,12 @@ static int bnx2x_ptp_gettime(struct ptp_
struct bnx2x *bp = container_of(ptp, struct bnx2x, ptp_clock_info);
u64 ns;
+ if (!netif_running(bp->dev)) {
+ DP(BNX2X_MSG_PTP,
+ "PTP gettime called while the interface is down\n");
+ return -ENETDOWN;
+ }
+
ns = timecounter_read(&bp->timecounter);
DP(BNX2X_MSG_PTP, "PTP gettime called, ns = %llu\n", ns);
@@ -13732,6 +13744,12 @@ static int bnx2x_ptp_settime(struct ptp_
struct bnx2x *bp = container_of(ptp, struct bnx2x, ptp_clock_info);
u64 ns;
+ if (!netif_running(bp->dev)) {
+ DP(BNX2X_MSG_PTP,
+ "PTP settime called while the interface is down\n");
+ return -ENETDOWN;
+ }
+
ns = timespec64_to_ns(ts);
DP(BNX2X_MSG_PTP, "PTP settime called, ns = %llu\n", ns);
Patches currently in stable-queue which might be from mschmidt(a)redhat.com are
queue-4.4/bnx2x-fix-possible-overrun-of-vfpf-multicast-addresses-array.patch
queue-4.4/bnx2x-do-not-rollback-vf-mac-vlan-filters-we-did-not-configure.patch
queue-4.4/bnx2x-prevent-crash-when-accessing-ptp-with-interface-down.patch
This is a note to let you know that I've just added the patch titled
drm/amd/amdgpu: fix console deadlock if late init failed
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:
drm-amd-amdgpu-fix-console-deadlock-if-late-init-failed.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 Tue Dec 12 13:38:50 CET 2017
From: Jim Qu <Jim.Qu(a)amd.com>
Date: Wed, 1 Mar 2017 15:53:29 +0800
Subject: drm/amd/amdgpu: fix console deadlock if late init failed
From: Jim Qu <Jim.Qu(a)amd.com>
[ Upstream commit c085bd5119d5d0bdf3ef591a5563566be7dedced ]
Signed-off-by: Jim Qu <Jim.Qu(a)amd.com>
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1760,8 +1760,11 @@ int amdgpu_resume_kms(struct drm_device
}
r = amdgpu_late_init(adev);
- if (r)
+ if (r) {
+ if (fbcon)
+ console_unlock();
return r;
+ }
/* pin cursors */
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
Patches currently in stable-queue which might be from Jim.Qu(a)amd.com are
queue-4.4/drm-amd-amdgpu-fix-console-deadlock-if-late-init-failed.patch