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.9-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.9 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 09:02:40 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
@@ -166,7 +166,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.9/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: ipv6: send NS for DAD when link operationally up
to the 4.9-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-ipv6-send-ns-for-dad-when-link-operationally-up.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Mike Manning <mmanning(a)brocade.com>
Date: Mon, 25 Sep 2017 22:01:36 +0100
Subject: net: ipv6: send NS for DAD when link operationally up
From: Mike Manning <mmanning(a)brocade.com>
[ Upstream commit 1f372c7bfb23286d2bf4ce0423ab488e86b74bb2 ]
The NS for DAD are sent on admin up as long as a valid qdisc is found.
A race condition exists by which these packets will not egress the
interface if the operational state of the lower device is not yet up.
The solution is to delay DAD until the link is operationally up
according to RFC2863. Rather than only doing this, follow the existing
code checks by deferring IPv6 device initialization altogether. The fix
allows DAD on devices like tunnels that are controlled by userspace
control plane. The fix has no impact on regular deployments, but means
that there is no IPv6 connectivity until the port has been opened in
the case of port-based network access control, which should be
desirable.
Signed-off-by: Mike Manning <mmanning(a)brocade.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/addrconf.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -286,10 +286,10 @@ static struct ipv6_devconf ipv6_devconf_
.keep_addr_on_down = 0,
};
-/* Check if a valid qdisc is available */
-static inline bool addrconf_qdisc_ok(const struct net_device *dev)
+/* Check if link is ready: is it up and is a valid qdisc available */
+static inline bool addrconf_link_ready(const struct net_device *dev)
{
- return !qdisc_tx_is_noop(dev);
+ return netif_oper_up(dev) && !qdisc_tx_is_noop(dev);
}
static void addrconf_del_rs_timer(struct inet6_dev *idev)
@@ -434,7 +434,7 @@ static struct inet6_dev *ipv6_add_dev(st
ndev->token = in6addr_any;
- if (netif_running(dev) && addrconf_qdisc_ok(dev))
+ if (netif_running(dev) && addrconf_link_ready(dev))
ndev->if_flags |= IF_READY;
ipv6_mc_init_dev(ndev);
@@ -3368,7 +3368,7 @@ static int addrconf_notify(struct notifi
/* restore routes for permanent addresses */
addrconf_permanent_addr(dev);
- if (!addrconf_qdisc_ok(dev)) {
+ if (!addrconf_link_ready(dev)) {
/* device is not ready yet. */
pr_info("ADDRCONF(NETDEV_UP): %s: link is not ready\n",
dev->name);
@@ -3383,7 +3383,7 @@ static int addrconf_notify(struct notifi
run_pending = 1;
}
} else if (event == NETDEV_CHANGE) {
- if (!addrconf_qdisc_ok(dev)) {
+ if (!addrconf_link_ready(dev)) {
/* device is still not ready. */
break;
}
Patches currently in stable-queue which might be from mmanning(a)brocade.com are
queue-4.9/net-ipv6-send-ns-for-dad-when-link-operationally-up.patch
This is a note to let you know that I've just added the patch titled
net: ipconfig: fix ic_close_devs() use-after-free
to the 4.9-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-ipconfig-fix-ic_close_devs-use-after-free.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Mark Rutland <mark.rutland(a)arm.com>
Date: Mon, 27 Mar 2017 18:00:14 +0100
Subject: net: ipconfig: fix ic_close_devs() use-after-free
From: Mark Rutland <mark.rutland(a)arm.com>
[ Upstream commit ffefb6f4d6ad699a2b5484241bc46745a53235d0 ]
Our chosen ic_dev may be anywhere in our list of ic_devs, and we may
free it before attempting to close others. When we compare d->dev and
ic_dev->dev, we're potentially dereferencing memory returned to the
allocator. This causes KASAN to scream for each subsequent ic_dev we
check.
As there's a 1-1 mapping between ic_devs and netdevs, we can instead
compare d and ic_dev directly, which implicitly handles the !ic_dev
case, and avoids the use-after-free. The ic_dev pointer may be stale,
but we will not dereference it.
Original splat:
[ 6.487446] ==================================================================
[ 6.494693] BUG: KASAN: use-after-free in ic_close_devs+0xc4/0x154 at addr ffff800367efa708
[ 6.503013] Read of size 8 by task swapper/0/1
[ 6.507452] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc3-00002-gda42158 #8
[ 6.514993] Hardware name: AppliedMicro Mustang/Mustang, BIOS 3.05.05-beta_rc Jan 27 2016
[ 6.523138] Call trace:
[ 6.525590] [<ffff200008094778>] dump_backtrace+0x0/0x570
[ 6.530976] [<ffff200008094d08>] show_stack+0x20/0x30
[ 6.536017] [<ffff200008bee928>] dump_stack+0x120/0x188
[ 6.541231] [<ffff20000856d5e4>] kasan_object_err+0x24/0xa0
[ 6.546790] [<ffff20000856d924>] kasan_report_error+0x244/0x738
[ 6.552695] [<ffff20000856dfec>] __asan_report_load8_noabort+0x54/0x80
[ 6.559204] [<ffff20000aae86ac>] ic_close_devs+0xc4/0x154
[ 6.564590] [<ffff20000aaedbac>] ip_auto_config+0x2ed4/0x2f1c
[ 6.570321] [<ffff200008084b04>] do_one_initcall+0xcc/0x370
[ 6.575882] [<ffff20000aa31de8>] kernel_init_freeable+0x5f8/0x6c4
[ 6.581959] [<ffff20000a16df00>] kernel_init+0x18/0x190
[ 6.587171] [<ffff200008084710>] ret_from_fork+0x10/0x40
[ 6.592468] Object at ffff800367efa700, in cache kmalloc-128 size: 128
[ 6.598969] Allocated:
[ 6.601324] PID = 1
[ 6.603427] save_stack_trace_tsk+0x0/0x418
[ 6.607603] save_stack_trace+0x20/0x30
[ 6.611430] kasan_kmalloc+0xd8/0x188
[ 6.615087] ip_auto_config+0x8c4/0x2f1c
[ 6.619002] do_one_initcall+0xcc/0x370
[ 6.622832] kernel_init_freeable+0x5f8/0x6c4
[ 6.627178] kernel_init+0x18/0x190
[ 6.630660] ret_from_fork+0x10/0x40
[ 6.634223] Freed:
[ 6.636233] PID = 1
[ 6.638334] save_stack_trace_tsk+0x0/0x418
[ 6.642510] save_stack_trace+0x20/0x30
[ 6.646337] kasan_slab_free+0x88/0x178
[ 6.650167] kfree+0xb8/0x478
[ 6.653131] ic_close_devs+0x130/0x154
[ 6.656875] ip_auto_config+0x2ed4/0x2f1c
[ 6.660875] do_one_initcall+0xcc/0x370
[ 6.664705] kernel_init_freeable+0x5f8/0x6c4
[ 6.669051] kernel_init+0x18/0x190
[ 6.672534] ret_from_fork+0x10/0x40
[ 6.676098] Memory state around the buggy address:
[ 6.680880] ffff800367efa600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 6.688078] ffff800367efa680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 6.695276] >ffff800367efa700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 6.702469] ^
[ 6.705952] ffff800367efa780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 6.713149] ffff800367efa800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 6.720343] ==================================================================
[ 6.727536] Disabling lock debugging due to kernel taint
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Cc: Alexey Kuznetsov <kuznet(a)ms2.inr.ac.ru>
Cc: David S. Miller <davem(a)davemloft.net>
Cc: Hideaki YOSHIFUJI <yoshfuji(a)linux-ipv6.org>
Cc: James Morris <jmorris(a)namei.org>
Cc: Patrick McHardy <kaber(a)trash.net>
Cc: netdev(a)vger.kernel.org
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/ipv4/ipconfig.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -306,7 +306,7 @@ static void __init ic_close_devs(void)
while ((d = next)) {
next = d->next;
dev = d->dev;
- if ((!ic_dev || dev != ic_dev->dev) && !netdev_uses_dsa(dev)) {
+ if (d != ic_dev && !netdev_uses_dsa(dev)) {
pr_debug("IP-Config: Downing %s\n", dev->name);
dev_change_flags(dev, d->flags);
}
Patches currently in stable-queue which might be from mark.rutland(a)arm.com are
queue-4.9/net-ipconfig-fix-ic_close_devs-use-after-free.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.9-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.9 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 09:02:40 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
@@ -369,14 +369,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.9/i40e-do-not-enable-napi-on-q_vectors-that-have-no-rings.patch
queue-4.9/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
nbd: set queue timeout properly
to the 4.9-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:
nbd-set-queue-timeout-properly.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Josef Bacik <jbacik(a)fb.com>
Date: Fri, 24 Mar 2017 14:08:28 -0400
Subject: nbd: set queue timeout properly
From: Josef Bacik <jbacik(a)fb.com>
[ Upstream commit f8586855031a1d6b243f013c3082631346fddfad ]
We can't just set the timeout on the tagset, we have to set it on the
queue as it would have been setup already at this point.
Signed-off-by: Josef Bacik <jbacik(a)fb.com>
Signed-off-by: Jens Axboe <axboe(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/nbd.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -654,7 +654,10 @@ static int __nbd_ioctl(struct block_devi
return nbd_size_set(nbd, bdev, nbd->blksize, arg);
case NBD_SET_TIMEOUT:
- nbd->tag_set.timeout = arg * HZ;
+ if (arg) {
+ nbd->tag_set.timeout = arg * HZ;
+ blk_queue_rq_timeout(nbd->disk->queue, arg * HZ);
+ }
return 0;
case NBD_SET_FLAGS:
Patches currently in stable-queue which might be from jbacik(a)fb.com are
queue-4.9/nbd-set-queue-timeout-properly.patch
This is a note to let you know that I've just added the patch titled
mm, x86/mm: Make the batched unmap TLB flush API more generic
to the 4.9-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-x86-mm-make-the-batched-unmap-tlb-flush-api-more-generic.patch
and it can be found in the queue-4.9 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 e73ad5ff2f76da25390e9607cb549691639330c3 Mon Sep 17 00:00:00 2001
From: Andy Lutomirski <luto(a)kernel.org>
Date: Mon, 22 May 2017 15:30:03 -0700
Subject: mm, x86/mm: Make the batched unmap TLB flush API more generic
From: Andy Lutomirski <luto(a)kernel.org>
commit e73ad5ff2f76da25390e9607cb549691639330c3 upstream.
try_to_unmap_flush() used to open-code a rather x86-centric flush
sequence: local_flush_tlb() + flush_tlb_others(). Rearrange the
code so that the arch (only x86 for now) provides
arch_tlbbatch_add_mm() and arch_tlbbatch_flush() and the core code
calls those functions instead.
I'll want this for x86 because, to enable address space ids, I can't
support the flush_tlb_others() mode used by exising
try_to_unmap_flush() implementation with good performance. I can
support the new API fairly easily, though.
I imagine that other architectures may be in a similar position.
Architectures with strong remote flush primitives (arm64?) may have
even worse performance problems with flush_tlb_others() the way that
try_to_unmap_flush() uses it.
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Acked-by: Kees Cook <keescook(a)chromium.org>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Borislav Petkov <bpetkov(a)suse.de>
Cc: Dave Hansen <dave.hansen(a)intel.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Mel Gorman <mgorman(a)suse.de>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Nadav Amit <nadav.amit(a)gmail.com>
Cc: Nadav Amit <namit(a)vmware.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Sasha Levin <sasha.levin(a)oracle.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-mm(a)kvack.org
Link: http://lkml.kernel.org/r/19f25a8581f9fb77876b7ff3b001f89835e34ea3.149549206…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Eduardo Valentin <eduval(a)amazon.com>
Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/tlbbatch.h | 16 ++++++++++++++++
arch/x86/include/asm/tlbflush.h | 8 ++++++++
arch/x86/mm/tlb.c | 17 +++++++++++++++++
include/linux/sched.h | 15 +++++++++++----
mm/rmap.c | 16 ++--------------
5 files changed, 54 insertions(+), 18 deletions(-)
create mode 100644 arch/x86/include/asm/tlbbatch.h
--- /dev/null
+++ b/arch/x86/include/asm/tlbbatch.h
@@ -0,0 +1,16 @@
+#ifndef _ARCH_X86_TLBBATCH_H
+#define _ARCH_X86_TLBBATCH_H
+
+#include <linux/cpumask.h>
+
+#ifdef CONFIG_SMP
+struct arch_tlbflush_unmap_batch {
+ /*
+ * Each bit set is a CPU that potentially has a TLB entry for one of
+ * the PFNs being flushed..
+ */
+ struct cpumask cpumask;
+};
+#endif
+
+#endif /* _ARCH_X86_TLBBATCH_H */
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -327,6 +327,14 @@ static inline void reset_lazy_tlbstate(v
this_cpu_write(cpu_tlbstate.active_mm, &init_mm);
}
+static inline void arch_tlbbatch_add_mm(struct arch_tlbflush_unmap_batch *batch,
+ struct mm_struct *mm)
+{
+ cpumask_or(&batch->cpumask, &batch->cpumask, mm_cpumask(mm));
+}
+
+extern void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch);
+
#endif /* SMP */
#ifndef CONFIG_PARAVIRT
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -410,6 +410,23 @@ void flush_tlb_kernel_range(unsigned lon
}
}
+void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch)
+{
+ int cpu = get_cpu();
+
+ if (cpumask_test_cpu(cpu, &batch->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(&batch->cpumask, cpu) < nr_cpu_ids)
+ flush_tlb_others(&batch->cpumask, NULL, 0, TLB_FLUSH_ALL);
+ cpumask_clear(&batch->cpumask);
+
+ put_cpu();
+}
+
static ssize_t tlbflush_read_file(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1463,15 +1463,22 @@ enum perf_event_task_context {
perf_nr_task_contexts,
};
+#ifdef CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
+#include <asm/tlbbatch.h>
+#endif
+
/* Track pages that require TLB flushes */
struct tlbflush_unmap_batch {
/*
- * Each bit set is a CPU that potentially has a TLB entry for one of
- * the PFNs being flushed. See set_tlb_ubc_flush_pending().
+ * The arch code makes the following promise: generic code can modify a
+ * PTE, then call arch_tlbbatch_add_mm() (which internally provides all
+ * needed barriers), then call arch_tlbbatch_flush(), and the entries
+ * will be flushed on all CPUs by the time that arch_tlbbatch_flush()
+ * returns.
*/
- struct cpumask cpumask;
+ struct arch_tlbflush_unmap_batch arch;
- /* True if any bit in cpumask is set */
+ /* True if a flush is needed. */
bool flush_required;
/*
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -578,25 +578,13 @@ void page_unlock_anon_vma_read(struct an
void try_to_unmap_flush(void)
{
struct tlbflush_unmap_batch *tlb_ubc = ¤t->tlb_ubc;
- int cpu;
if (!tlb_ubc->flush_required)
return;
- cpu = get_cpu();
-
- 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);
+ arch_tlbbatch_flush(&tlb_ubc->arch);
tlb_ubc->flush_required = false;
tlb_ubc->writable = false;
- put_cpu();
}
/* Flush iff there are potentially writable TLB entries that can race with IO */
@@ -613,7 +601,7 @@ static void set_tlb_ubc_flush_pending(st
{
struct tlbflush_unmap_batch *tlb_ubc = ¤t->tlb_ubc;
- cpumask_or(&tlb_ubc->cpumask, &tlb_ubc->cpumask, mm_cpumask(mm));
+ arch_tlbbatch_add_mm(&tlb_ubc->arch, mm);
tlb_ubc->flush_required = true;
/*
Patches currently in stable-queue which might be from luto(a)kernel.org are
queue-4.9/x86-mm-refactor-flush_tlb_mm_range-to-merge-local-and-remote-cases.patch
queue-4.9/x86-mm-pass-flush_tlb_info-to-flush_tlb_others-etc.patch
queue-4.9/x86-mm-rework-lazy-tlb-to-track-the-actual-loaded-mm.patch
queue-4.9/x86-mm-kvm-teach-kvm-s-vmx-code-that-cr3-isn-t-a-constant.patch
queue-4.9/x86-mm-use-new-merged-flush-logic-in-arch_tlbbatch_flush.patch
queue-4.9/x86-kvm-vmx-simplify-segment_base.patch
queue-4.9/x86-entry-unwind-create-stack-frames-for-saved-interrupt-registers.patch
queue-4.9/x86-mm-reduce-indentation-in-flush_tlb_func.patch
queue-4.9/x86-mm-remove-the-up-asm-tlbflush.h-code-always-use-the-formerly-smp-code.patch
queue-4.9/x86-mm-reimplement-flush_tlb_page-using-flush_tlb_mm_range.patch
queue-4.9/mm-x86-mm-make-the-batched-unmap-tlb-flush-api-more-generic.patch
queue-4.9/x86-kvm-vmx-defer-tr-reload-after-vm-exit.patch
queue-4.9/x86-mm-change-the-leave_mm-condition-for-local-tlb-flushes.patch
queue-4.9/x86-mm-be-more-consistent-wrt-page_shift-vs-page_size-in-tlb-flush-code.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.9-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.9 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 09:02:40 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
@@ -8443,11 +8443,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.9/kvm-x86-correct-async-page-present-tracepoint.patch
queue-4.9/kvm-vmx-fix-enable-vpid-conditions.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.9-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.9 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 09:02:40 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
@@ -1201,6 +1201,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 &
@@ -6445,8 +6450,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.9/kvm-x86-correct-async-page-present-tracepoint.patch
queue-4.9/kvm-vmx-fix-enable-vpid-conditions.patch
This is a note to let you know that I've just added the patch titled
kvm: vmx: Flush TLB when the APIC-access address changes
to the 4.9-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-flush-tlb-when-the-apic-access-address-changes.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Jim Mattson <jmattson(a)google.com>
Date: Thu, 16 Mar 2017 13:53:59 -0700
Subject: kvm: vmx: Flush TLB when the APIC-access address changes
From: Jim Mattson <jmattson(a)google.com>
[ Upstream commit fb6c8198431311027c3434d4e94ab8bc040f7aea ]
Quoting from the Intel SDM, volume 3, section 28.3.3.4: Guidelines for
Use of the INVEPT Instruction:
If EPT was in use on a logical processor at one time with EPTP X, it
is recommended that software use the INVEPT instruction with the
"single-context" INVEPT type and with EPTP X in the INVEPT descriptor
before a VM entry on the same logical processor that enables EPT with
EPTP X and either (a) the "virtualize APIC accesses" VM-execution
control was changed from 0 to 1; or (b) the value of the APIC-access
address was changed.
In the nested case, the burden falls on L1, unless L0 enables EPT in
vmcs02 when L1 doesn't enable EPT in vmcs12.
Signed-off-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 | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3818,6 +3818,12 @@ static void vmx_flush_tlb(struct kvm_vcp
__vmx_flush_tlb(vcpu, to_vmx(vcpu)->vpid);
}
+static void vmx_flush_tlb_ept_only(struct kvm_vcpu *vcpu)
+{
+ if (enable_ept)
+ vmx_flush_tlb(vcpu);
+}
+
static void vmx_decache_cr0_guest_bits(struct kvm_vcpu *vcpu)
{
ulong cr0_guest_owned_bits = vcpu->arch.cr0_guest_owned_bits;
@@ -8505,6 +8511,7 @@ static void vmx_set_virtual_x2apic_mode(
} else {
sec_exec_control &= ~SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE;
sec_exec_control |= SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
+ vmx_flush_tlb_ept_only(vcpu);
}
vmcs_write32(SECONDARY_VM_EXEC_CONTROL, sec_exec_control);
@@ -8530,8 +8537,10 @@ static void vmx_set_apic_access_page_add
*/
if (!is_guest_mode(vcpu) ||
!nested_cpu_has2(get_vmcs12(&vmx->vcpu),
- SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES))
+ SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES)) {
vmcs_write64(APIC_ACCESS_ADDR, hpa);
+ vmx_flush_tlb_ept_only(vcpu);
+ }
}
static void vmx_hwapic_isr_update(struct kvm_vcpu *vcpu, int max_isr)
@@ -10110,6 +10119,9 @@ static void prepare_vmcs02(struct kvm_vc
if (nested_cpu_has_ept(vmcs12)) {
kvm_mmu_unload(vcpu);
nested_ept_init_mmu_context(vcpu);
+ } else if (nested_cpu_has2(vmcs12,
+ SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES)) {
+ vmx_flush_tlb_ept_only(vcpu);
}
if (vmcs12->vm_entry_controls & VM_ENTRY_LOAD_IA32_EFER)
@@ -10850,6 +10862,10 @@ static void nested_vmx_vmexit(struct kvm
vmx->nested.change_vmcs01_virtual_x2apic_mode = false;
vmx_set_virtual_x2apic_mode(vcpu,
vcpu->arch.apic_base & X2APIC_ENABLE);
+ } else if (!nested_cpu_has_ept(vmcs12) &&
+ nested_cpu_has2(vmcs12,
+ SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES)) {
+ vmx_flush_tlb_ept_only(vcpu);
}
/* This is needed for same reason as it was needed in prepare_vmcs02 */
Patches currently in stable-queue which might be from jmattson(a)google.com are
queue-4.9/x86-kvm-vmx-simplify-segment_base.patch
queue-4.9/kvm-vmx-flush-tlb-when-the-apic-access-address-changes.patch
queue-4.9/kvm-vmx-fix-enable-vpid-conditions.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.9-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.9 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 09:02:40 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
@@ -1060,7 +1060,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.9/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
KVM: nVMX: fix HOST_CR3/HOST_CR4 cache
to the 4.9-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-fix-host_cr3-host_cr4-cache.patch
and it can be found in the queue-4.9 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 44889942b6eb356eab27ce25fe10701adfec7776 Mon Sep 17 00:00:00 2001
From: Ladi Prosek <lprosek(a)redhat.com>
Date: Fri, 22 Sep 2017 07:53:15 +0200
Subject: KVM: nVMX: fix HOST_CR3/HOST_CR4 cache
From: Ladi Prosek <lprosek(a)redhat.com>
commit 44889942b6eb356eab27ce25fe10701adfec7776 upstream.
For nested virt we maintain multiple VMCS that can run on a vCPU. So it is
incorrect to keep vmcs_host_cr3 and vmcs_host_cr4, whose purpose is caching
the value of the rarely changing HOST_CR3 and HOST_CR4 VMCS fields, in
vCPU-wide data structures.
Hyper-V nested on KVM runs into this consistently for me with PCID enabled.
CR3 is updated with a new value, unlikely(cr3 != vmx->host_state.vmcs_host_cr3)
fires, and the currently loaded VMCS is updated. Then we switch from L2 to
L1 and the next exit reverts CR3 to its old value.
Fixes: d6e41f1151fe ("x86/mm, KVM: Teach KVM's VMX code that CR3 isn't a constant")
Signed-off-by: Ladi Prosek <lprosek(a)redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -191,6 +191,8 @@ struct loaded_vmcs {
struct vmcs *shadow_vmcs;
int cpu;
int launched;
+ unsigned long vmcs_host_cr3; /* May not match real cr3 */
+ unsigned long vmcs_host_cr4; /* May not match real cr4 */
struct list_head loaded_vmcss_on_cpu_link;
};
@@ -573,8 +575,6 @@ struct vcpu_vmx {
int gs_ldt_reload_needed;
int fs_reload_needed;
u64 msr_host_bndcfgs;
- unsigned long vmcs_host_cr3; /* May not match real cr3 */
- unsigned long vmcs_host_cr4; /* May not match real cr4 */
} host_state;
struct {
int vm86_active;
@@ -4871,12 +4871,12 @@ static void vmx_set_constant_host_state(
*/
cr3 = read_cr3();
vmcs_writel(HOST_CR3, cr3); /* 22.2.3 FIXME: shadow tables */
- vmx->host_state.vmcs_host_cr3 = cr3;
+ vmx->loaded_vmcs->vmcs_host_cr3 = cr3;
/* Save the most likely value for this task's CR4 in the VMCS. */
cr4 = cr4_read_shadow();
vmcs_writel(HOST_CR4, cr4); /* 22.2.3, 22.2.5 */
- vmx->host_state.vmcs_host_cr4 = cr4;
+ vmx->loaded_vmcs->vmcs_host_cr4 = cr4;
vmcs_write16(HOST_CS_SELECTOR, __KERNEL_CS); /* 22.2.4 */
#ifdef CONFIG_X86_64
@@ -8874,15 +8874,15 @@ static void __noclone vmx_vcpu_run(struc
vmcs_writel(GUEST_RIP, vcpu->arch.regs[VCPU_REGS_RIP]);
cr3 = __get_current_cr3_fast();
- if (unlikely(cr3 != vmx->host_state.vmcs_host_cr3)) {
+ if (unlikely(cr3 != vmx->loaded_vmcs->vmcs_host_cr3)) {
vmcs_writel(HOST_CR3, cr3);
- vmx->host_state.vmcs_host_cr3 = cr3;
+ vmx->loaded_vmcs->vmcs_host_cr3 = cr3;
}
cr4 = cr4_read_shadow();
- if (unlikely(cr4 != vmx->host_state.vmcs_host_cr4)) {
+ if (unlikely(cr4 != vmx->loaded_vmcs->vmcs_host_cr4)) {
vmcs_writel(HOST_CR4, cr4);
- vmx->host_state.vmcs_host_cr4 = cr4;
+ vmx->loaded_vmcs->vmcs_host_cr4 = cr4;
}
/* When single-stepping over STI and MOV SS, we must clear the
Patches currently in stable-queue which might be from lprosek(a)redhat.com are
queue-4.9/kvm-nvmx-fix-host_cr3-host_cr4-cache.patch
queue-4.9/virtio-balloon-use-actual-number-of-stats-for-stats-queue-buffers.patch
queue-4.9/virtio_balloon-prevent-uninitialized-variable-use.patch
This is a note to let you know that I've just added the patch titled
kvm, mm: account kvm related kmem slabs to kmemcg
to the 4.9-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-mm-account-kvm-related-kmem-slabs-to-kmemcg.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Shakeel Butt <shakeelb(a)google.com>
Date: Thu, 5 Oct 2017 18:07:24 -0700
Subject: kvm, mm: account kvm related kmem slabs to kmemcg
From: Shakeel Butt <shakeelb(a)google.com>
[ Upstream commit 46bea48ac241fe0b413805952dda74dd0c09ba8b ]
The kvm slabs can consume a significant amount of system memory
and indeed in our production environment we have observed that
a lot of machines are spending significant amount of memory that
can not be left as system memory overhead. Also the allocations
from these slabs can be triggered directly by user space applications
which has access to kvm and thus a buggy application can leak
such memory. So, these caches should be accounted to kmemcg.
Signed-off-by: Shakeel Butt <shakeelb(a)google.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/mmu.c | 4 ++--
virt/kvm/kvm_main.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -5052,13 +5052,13 @@ int kvm_mmu_module_init(void)
{
pte_list_desc_cache = kmem_cache_create("pte_list_desc",
sizeof(struct pte_list_desc),
- 0, 0, NULL);
+ 0, SLAB_ACCOUNT, NULL);
if (!pte_list_desc_cache)
goto nomem;
mmu_page_header_cache = kmem_cache_create("kvm_mmu_page_header",
sizeof(struct kvm_mmu_page),
- 0, 0, NULL);
+ 0, SLAB_ACCOUNT, NULL);
if (!mmu_page_header_cache)
goto nomem;
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3904,7 +3904,7 @@ int kvm_init(void *opaque, unsigned vcpu
if (!vcpu_align)
vcpu_align = __alignof__(struct kvm_vcpu);
kvm_vcpu_cache = kmem_cache_create("kvm_vcpu", vcpu_size, vcpu_align,
- 0, NULL);
+ SLAB_ACCOUNT, NULL);
if (!kvm_vcpu_cache) {
r = -ENOMEM;
goto out_free_3;
Patches currently in stable-queue which might be from shakeelb(a)google.com are
queue-4.9/kvm-mm-account-kvm-related-kmem-slabs-to-kmemcg.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.9-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.9 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 09:02:40 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
@@ -3696,10 +3696,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, &fw_cmd,
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -617,6 +617,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, &buffer,
sizeof(buffer),
Patches currently in stable-queue which might be from emil.s.tantilov(a)intel.com are
queue-4.9/ixgbe-fix-use-of-uninitialized-padding.patch
This is a note to let you know that I've just added the patch titled
kvm: fix usage of uninit spinlock in avic_vm_destroy()
to the 4.9-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-fix-usage-of-uninit-spinlock-in-avic_vm_destroy.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Tue, 24 Jan 2017 14:06:48 +0100
Subject: kvm: fix usage of uninit spinlock in avic_vm_destroy()
From: Dmitry Vyukov <dvyukov(a)google.com>
[ Upstream commit 3863dff0c3dd72984395c93b12383b393c5c3989 ]
If avic is not enabled, avic_vm_init() does nothing and returns early.
However, avic_vm_destroy() still tries to destroy what hasn't been created.
The only bad consequence of this now is that avic_vm_destroy() uses
svm_vm_data_hash_lock that hasn't been initialized (and is not meant
to be used at all if avic is not enabled).
Return early from avic_vm_destroy() if avic is not enabled.
It has nothing to destroy.
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Joerg Roedel <joro(a)8bytes.org>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: "Radim Krčmář" <rkrcmar(a)redhat.com>
Cc: David Hildenbrand <david(a)redhat.com>
Cc: kvm(a)vger.kernel.org
Cc: syzkaller(a)googlegroups.com
Reviewed-by: David Hildenbrand <david(a)redhat.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/svm.c | 3 +++
1 file changed, 3 insertions(+)
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1382,6 +1382,9 @@ static void avic_vm_destroy(struct kvm *
unsigned long flags;
struct kvm_arch *vm_data = &kvm->arch;
+ if (!avic)
+ return;
+
avic_free_vm_id(vm_data->avic_vm_id);
if (vm_data->avic_logical_id_table_page)
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-4.9/kvm-fix-usage-of-uninit-spinlock-in-avic_vm_destroy.patch
queue-4.9/inet-frag-release-spinlock-before-calling-icmp_send.patch
queue-4.9/crypto-deadlock-between-crypto_alg_sem-rtnl_mutex-genl_mutex.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.9-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.9 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 09:02:40 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.9/hwmon-asus_atk0110-fix-uninitialized-data-access.patch
queue-4.9/bna-avoid-writing-uninitialized-data-into-hw-registers.patch
queue-4.9/virtio-balloon-use-actual-number-of-stats-for-stats-queue-buffers.patch
queue-4.9/virtio_balloon-prevent-uninitialized-variable-use.patch
queue-4.9/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.9-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.9 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 09:02:40 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.9/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
iommu/exynos: Workaround FLPD cache flush issues for SYSMMU v5
to the 4.9-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:
iommu-exynos-workaround-flpd-cache-flush-issues-for-sysmmu-v5.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Marek Szyprowski <m.szyprowski(a)samsung.com>
Date: Mon, 20 Mar 2017 10:17:57 +0100
Subject: iommu/exynos: Workaround FLPD cache flush issues for SYSMMU v5
From: Marek Szyprowski <m.szyprowski(a)samsung.com>
[ Upstream commit cd37a296a9f890586665bb8974a8b17ee2f17d6d ]
For some unknown reasons, in some cases, FLPD cache invalidation doesn't
work properly with SYSMMU v5 controllers found in Exynos5433 SoCs. This
can be observed by a firmware crash during initialization phase of MFC
video decoder available in the mentioned SoCs when IOMMU support is
enabled. To workaround this issue perform a full TLB/FLPD invalidation
in case of replacing any first level page descriptors in case of SYSMMU v5.
Fixes: 740a01eee9ada ("iommu/exynos: Add support for v5 SYSMMU")
CC: stable(a)vger.kernel.org # v4.10+
Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Tested-by: Andrzej Hajda <a.hajda(a)samsung.com>
Signed-off-by: Joerg Roedel <jroedel(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iommu/exynos-iommu.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -543,7 +543,10 @@ static void sysmmu_tlb_invalidate_flpdca
if (is_sysmmu_active(data) && data->version >= MAKE_MMU_VER(3, 3)) {
clk_enable(data->clk_master);
if (sysmmu_block(data)) {
- __sysmmu_tlb_invalidate_entry(data, iova, 1);
+ if (data->version >= MAKE_MMU_VER(5, 0))
+ __sysmmu_tlb_invalidate(data);
+ else
+ __sysmmu_tlb_invalidate_entry(data, iova, 1);
sysmmu_unblock(data);
}
clk_disable(data->clk_master);
Patches currently in stable-queue which might be from m.szyprowski(a)samsung.com are
queue-4.9/iommu-exynos-workaround-flpd-cache-flush-issues-for-sysmmu-v5.patch
This is a note to let you know that I've just added the patch titled
infiniband: Fix alignment of mmap cookies to support VIPT caching
to the 4.9-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:
infiniband-fix-alignment-of-mmap-cookies-to-support-vipt-caching.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Jason Gunthorpe <jgunthorpe(a)obsidianresearch.com>
Date: Fri, 10 Mar 2017 11:34:20 -0700
Subject: infiniband: Fix alignment of mmap cookies to support VIPT caching
From: Jason Gunthorpe <jgunthorpe(a)obsidianresearch.com>
[ Upstream commit cb8864559631754ac93d5734b165ccd0cad4728c ]
When vmalloc_user is used to create memory that is supposed to be mmap'd
to user space, it is necessary for the mmap cookie (eg the offset) to be
aligned to SHMLBA.
This creates a situation where all virtual mappings of the same physical
page share the same virtual cache index and guarantees VIPT coherence.
Otherwise the cache is non-coherent and the kernel will not see writes
by userspace when reading the shared page (or vice-versa).
Reported-by: Josh Beavers <josh.beavers(a)gmail.com>
Signed-off-by: Jason Gunthorpe <jgunthorpe(a)obsidianresearch.com>
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/sw/rdmavt/mmap.c | 4 ++--
drivers/infiniband/sw/rxe/rxe_mmap.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/infiniband/sw/rdmavt/mmap.c
+++ b/drivers/infiniband/sw/rdmavt/mmap.c
@@ -170,9 +170,9 @@ struct rvt_mmap_info *rvt_create_mmap_in
spin_lock_irq(&rdi->mmap_offset_lock);
if (rdi->mmap_offset == 0)
- rdi->mmap_offset = PAGE_SIZE;
+ rdi->mmap_offset = ALIGN(PAGE_SIZE, SHMLBA);
ip->offset = rdi->mmap_offset;
- rdi->mmap_offset += size;
+ rdi->mmap_offset += ALIGN(size, SHMLBA);
spin_unlock_irq(&rdi->mmap_offset_lock);
INIT_LIST_HEAD(&ip->pending_mmaps);
--- a/drivers/infiniband/sw/rxe/rxe_mmap.c
+++ b/drivers/infiniband/sw/rxe/rxe_mmap.c
@@ -156,10 +156,10 @@ struct rxe_mmap_info *rxe_create_mmap_in
spin_lock_bh(&rxe->mmap_offset_lock);
if (rxe->mmap_offset == 0)
- rxe->mmap_offset = PAGE_SIZE;
+ rxe->mmap_offset = ALIGN(PAGE_SIZE, SHMLBA);
ip->info.offset = rxe->mmap_offset;
- rxe->mmap_offset += size;
+ rxe->mmap_offset += ALIGN(size, SHMLBA);
spin_unlock_bh(&rxe->mmap_offset_lock);
Patches currently in stable-queue which might be from jgunthorpe(a)obsidianresearch.com are
queue-4.9/infiniband-fix-alignment-of-mmap-cookies-to-support-vipt-caching.patch
This is a note to let you know that I've just added the patch titled
IB/rxe: increment msn only when completing a request
to the 4.9-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-rxe-increment-msn-only-when-completing-a-request.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: David Marchand <david.marchand(a)6wind.com>
Date: Fri, 24 Feb 2017 15:38:26 +0100
Subject: IB/rxe: increment msn only when completing a request
From: David Marchand <david.marchand(a)6wind.com>
[ Upstream commit 9fcd67d1772c43d2f23e8fca56acc7219e991676 ]
According to C9-147, MSN should only be incremented when the last packet of
a multi packet request has been received.
"Logically, the requester associates a sequential Send Sequence Number
(SSN) with each WQE posted to the send queue. The SSN bears a one-
to-one relationship to the MSN returned by the responder in each re-
sponse packet. Therefore, when the requester receives a response, it in-
terprets the MSN as representing the SSN of the most recent request
completed by the responder to determine which send WQE(s) can be
completed."
Fixes: 8700e3e7c485 ("Soft RoCE driver")
Signed-off-by: David Marchand <david.marchand(a)6wind.com>
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/sw/rxe/rxe_resp.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/drivers/infiniband/sw/rxe/rxe_resp.c
+++ b/drivers/infiniband/sw/rxe/rxe_resp.c
@@ -799,18 +799,17 @@ static enum resp_states execute(struct r
/* Unreachable */
WARN_ON(1);
- /* We successfully processed this new request. */
- qp->resp.msn++;
-
/* next expected psn, read handles this separately */
qp->resp.psn = (pkt->psn + 1) & BTH_PSN_MASK;
qp->resp.opcode = pkt->opcode;
qp->resp.status = IB_WC_SUCCESS;
- if (pkt->mask & RXE_COMP_MASK)
+ if (pkt->mask & RXE_COMP_MASK) {
+ /* We successfully processed this new request. */
+ qp->resp.msn++;
return RESPST_COMPLETE;
- else if (qp_type(qp) == IB_QPT_RC)
+ } else if (qp_type(qp) == IB_QPT_RC)
return RESPST_ACKNOWLEDGE;
else
return RESPST_CLEANUP;
Patches currently in stable-queue which might be from david.marchand(a)6wind.com are
queue-4.9/ib-rxe-increment-msn-only-when-completing-a-request.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.9-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.9 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 09:02:40 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
@@ -3102,6 +3102,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.9/igb-check-memory-allocation-failure.patch
This is a note to let you know that I've just added the patch titled
IB/rxe: double free on error
to the 4.9-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-rxe-double-free-on-error.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Wed, 8 Mar 2017 08:21:52 +0300
Subject: IB/rxe: double free on error
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit ded260235308f340b979258a4c736e06ba12c747 ]
"goto err;" has it's own kfree_skb() call so it's a double free. We
only need to free on the "goto exit;" path.
Fixes: 8700e3e7c485 ("Soft RoCE driver")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
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/sw/rxe/rxe_req.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/sw/rxe/rxe_req.c
+++ b/drivers/infiniband/sw/rxe/rxe_req.c
@@ -726,11 +726,11 @@ next_wqe:
ret = rxe_xmit_packet(to_rdev(qp->ibqp.device), qp, &pkt, skb);
if (ret) {
qp->need_req_skb = 1;
- kfree_skb(skb);
rollback_state(wqe, qp, &rollback_wqe, rollback_psn);
if (ret == -EAGAIN) {
+ kfree_skb(skb);
rxe_run_task(&qp->req.task, 1);
goto exit;
}
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/bna-integer-overflow-bug-in-debugfs.patch
queue-4.9/btrfs-fix-an-integer-overflow-check.patch
queue-4.9/ib-rxe-double-free-on-error.patch
This is a note to let you know that I've just added the patch titled
IB/rxe: check for allocation failure on elem
to the 4.9-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-rxe-check-for-allocation-failure-on-elem.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Colin Ian King <colin.king(a)canonical.com>
Date: Fri, 8 Sep 2017 15:37:45 +0100
Subject: IB/rxe: check for allocation failure on elem
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 4831ca9e4a8e48cb27e0a792f73250390827a228 ]
The allocation for elem may fail (especially because we're using
GFP_ATOMIC) so best to check for a null return. This fixes a potential
null pointer dereference when assigning elem->pool.
Detected by CoverityScan CID#1357507 ("Dereference null return value")
Fixes: 8700e3e7c485 ("Soft RoCE driver")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
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/sw/rxe/rxe_pool.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/infiniband/sw/rxe/rxe_pool.c
+++ b/drivers/infiniband/sw/rxe/rxe_pool.c
@@ -412,6 +412,8 @@ void *rxe_alloc(struct rxe_pool *pool)
elem = kmem_cache_zalloc(pool_cache(pool),
(pool->flags & RXE_POOL_ATOMIC) ?
GFP_ATOMIC : GFP_KERNEL);
+ if (!elem)
+ return NULL;
elem->pool = pool;
kref_init(&elem->ref_cnt);
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.9/ib-rxe-check-for-allocation-failure-on-elem.patch
This is a note to let you know that I've just added the patch titled
i40iw: Receive netdev events post INET_NOTIFIER state
to the 4.9-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:
i40iw-receive-netdev-events-post-inet_notifier-state.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Shiraz Saleem <shiraz.saleem(a)intel.com>
Date: Fri, 17 Mar 2017 18:30:07 -0500
Subject: i40iw: Receive netdev events post INET_NOTIFIER state
From: Shiraz Saleem <shiraz.saleem(a)intel.com>
[ Upstream commit 871a8623d3b40221ad1103aff715dfee0aa4dacf ]
Netdev notification events are de-registered only when all
client iwdev instances are removed. If a single client is closed
and re-opened, netdev events could arrive even before the Control
Queue-Pair (CQP) is created, causing a NULL pointer dereference crash
in i40iw_get_cqp_request. Fix this by allowing netdev event
notification only after we have reached the INET_NOTIFIER state with
respect to device initialization.
Reported-by: Stefan Assmann <sassmann(a)redhat.com>
Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com>
Reviewed-by: Yuval Shaia <yuval.shaia(a)oracle.com>
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/i40iw/i40iw_utils.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/infiniband/hw/i40iw/i40iw_utils.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_utils.c
@@ -159,6 +159,9 @@ int i40iw_inetaddr_event(struct notifier
return NOTIFY_DONE;
iwdev = &hdl->device;
+ if (iwdev->init_state < INET_NOTIFIER)
+ return NOTIFY_DONE;
+
netdev = iwdev->ldev->netdev;
upper_dev = netdev_master_upper_dev_get(netdev);
if (netdev != event_netdev)
@@ -231,6 +234,9 @@ int i40iw_inet6addr_event(struct notifie
return NOTIFY_DONE;
iwdev = &hdl->device;
+ if (iwdev->init_state < INET_NOTIFIER)
+ return NOTIFY_DONE;
+
netdev = iwdev->ldev->netdev;
if (netdev != event_netdev)
return NOTIFY_DONE;
@@ -280,6 +286,8 @@ int i40iw_net_event(struct notifier_bloc
if (!iwhdl)
return NOTIFY_DONE;
iwdev = &iwhdl->device;
+ if (iwdev->init_state < INET_NOTIFIER)
+ return NOTIFY_DONE;
p = (__be32 *)neigh->primary_key;
i40iw_copy_ip_ntohl(local_ipaddr, p);
if (neigh->nud_state & NUD_VALID) {
Patches currently in stable-queue which might be from shiraz.saleem(a)intel.com are
queue-4.9/i40iw-receive-netdev-events-post-inet_notifier-state.patch
This is a note to let you know that I've just added the patch titled
IB/core: Protect against self-requeue of a cq work item
to the 4.9-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-core-protect-against-self-requeue-of-a-cq-work-item.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Sagi Grimberg <sagi(a)grimberg.me>
Date: Wed, 8 Mar 2017 22:00:52 +0200
Subject: IB/core: Protect against self-requeue of a cq work item
From: Sagi Grimberg <sagi(a)grimberg.me>
[ Upstream commit 86f46aba8d1ac3ed0904542158a9b9cb9c7a143c ]
We need to make sure that the cq work item does not
run when we are destroying the cq. Unlike flush_work,
cancel_work_sync protects against self-requeue of the
work item (which we can do in ib_cq_poll_work).
Signed-off-by: Sagi Grimberg <sagi(a)grimberg.me>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Reviewed-by: Bart Van Assche <bart.vanassche(a)sandisk.com>--
Reviewed-by: Leon Romanovsky <leonro(a)mellanox.com>
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/core/cq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/core/cq.c
+++ b/drivers/infiniband/core/cq.c
@@ -196,7 +196,7 @@ void ib_free_cq(struct ib_cq *cq)
irq_poll_disable(&cq->iop);
break;
case IB_POLL_WORKQUEUE:
- flush_work(&cq->work);
+ cancel_work_sync(&cq->work);
break;
default:
WARN_ON_ONCE(1);
Patches currently in stable-queue which might be from sagi(a)grimberg.me are
queue-4.9/nvme-loop-handle-cpu-unplug-when-re-establishing-the-controller.patch
queue-4.9/ib-core-protect-against-self-requeue-of-a-cq-work-item.patch
queue-4.9/rdma-iser-fix-possible-mr-leak-on-device-removal-event.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.9-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.9 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 09:02:40 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
@@ -96,6 +96,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,
@@ -113,7 +117,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.9/i2c-mux-pca954x-add-missing-pca9546-definition-to-chip_desc.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.9-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.9 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 09:02:40 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
@@ -4217,8 +4217,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);
+ }
}
/**
@@ -4232,8 +4236,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.9/i40e-do-not-enable-napi-on-q_vectors-that-have-no-rings.patch
queue-4.9/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
hwmon: (asus_atk0110) fix uninitialized data access
to the 4.9-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:
hwmon-asus_atk0110-fix-uninitialized-data-access.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 23 Mar 2017 16:03:11 +0100
Subject: hwmon: (asus_atk0110) fix uninitialized data access
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit a2125d02443e9a4e68bcfd9f8004fa23239e8329 ]
The latest gcc-7 snapshot adds a warning to point out that when
atk_read_value_old or atk_read_value_new fails, we copy
uninitialized data into sensor->cached_value:
drivers/hwmon/asus_atk0110.c: In function 'atk_input_show':
drivers/hwmon/asus_atk0110.c:651:26: error: 'value' may be used uninitialized in this function [-Werror=maybe-uninitialized]
Adding an error check avoids this. All versions of the driver
are affected.
Fixes: 2c03d07ad54d ("hwmon: Add Asus ATK0110 support")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Reviewed-by: Luca Tettamanti <kronos.it(a)gmail.com>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hwmon/asus_atk0110.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hwmon/asus_atk0110.c
+++ b/drivers/hwmon/asus_atk0110.c
@@ -646,6 +646,9 @@ static int atk_read_value(struct atk_sen
else
err = atk_read_value_new(sensor, value);
+ if (err)
+ return err;
+
sensor->is_valid = true;
sensor->last_updated = jiffies;
sensor->cached_value = *value;
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/hwmon-asus_atk0110-fix-uninitialized-data-access.patch
queue-4.9/bna-avoid-writing-uninitialized-data-into-hw-registers.patch
queue-4.9/virtio-balloon-use-actual-number-of-stats-for-stats-queue-buffers.patch
queue-4.9/virtio_balloon-prevent-uninitialized-variable-use.patch
queue-4.9/isdn-kcapi-avoid-uninitialized-data.patch
This is a note to let you know that I've just added the patch titled
hwmon: (max31790) Set correct PWM value
to the 4.9-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:
hwmon-max31790-set-correct-pwm-value.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Alex Hemme <ahemme(a)cisco.com>
Date: Tue, 7 Mar 2017 14:38:29 -0500
Subject: hwmon: (max31790) Set correct PWM value
From: Alex Hemme <ahemme(a)cisco.com>
[ Upstream commit dd7406dd334a98ada3ff5371847a3eeb4ba16313 ]
Traced fans not spinning to incorrect PWM value being written.
The passed in value was written instead of the calulated value.
Fixes: 54187ff9d766 ("hwmon: (max31790) Convert to use new hwmon registration API")
Signed-off-by: Alex Hemme <ahemme(a)cisco.com>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hwmon/max31790.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/hwmon/max31790.c
+++ b/drivers/hwmon/max31790.c
@@ -311,7 +311,7 @@ static int max31790_write_pwm(struct dev
data->pwm[channel] = val << 8;
err = i2c_smbus_write_word_swapped(client,
MAX31790_REG_PWMOUT(channel),
- val);
+ data->pwm[channel]);
break;
case hwmon_pwm_enable:
fan_config = data->fan_config[channel];
Patches currently in stable-queue which might be from ahemme(a)cisco.com are
queue-4.9/hwmon-max31790-set-correct-pwm-value.patch
This is a note to let you know that I've just added the patch titled
HID: xinmo: fix for out of range for THT 2P arcade controller.
to the 4.9-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-xinmo-fix-for-out-of-range-for-tht-2p-arcade-controller.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Peter Stein <peter(a)stuntstein.dk>
Date: Fri, 17 Feb 2017 00:00:50 -0800
Subject: HID: xinmo: fix for out of range for THT 2P arcade controller.
From: Peter Stein <peter(a)stuntstein.dk>
[ Upstream commit 9257821c5a1dc57ef3a37f7cbcebaf548395c964 ]
There is a new clone of the XIN MO arcade controller which has same issue with
out of range like the original. This fix will solve the issue where 2
directions on the joystick are not recognized by the new THT 2P arcade
controller with device ID 0x75e1. In details the new device ID is added the
hid-id list and the hid-xinmo source code.
Signed-off-by: Peter Stein <peter(a)stuntstein.dk>
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/hid-core.c | 1 +
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-xinmo.c | 1 +
3 files changed, 3 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2107,6 +2107,7 @@ static const struct hid_device_id hid_ha
{ HID_USB_DEVICE(USB_VENDOR_ID_WALTOP, USB_DEVICE_ID_WALTOP_SIRIUS_BATTERY_FREE_TABLET) },
{ HID_USB_DEVICE(USB_VENDOR_ID_X_TENSIONS, USB_DEVICE_ID_SPEEDLINK_VAD_CEZANNE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_XIN_MO, USB_DEVICE_ID_XIN_MO_DUAL_ARCADE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_XIN_MO, USB_DEVICE_ID_THT_2P_ARCADE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0005) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0030) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ZYDACRON, USB_DEVICE_ID_ZYDACRON_REMOTE_CONTROL) },
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1080,6 +1080,7 @@
#define USB_VENDOR_ID_XIN_MO 0x16c0
#define USB_DEVICE_ID_XIN_MO_DUAL_ARCADE 0x05e1
+#define USB_DEVICE_ID_THT_2P_ARCADE 0x75e1
#define USB_VENDOR_ID_XIROKU 0x1477
#define USB_DEVICE_ID_XIROKU_SPX 0x1006
--- a/drivers/hid/hid-xinmo.c
+++ b/drivers/hid/hid-xinmo.c
@@ -46,6 +46,7 @@ static int xinmo_event(struct hid_device
static const struct hid_device_id xinmo_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_XIN_MO, USB_DEVICE_ID_XIN_MO_DUAL_ARCADE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_XIN_MO, USB_DEVICE_ID_THT_2P_ARCADE) },
{ }
};
Patches currently in stable-queue which might be from peter(a)stuntstein.dk are
queue-4.9/hid-xinmo-fix-for-out-of-range-for-tht-2p-arcade-controller.patch
This is a note to let you know that I've just added the patch titled
HID: corsair: support for K65-K70 Rapidfire and Scimitar Pro RGB
to the 4.9-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-corsair-support-for-k65-k70-rapidfire-and-scimitar-pro-rgb.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Oscar Campos <oscar.campos(a)member.fsf.org>
Date: Fri, 10 Feb 2017 18:23:00 +0000
Subject: HID: corsair: support for K65-K70 Rapidfire and Scimitar Pro RGB
From: Oscar Campos <oscar.campos(a)member.fsf.org>
[ Upstream commit deaba636997557fce46ca7bcb509bff5ea1b0558 ]
Add quirks for several corsair gaming devices to avoid long delays on
report initialization
Supported devices:
- Corsair K65RGB Rapidfire Gaming Keyboard
- Corsair K70RGB Rapidfire Gaming Keyboard
- Corsair Scimitar Pro RGB Gaming Mouse
Signed-off-by: Oscar Campos <oscar.campos(a)member.fsf.org>
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/hid-ids.h | 3 +++
drivers/hid/usbhid/hid-quirks.c | 3 +++
2 files changed, 6 insertions(+)
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -277,6 +277,9 @@
#define USB_DEVICE_ID_CORSAIR_K70RGB 0x1b13
#define USB_DEVICE_ID_CORSAIR_STRAFE 0x1b15
#define USB_DEVICE_ID_CORSAIR_K65RGB 0x1b17
+#define USB_DEVICE_ID_CORSAIR_K70RGB_RAPIDFIRE 0x1b38
+#define USB_DEVICE_ID_CORSAIR_K65RGB_RAPIDFIRE 0x1b39
+#define USB_DEVICE_ID_CORSAIR_SCIMITAR_PRO_RGB 0x1b3e
#define USB_VENDOR_ID_CREATIVELABS 0x041e
#define USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_51 0x322c
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -80,6 +80,9 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K70RGB, HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K65RGB, HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_STRAFE, HID_QUIRK_NO_INIT_REPORTS | HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K70RGB_RAPIDFIRE, HID_QUIRK_NO_INIT_REPORTS | HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K65RGB_RAPIDFIRE, HID_QUIRK_NO_INIT_REPORTS | HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_SCIMITAR_PRO_RGB, HID_QUIRK_NO_INIT_REPORTS | HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_CREATIVELABS, USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_51, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_DELL, USB_DEVICE_ID_DELL_PIXART_USB_OPTICAL_MOUSE, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
Patches currently in stable-queue which might be from oscar.campos(a)member.fsf.org are
queue-4.9/hid-corsair-support-for-k65-k70-rapidfire-and-scimitar-pro-rgb.patch
queue-4.9/hid-corsair-add-driver-scimitar-pro-rgb-gaming-mouse-1b1c-1b3e-support-to-hid-corsair.patch
This is a note to let you know that I've just added the patch titled
HID: corsair: Add driver Scimitar Pro RGB gaming mouse 1b1c:1b3e support to hid-corsair
to the 4.9-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-corsair-add-driver-scimitar-pro-rgb-gaming-mouse-1b1c-1b3e-support-to-hid-corsair.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Oscar Campos <oscar.campos(a)member.fsf.org>
Date: Mon, 6 Mar 2017 21:02:39 +0000
Subject: HID: corsair: Add driver Scimitar Pro RGB gaming mouse 1b1c:1b3e support to hid-corsair
From: Oscar Campos <oscar.campos(a)member.fsf.org>
[ Upstream commit 01adc47e885f1127b29d76d0dfb21d8262f9d6b4 ]
This mouse sold by Corsair as Scimitar PRO RGB defines two consecutive
Logical Minimum items in its Application (Consumer.0001) report making
it non parseable. This patch fixes the report descriptor overriding
byte 77 in rdesc from 0x16 (Logical Minimum with 16 bits value) to 0x26
(Logical Maximum with 16 bits value).
Signed-off-by: Oscar Campos <oscar.campos(a)member.fsf.org>
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 | 1
drivers/hid/hid-core.c | 1
drivers/hid/hid-corsair.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 49 insertions(+)
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -190,6 +190,7 @@ config HID_CORSAIR
Supported devices:
- Vengeance K90
+ - Scimitar PRO RGB
config HID_PRODIKEYS
tristate "Prodikeys PC-MIDI Keyboard support"
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1872,6 +1872,7 @@ static const struct hid_device_id hid_ha
{ 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_CORSAIR, USB_DEVICE_ID_CORSAIR_K90) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_SCIMITAR_PRO_RGB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CREATIVELABS, USB_DEVICE_ID_PRODIKEYS_PCMIDI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, USB_DEVICE_ID_CYGNAL_CP2112) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_1) },
--- a/drivers/hid/hid-corsair.c
+++ b/drivers/hid/hid-corsair.c
@@ -3,8 +3,10 @@
*
* Supported devices:
* - Vengeance K90 Keyboard
+ * - Scimitar PRO RGB Gaming Mouse
*
* Copyright (c) 2015 Clement Vuchener
+ * Copyright (c) 2017 Oscar Campos
*/
/*
@@ -670,10 +672,51 @@ static int corsair_input_mapping(struct
return 0;
}
+/*
+ * The report descriptor of Corsair Scimitar RGB Pro gaming mouse is
+ * non parseable as they define two consecutive Logical Minimum for
+ * the Usage Page (Consumer) in rdescs bytes 75 and 77 being 77 0x16
+ * that should be obviousy 0x26 for Logical Magimum of 16 bits. This
+ * prevents poper parsing of the report descriptor due Logical
+ * Minimum being larger than Logical Maximum.
+ *
+ * This driver fixes the report descriptor for:
+ * - USB ID b1c:1b3e, sold as Scimitar RGB Pro Gaming mouse
+ */
+
+static __u8 *corsair_mouse_report_fixup(struct hid_device *hdev, __u8 *rdesc,
+ unsigned int *rsize)
+{
+ struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
+
+ if (intf->cur_altsetting->desc.bInterfaceNumber == 1) {
+ /*
+ * Corsair Scimitar RGB Pro report descriptor is broken and
+ * defines two different Logical Minimum for the Consumer
+ * Application. The byte 77 should be a 0x26 defining a 16
+ * bits integer for the Logical Maximum but it is a 0x16
+ * instead (Logical Minimum)
+ */
+ switch (hdev->product) {
+ case USB_DEVICE_ID_CORSAIR_SCIMITAR_PRO_RGB:
+ if (*rsize >= 172 && rdesc[75] == 0x15 && rdesc[77] == 0x16
+ && rdesc[78] == 0xff && rdesc[79] == 0x0f) {
+ hid_info(hdev, "Fixing up report descriptor\n");
+ rdesc[77] = 0x26;
+ }
+ break;
+ }
+
+ }
+ return rdesc;
+}
+
static const struct hid_device_id corsair_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K90),
.driver_data = CORSAIR_USE_K90_MACRO |
CORSAIR_USE_K90_BACKLIGHT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
+ USB_DEVICE_ID_CORSAIR_SCIMITAR_PRO_RGB) },
{}
};
@@ -686,10 +729,14 @@ static struct hid_driver corsair_driver
.event = corsair_event,
.remove = corsair_remove,
.input_mapping = corsair_input_mapping,
+ .report_fixup = corsair_mouse_report_fixup,
};
module_hid_driver(corsair_driver);
MODULE_LICENSE("GPL");
+/* Original K90 driver author */
MODULE_AUTHOR("Clement Vuchener");
+/* Scimitar PRO RGB driver author */
+MODULE_AUTHOR("Oscar Campos");
MODULE_DESCRIPTION("HID driver for Corsair devices");
Patches currently in stable-queue which might be from oscar.campos(a)member.fsf.org are
queue-4.9/hid-corsair-support-for-k65-k70-rapidfire-and-scimitar-pro-rgb.patch
queue-4.9/hid-corsair-add-driver-scimitar-pro-rgb-gaming-mouse-1b1c-1b3e-support-to-hid-corsair.patch
This is a note to let you know that I've just added the patch titled
fm10k: fix mis-ordered parameters in declaration for .ndo_set_vf_bw
to the 4.9-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:
fm10k-fix-mis-ordered-parameters-in-declaration-for-.ndo_set_vf_bw.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Jacob Keller <jacob.e.keller(a)intel.com>
Date: Fri, 11 Aug 2017 11:14:58 -0700
Subject: fm10k: fix mis-ordered parameters in declaration for .ndo_set_vf_bw
From: Jacob Keller <jacob.e.keller(a)intel.com>
[ Upstream commit 3e256ac5b1ec307e5dd5a4c99fbdbc651446c738 ]
We've had support for setting both a minimum and maximum bandwidth via
.ndo_set_vf_bw since commit 883a9ccbae56 ("fm10k: Add support for SR-IOV
to driver", 2014-09-20).
Likely because we do not support minimum rates, the declaration
mis-ordered the "unused" parameter, which causes warnings when analyzed
with cppcheck.
Fix this warning by properly declaring the min_rate and max_rate
variables in the declaration and definition (rather than using
"unused"). Also rename "rate" to max_rate so as to clarify that we only
support setting the maximum rate.
Signed-off-by: Jacob Keller <jacob.e.keller(a)intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh(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/fm10k/fm10k.h | 4 ++--
drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 9 +++++----
2 files changed, 7 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/intel/fm10k/fm10k.h
+++ b/drivers/net/ethernet/intel/fm10k/fm10k.h
@@ -508,8 +508,8 @@ s32 fm10k_iov_update_pvid(struct fm10k_i
int fm10k_ndo_set_vf_mac(struct net_device *netdev, int vf_idx, u8 *mac);
int fm10k_ndo_set_vf_vlan(struct net_device *netdev,
int vf_idx, u16 vid, u8 qos, __be16 vlan_proto);
-int fm10k_ndo_set_vf_bw(struct net_device *netdev, int vf_idx, int rate,
- int unused);
+int fm10k_ndo_set_vf_bw(struct net_device *netdev, int vf_idx,
+ int __always_unused min_rate, int max_rate);
int fm10k_ndo_get_vf_config(struct net_device *netdev,
int vf_idx, struct ifla_vf_info *ivi);
--- a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
@@ -482,7 +482,7 @@ int fm10k_ndo_set_vf_vlan(struct net_dev
}
int fm10k_ndo_set_vf_bw(struct net_device *netdev, int vf_idx,
- int __always_unused unused, int rate)
+ int __always_unused min_rate, int max_rate)
{
struct fm10k_intfc *interface = netdev_priv(netdev);
struct fm10k_iov_data *iov_data = interface->iov_data;
@@ -493,14 +493,15 @@ int fm10k_ndo_set_vf_bw(struct net_devic
return -EINVAL;
/* rate limit cannot be less than 10Mbs or greater than link speed */
- if (rate && ((rate < FM10K_VF_TC_MIN) || rate > FM10K_VF_TC_MAX))
+ if (max_rate &&
+ (max_rate < FM10K_VF_TC_MIN || max_rate > FM10K_VF_TC_MAX))
return -EINVAL;
/* store values */
- iov_data->vf_info[vf_idx].rate = rate;
+ iov_data->vf_info[vf_idx].rate = max_rate;
/* update hardware configuration */
- hw->iov.ops.configure_tc(hw, vf_idx, rate);
+ hw->iov.ops.configure_tc(hw, vf_idx, max_rate);
return 0;
}
Patches currently in stable-queue which might be from jacob.e.keller(a)intel.com are
queue-4.9/fm10k-fix-mis-ordered-parameters-in-declaration-for-.ndo_set_vf_bw.patch
queue-4.9/fm10k-ensure-we-process-sm-mbx-when-processing-vf-mbx.patch
This is a note to let you know that I've just added the patch titled
fm10k: ensure we process SM mbx when processing VF mbx
to the 4.9-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:
fm10k-ensure-we-process-sm-mbx-when-processing-vf-mbx.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Jacob Keller <jacob.e.keller(a)intel.com>
Date: Mon, 2 Oct 2017 07:17:50 -0700
Subject: fm10k: ensure we process SM mbx when processing VF mbx
From: Jacob Keller <jacob.e.keller(a)intel.com>
[ Upstream commit 17a91809942ca32c70026d2d5ba3348a2c4fdf8f ]
When we process VF mailboxes, the driver is likely going to also queue
up messages to the switch manager. This process merely queues up the
FIFO, but doesn't actually begin the transmission process. Because we
hold the mailbox lock during this VF processing, the PF<->SM mailbox is
not getting processed at this time. Ensure that we actually process the
PF<->SM mailbox in between each PF<->VF mailbox.
This should ensure prompt transmission of the messages queued up after
each VF message is received and handled.
Signed-off-by: Jacob Keller <jacob.e.keller(a)intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh(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/fm10k/fm10k_iov.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
@@ -126,6 +126,9 @@ process_mbx:
struct fm10k_mbx_info *mbx = &vf_info->mbx;
u16 glort = vf_info->glort;
+ /* process the SM mailbox first to drain outgoing messages */
+ hw->mbx.ops.process(hw, &hw->mbx);
+
/* verify port mapping is valid, if not reset port */
if (vf_info->vf_flags && !fm10k_glort_valid_pf(hw, glort))
hw->iov.ops.reset_lport(hw, vf_info);
Patches currently in stable-queue which might be from jacob.e.keller(a)intel.com are
queue-4.9/fm10k-fix-mis-ordered-parameters-in-declaration-for-.ndo_set_vf_bw.patch
queue-4.9/fm10k-ensure-we-process-sm-mbx-when-processing-vf-mbx.patch
This is a note to let you know that I've just added the patch titled
crypto: crypto4xx - increase context and scatter ring buffer elements
to the 4.9-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-crypto4xx-increase-context-and-scatter-ring-buffer-elements.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Christian Lamparter <chunkeey(a)gmail.com>
Date: Wed, 4 Oct 2017 01:00:08 +0200
Subject: crypto: crypto4xx - increase context and scatter ring buffer elements
From: Christian Lamparter <chunkeey(a)gmail.com>
[ Upstream commit 778f81d6cdb7d25360f082ac0384d5103f04eca5 ]
If crypto4xx is used in conjunction with dm-crypt, the available
ring buffer elements are not enough to handle the load properly.
On an aes-cbc-essiv:sha256 encrypted swap partition the read
performance is abyssal: (tested with hdparm -t)
/dev/mapper/swap_crypt:
Timing buffered disk reads: 14 MB in 3.68 seconds = 3.81 MB/sec
The patch increases both PPC4XX_NUM_SD and PPC4XX_NUM_PD to 256.
This improves the performance considerably:
/dev/mapper/swap_crypt:
Timing buffered disk reads: 104 MB in 3.03 seconds = 34.31 MB/sec
Furthermore, PPC4XX_LAST_SD, PPC4XX_LAST_GD and PPC4XX_LAST_PD
can be easily calculated from their respective PPC4XX_NUM_*
constant.
Signed-off-by: Christian Lamparter <chunkeey(a)gmail.com>
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/amcc/crypto4xx_core.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/crypto/amcc/crypto4xx_core.h
+++ b/drivers/crypto/amcc/crypto4xx_core.h
@@ -34,12 +34,12 @@
#define PPC405EX_CE_RESET 0x00000008
#define CRYPTO4XX_CRYPTO_PRIORITY 300
-#define PPC4XX_LAST_PD 63
-#define PPC4XX_NUM_PD 64
-#define PPC4XX_LAST_GD 1023
+#define PPC4XX_NUM_PD 256
+#define PPC4XX_LAST_PD (PPC4XX_NUM_PD - 1)
#define PPC4XX_NUM_GD 1024
-#define PPC4XX_LAST_SD 63
-#define PPC4XX_NUM_SD 64
+#define PPC4XX_LAST_GD (PPC4XX_NUM_GD - 1)
+#define PPC4XX_NUM_SD 256
+#define PPC4XX_LAST_SD (PPC4XX_NUM_SD - 1)
#define PPC4XX_SD_BUFFER_SIZE 2048
#define PD_ENTRY_INUSE 1
Patches currently in stable-queue which might be from chunkeey(a)gmail.com are
queue-4.9/crypto-crypto4xx-increase-context-and-scatter-ring-buffer-elements.patch
This is a note to let you know that I've just added the patch titled
crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex
netlink: Annotate nlk cb_mutex by protocol
to the 4.9-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-deadlock-between-crypto_alg_sem-rtnl_mutex-genl_mutex.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Herbert Xu <herbert(a)gondor.apana.org.au>
Date: Tue, 14 Mar 2017 18:25:57 +0800
Subject: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex
From: Herbert Xu <herbert(a)gondor.apana.org.au>
[ Upstream commit 8a0f5ccfb33b0b8b51de65b7b3bf342ba10b4fb6 ]
On Tue, Mar 14, 2017 at 10:44:10AM +0100, Dmitry Vyukov wrote:
>
> Yes, please.
> Disregarding some reports is not a good way long term.
Please try this patch.
---8<---
Subject: netlink: Annotate nlk cb_mutex by protocol
Currently all occurences of nlk->cb_mutex are annotated by lockdep
as a single class. This causes a false lcokdep cycle involving
genl and crypto_user.
This patch fixes it by dividing cb_mutex into individual classes
based on the netlink protocol. As genl and crypto_user do not
use the same netlink protocol this breaks the false dependency
loop.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
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/netlink/af_netlink.c | 41 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -96,6 +96,44 @@ EXPORT_SYMBOL_GPL(nl_table);
static DECLARE_WAIT_QUEUE_HEAD(nl_table_wait);
+static struct lock_class_key nlk_cb_mutex_keys[MAX_LINKS];
+
+static const char *const nlk_cb_mutex_key_strings[MAX_LINKS + 1] = {
+ "nlk_cb_mutex-ROUTE",
+ "nlk_cb_mutex-1",
+ "nlk_cb_mutex-USERSOCK",
+ "nlk_cb_mutex-FIREWALL",
+ "nlk_cb_mutex-SOCK_DIAG",
+ "nlk_cb_mutex-NFLOG",
+ "nlk_cb_mutex-XFRM",
+ "nlk_cb_mutex-SELINUX",
+ "nlk_cb_mutex-ISCSI",
+ "nlk_cb_mutex-AUDIT",
+ "nlk_cb_mutex-FIB_LOOKUP",
+ "nlk_cb_mutex-CONNECTOR",
+ "nlk_cb_mutex-NETFILTER",
+ "nlk_cb_mutex-IP6_FW",
+ "nlk_cb_mutex-DNRTMSG",
+ "nlk_cb_mutex-KOBJECT_UEVENT",
+ "nlk_cb_mutex-GENERIC",
+ "nlk_cb_mutex-17",
+ "nlk_cb_mutex-SCSITRANSPORT",
+ "nlk_cb_mutex-ECRYPTFS",
+ "nlk_cb_mutex-RDMA",
+ "nlk_cb_mutex-CRYPTO",
+ "nlk_cb_mutex-SMC",
+ "nlk_cb_mutex-23",
+ "nlk_cb_mutex-24",
+ "nlk_cb_mutex-25",
+ "nlk_cb_mutex-26",
+ "nlk_cb_mutex-27",
+ "nlk_cb_mutex-28",
+ "nlk_cb_mutex-29",
+ "nlk_cb_mutex-30",
+ "nlk_cb_mutex-31",
+ "nlk_cb_mutex-MAX_LINKS"
+};
+
static int netlink_dump(struct sock *sk);
static void netlink_skb_destructor(struct sk_buff *skb);
@@ -585,6 +623,9 @@ static int __netlink_create(struct net *
} else {
nlk->cb_mutex = &nlk->cb_def_mutex;
mutex_init(nlk->cb_mutex);
+ lockdep_set_class_and_name(nlk->cb_mutex,
+ nlk_cb_mutex_keys + protocol,
+ nlk_cb_mutex_key_strings[protocol]);
}
init_waitqueue_head(&nlk->wait);
Patches currently in stable-queue which might be from herbert(a)gondor.apana.org.au are
queue-4.9/crypto-crypto4xx-increase-context-and-scatter-ring-buffer-elements.patch
queue-4.9/crypto-deadlock-between-crypto_alg_sem-rtnl_mutex-genl_mutex.patch
This is a note to let you know that I've just added the patch titled
cpuidle: Validate cpu_dev in cpuidle_add_sysfs()
to the 4.9-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:
cpuidle-validate-cpu_dev-in-cpuidle_add_sysfs.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Vaidyanathan Srinivasan <svaidy(a)linux.vnet.ibm.com>
Date: Sun, 19 Mar 2017 00:51:59 +0530
Subject: cpuidle: Validate cpu_dev in cpuidle_add_sysfs()
From: Vaidyanathan Srinivasan <svaidy(a)linux.vnet.ibm.com>
[ Upstream commit ad0a45fd9c14feebd000b6e84189d0edff265170 ]
If a given cpu is not in cpu_present and cpu hotplug
is disabled, arch can skip setting up the cpu_dev.
Arch cpuidle driver should pass correct cpu mask
for registration, but failing to do so by the driver
causes error to propagate and crash like this:
[ 30.076045] Unable to handle kernel paging request for data at address 0x00000048
[ 30.076100] Faulting instruction address: 0xc0000000007b2f30
cpu 0x4d: Vector: 300 (Data Access) at [c000003feb18b670]
pc: c0000000007b2f30: kobject_get+0x20/0x70
lr: c0000000007b3c94: kobject_add_internal+0x54/0x3f0
sp: c000003feb18b8f0
msr: 9000000000009033
dar: 48
dsisr: 40000000
current = 0xc000003fd2ed8300
paca = 0xc00000000fbab500 softe: 0 irq_happened: 0x01
pid = 1, comm = swapper/0
Linux version 4.11.0-rc2-svaidy+ (sv@sagarika) (gcc version 6.2.0
20161005 (Ubuntu 6.2.0-5ubuntu12) ) #10 SMP Sun Mar 19 00:08:09 IST 2017
enter ? for help
[c000003feb18b960] c0000000007b3c94 kobject_add_internal+0x54/0x3f0
[c000003feb18b9f0] c0000000007b43a4 kobject_init_and_add+0x64/0xa0
[c000003feb18ba70] c000000000e284f4 cpuidle_add_sysfs+0xb4/0x130
[c000003feb18baf0] c000000000e26038 cpuidle_register_device+0x118/0x1c0
[c000003feb18bb30] c000000000e26c48 cpuidle_register+0x78/0x120
[c000003feb18bbc0] c00000000168fd9c powernv_processor_idle_init+0x110/0x1c4
[c000003feb18bc40] c00000000000cff8 do_one_initcall+0x68/0x1d0
[c000003feb18bd00] c0000000016242f4 kernel_init_freeable+0x280/0x360
[c000003feb18bdc0] c00000000000d864 kernel_init+0x24/0x160
[c000003feb18be30] c00000000000b4e8 ret_from_kernel_thread+0x5c/0x74
Validating cpu_dev fixes the crash and reports correct error message like:
[ 30.163506] Failed to register cpuidle device for cpu136
[ 30.173329] Registration of powernv driver failed.
Signed-off-by: Vaidyanathan Srinivasan <svaidy(a)linux.vnet.ibm.com>
[ rjw: Comment massage ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/cpuidle/sysfs.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -613,6 +613,18 @@ int cpuidle_add_sysfs(struct cpuidle_dev
struct device *cpu_dev = get_cpu_device((unsigned long)dev->cpu);
int error;
+ /*
+ * Return if cpu_device is not setup for this CPU.
+ *
+ * This could happen if the arch did not set up cpu_device
+ * since this CPU is not in cpu_present mask and the
+ * driver did not send a correct CPU mask during registration.
+ * Without this check we would end up passing bogus
+ * value for &cpu_dev->kobj in kobject_init_and_add()
+ */
+ if (!cpu_dev)
+ return -ENODEV;
+
kdev = kzalloc(sizeof(*kdev), GFP_KERNEL);
if (!kdev)
return -ENOMEM;
Patches currently in stable-queue which might be from svaidy(a)linux.vnet.ibm.com are
queue-4.9/cpuidle-validate-cpu_dev-in-cpuidle_add_sysfs.patch
queue-4.9/cpuidle-powernv-pass-correct-drv-cpumask-for-registration.patch
This is a note to let you know that I've just added the patch titled
cpuidle: powernv: Pass correct drv->cpumask for registration
to the 4.9-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:
cpuidle-powernv-pass-correct-drv-cpumask-for-registration.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Vaidyanathan Srinivasan <svaidy(a)linux.vnet.ibm.com>
Date: Thu, 23 Mar 2017 20:52:46 +0530
Subject: cpuidle: powernv: Pass correct drv->cpumask for registration
From: Vaidyanathan Srinivasan <svaidy(a)linux.vnet.ibm.com>
[ Upstream commit 293d264f13cbde328d5477f49e3103edbc1dc191 ]
drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init().
On PowerNV platform cpu_present could be less than cpu_possible in cases
where firmware detects the cpu, but it is not available to the OS. When
CONFIG_HOTPLUG_CPU=n, such cpus are not hotplugable at runtime and hence
we skip creating cpu_device.
This breaks cpuidle on powernv where register_cpu() is not called for
cpus in cpu_possible_mask that cannot be hot-added at runtime.
Trying cpuidle_register_device() on cpu without cpu_device will cause
crash like this:
cpu 0xf: Vector: 380 (Data SLB Access) at [c000000ff1503490]
pc: c00000000022c8bc: string+0x34/0x60
lr: c00000000022ed78: vsnprintf+0x284/0x42c
sp: c000000ff1503710
msr: 9000000000009033
dar: 6000000060000000
current = 0xc000000ff1480000
paca = 0xc00000000fe82d00 softe: 0 irq_happened: 0x01
pid = 1, comm = swapper/8
Linux version 4.11.0-rc2 (sv@sagarika) (gcc version 4.9.4
(Buildroot 2017.02-00004-gc28573e) ) #15 SMP Fri Mar 17 19:32:02 IST 2017
enter ? for help
[link register ] c00000000022ed78 vsnprintf+0x284/0x42c
[c000000ff1503710] c00000000022ebb8 vsnprintf+0xc4/0x42c (unreliable)
[c000000ff1503800] c00000000022ef40 vscnprintf+0x20/0x44
[c000000ff1503830] c0000000000ab61c vprintk_emit+0x94/0x2cc
[c000000ff15038a0] c0000000000acc9c vprintk_func+0x60/0x74
[c000000ff15038c0] c000000000619694 printk+0x38/0x4c
[c000000ff15038e0] c000000000224950 kobject_get+0x40/0x60
[c000000ff1503950] c00000000022507c kobject_add_internal+0x60/0x2c4
[c000000ff15039e0] c000000000225350 kobject_init_and_add+0x70/0x78
[c000000ff1503a60] c00000000053c288 cpuidle_add_sysfs+0x9c/0xe0
[c000000ff1503ae0] c00000000053aeac cpuidle_register_device+0xd4/0x12c
[c000000ff1503b30] c00000000053b108 cpuidle_register+0x98/0xcc
[c000000ff1503bc0] c00000000085eaf0 powernv_processor_idle_init+0x140/0x1e0
[c000000ff1503c60] c00000000000cd60 do_one_initcall+0xc0/0x15c
[c000000ff1503d20] c000000000833e84 kernel_init_freeable+0x1a0/0x25c
[c000000ff1503dc0] c00000000000d478 kernel_init+0x24/0x12c
[c000000ff1503e30] c00000000000b564 ret_from_kernel_thread+0x5c/0x78
This patch fixes the bug by passing correct cpumask from
powernv-cpuidle driver.
Signed-off-by: Vaidyanathan Srinivasan <svaidy(a)linux.vnet.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego(a)linux.vnet.ibm.com>
Acked-by: Michael Ellerman <mpe(a)ellerman.id.au>
[ rjw: Comment massage ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/cpuidle/cpuidle-powernv.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -164,6 +164,24 @@ static int powernv_cpuidle_driver_init(v
drv->state_count += 1;
}
+ /*
+ * On the PowerNV platform cpu_present may be less than cpu_possible in
+ * cases when firmware detects the CPU, but it is not available to the
+ * OS. If CONFIG_HOTPLUG_CPU=n, then such CPUs are not hotplugable at
+ * run time and hence cpu_devices are not created for those CPUs by the
+ * generic topology_init().
+ *
+ * drv->cpumask defaults to cpu_possible_mask in
+ * __cpuidle_driver_init(). This breaks cpuidle on PowerNV where
+ * cpu_devices are not created for CPUs in cpu_possible_mask that
+ * cannot be hot-added later at run time.
+ *
+ * Trying cpuidle_register_device() on a CPU without a cpu_device is
+ * incorrect, so pass a correct CPU mask to the generic cpuidle driver.
+ */
+
+ drv->cpumask = (struct cpumask *)cpu_present_mask;
+
return 0;
}
Patches currently in stable-queue which might be from svaidy(a)linux.vnet.ibm.com are
queue-4.9/cpuidle-validate-cpu_dev-in-cpuidle_add_sysfs.patch
queue-4.9/cpuidle-powernv-pass-correct-drv-cpumask-for-registration.patch
This is a note to let you know that I've just added the patch titled
cpufreq: Fix creation of symbolic links to policy directories
to the 4.9-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:
cpufreq-fix-creation-of-symbolic-links-to-policy-directories.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com>
Date: Mon, 27 Mar 2017 19:33:09 +0200
Subject: cpufreq: Fix creation of symbolic links to policy directories
From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com>
[ Upstream commit 2f0ba790df51721794c11abc7a076d407392f648 ]
The cpufreq core only tries to create symbolic links from CPU
directories in sysfs to policy directories in cpufreq_add_dev(),
either when a given CPU is registered or when the cpufreq driver
is registered, whichever happens first. That is not sufficient,
however, because cpufreq_add_dev() may be called for an offline CPU
whose policy object has not been created yet and, quite obviously,
the symbolic cannot be added in that case.
Fix that by making cpufreq_online() attempt to add symbolic links to
policy objects for the CPUs in the related_cpus mask of every new
policy object created by it.
The cpufreq_driver_lock locking around the for_each_cpu() loop
in cpufreq_online() is dropped, because it is not necessary and the
code is somewhat simpler without it. Moreover, failures to create
a symbolic link will not be regarded as hard errors any more and
the CPUs without those links will not be taken offline automatically,
but that should not be problematic in practice.
Reported-and-tested-by: Prashanth Prakash <pprakash(a)codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Cc: 4.9+ <stable(a)vger.kernel.org> # 4.9+
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/cpufreq/cpufreq.c | 38 +++++++++++++++++++++-----------------
1 file changed, 21 insertions(+), 17 deletions(-)
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -918,11 +918,19 @@ static struct kobj_type ktype_cpufreq =
.release = cpufreq_sysfs_release,
};
-static int add_cpu_dev_symlink(struct cpufreq_policy *policy,
- struct device *dev)
+static void add_cpu_dev_symlink(struct cpufreq_policy *policy, unsigned int cpu)
{
+ struct device *dev = get_cpu_device(cpu);
+
+ if (!dev)
+ return;
+
+ if (cpumask_test_and_set_cpu(cpu, policy->real_cpus))
+ return;
+
dev_dbg(dev, "%s: Adding symlink\n", __func__);
- return sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq");
+ if (sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq"))
+ dev_err(dev, "cpufreq symlink creation failed\n");
}
static void remove_cpu_dev_symlink(struct cpufreq_policy *policy,
@@ -1184,10 +1192,10 @@ static int cpufreq_online(unsigned int c
policy->user_policy.min = policy->min;
policy->user_policy.max = policy->max;
- write_lock_irqsave(&cpufreq_driver_lock, flags);
- for_each_cpu(j, policy->related_cpus)
+ for_each_cpu(j, policy->related_cpus) {
per_cpu(cpufreq_cpu_data, j) = policy;
- write_unlock_irqrestore(&cpufreq_driver_lock, flags);
+ add_cpu_dev_symlink(policy, j);
+ }
} else {
policy->min = policy->user_policy.min;
policy->max = policy->user_policy.max;
@@ -1284,13 +1292,15 @@ out_exit_policy:
if (cpufreq_driver->exit)
cpufreq_driver->exit(policy);
+
+ for_each_cpu(j, policy->real_cpus)
+ remove_cpu_dev_symlink(policy, get_cpu_device(j));
+
out_free_policy:
cpufreq_policy_free(policy, !new_policy);
return ret;
}
-static int cpufreq_offline(unsigned int cpu);
-
/**
* cpufreq_add_dev - the cpufreq interface for a CPU device.
* @dev: CPU device.
@@ -1312,16 +1322,10 @@ static int cpufreq_add_dev(struct device
/* Create sysfs link on CPU registration */
policy = per_cpu(cpufreq_cpu_data, cpu);
- if (!policy || cpumask_test_and_set_cpu(cpu, policy->real_cpus))
- return 0;
+ if (policy)
+ add_cpu_dev_symlink(policy, cpu);
- ret = add_cpu_dev_symlink(policy, dev);
- if (ret) {
- cpumask_clear_cpu(cpu, policy->real_cpus);
- cpufreq_offline(cpu);
- }
-
- return ret;
+ return 0;
}
static int cpufreq_offline(unsigned int cpu)
Patches currently in stable-queue which might be from rafael.j.wysocki(a)intel.com are
queue-4.9/cpuidle-validate-cpu_dev-in-cpuidle_add_sysfs.patch
queue-4.9/cpuidle-fix-broadcast-control-when-broadcast-can-not-be-entered.patch
queue-4.9/cpuidle-powernv-pass-correct-drv-cpumask-for-registration.patch
queue-4.9/pm-opp-move-error-message-to-debug-level.patch
queue-4.9/cpufreq-fix-creation-of-symbolic-links-to-policy-directories.patch
This is a note to let you know that I've just added the patch titled
cpuidle: fix broadcast control when broadcast can not be entered
to the 4.9-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:
cpuidle-fix-broadcast-control-when-broadcast-can-not-be-entered.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Fri, 1 Sep 2017 14:29:56 +1000
Subject: cpuidle: fix broadcast control when broadcast can not be entered
From: Nicholas Piggin <npiggin(a)gmail.com>
[ Upstream commit f187851b9b4a76952b1158b86434563dd2031103 ]
When failing to enter broadcast timer mode for an idle state that
requires it, a new state is selected that does not require broadcast,
but the broadcast variable remains set. This causes
tick_broadcast_exit to be called despite not having entered broadcast
mode.
This causes the WARN_ON_ONCE(!irqs_disabled()) to trigger in some
cases. It does not appear to cause problems for code today, but seems
to violate the interface so should be fixed.
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/cpuidle/cpuidle.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -189,6 +189,7 @@ int cpuidle_enter_state(struct cpuidle_d
return -EBUSY;
}
target_state = &drv->states[index];
+ broadcast = false;
}
/* Take note of the planned idle state. */
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.9/cpuidle-fix-broadcast-control-when-broadcast-can-not-be-entered.patch
This is a note to let you know that I've just added the patch titled
clk: sunxi-ng: sun6i: Rename HDMI DDC clock to avoid name collision
to the 4.9-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:
clk-sunxi-ng-sun6i-rename-hdmi-ddc-clock-to-avoid-name-collision.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Chen-Yu Tsai <wens(a)csie.org>
Date: Fri, 29 Sep 2017 16:22:54 +0800
Subject: clk: sunxi-ng: sun6i: Rename HDMI DDC clock to avoid name collision
From: Chen-Yu Tsai <wens(a)csie.org>
[ Upstream commit 7f3ed79188f2f094d0ee366fa858857fb7f511ba ]
The HDMI DDC clock found in the CCU is the parent of the actual DDC
clock within the HDMI controller. That clock is also named "hdmi-ddc".
Rename the one in the CCU to "ddc". This makes more sense than renaming
the one in the HDMI controller to something else.
Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
Signed-off-by: Chen-Yu Tsai <wens(a)csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -608,7 +608,7 @@ static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_cl
0x150, 0, 4, 24, 2, BIT(31),
CLK_SET_RATE_PARENT);
-static SUNXI_CCU_GATE(hdmi_ddc_clk, "hdmi-ddc", "osc24M", 0x150, BIT(30), 0);
+static SUNXI_CCU_GATE(hdmi_ddc_clk, "ddc", "osc24M", 0x150, BIT(30), 0);
static SUNXI_CCU_GATE(ps_clk, "ps", "lcd1-ch1", 0x140, BIT(31), 0);
Patches currently in stable-queue which might be from wens(a)csie.org are
queue-4.9/clk-sunxi-ng-sun6i-rename-hdmi-ddc-clock-to-avoid-name-collision.patch
This is a note to let you know that I've just added the patch titled
bnxt_en: Fix NULL pointer dereference in reopen failure path
to the 4.9-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:
bnxt_en-fix-null-pointer-dereference-in-reopen-failure-path.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Sankar Patchineelam <sankar.patchineelam(a)broadcom.com>
Date: Tue, 28 Mar 2017 19:47:29 -0400
Subject: bnxt_en: Fix NULL pointer dereference in reopen failure path
From: Sankar Patchineelam <sankar.patchineelam(a)broadcom.com>
[ Upstream commit 2247925f0942dc4e7c09b1cde45ca18461d94c5f ]
Net device reset can fail when the h/w or f/w is in a bad state.
Subsequent netdevice open fails in bnxt_hwrm_stat_ctx_alloc().
The cleanup invokes bnxt_hwrm_resource_free() which inturn
calls bnxt_disable_int(). In this routine, the code segment
if (ring->fw_ring_id != INVALID_HW_RING_ID)
BNXT_CP_DB(cpr->cp_doorbell, cpr->cp_raw_cons);
results in NULL pointer dereference as cpr->cp_doorbell is not yet
initialized, and fw_ring_id is zero.
The fix is to initialize cpr fw_ring_id to INVALID_HW_RING_ID before
bnxt_init_chip() is invoked.
Signed-off-by: Sankar Patchineelam <sankar.patchineelam(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.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/bnxt/bnxt.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -2381,6 +2381,18 @@ static int bnxt_init_one_rx_ring(struct
return 0;
}
+static void bnxt_init_cp_rings(struct bnxt *bp)
+{
+ int i;
+
+ for (i = 0; i < bp->cp_nr_rings; i++) {
+ struct bnxt_cp_ring_info *cpr = &bp->bnapi[i]->cp_ring;
+ struct bnxt_ring_struct *ring = &cpr->cp_ring_struct;
+
+ ring->fw_ring_id = INVALID_HW_RING_ID;
+ }
+}
+
static int bnxt_init_rx_rings(struct bnxt *bp)
{
int i, rc = 0;
@@ -4700,6 +4712,7 @@ static int bnxt_shutdown_nic(struct bnxt
static int bnxt_init_nic(struct bnxt *bp, bool irq_re_init)
{
+ bnxt_init_cp_rings(bp);
bnxt_init_rx_rings(bp);
bnxt_init_tx_rings(bp);
bnxt_init_ring_grps(bp, irq_re_init);
Patches currently in stable-queue which might be from sankar.patchineelam(a)broadcom.com are
queue-4.9/bnxt_en-fix-null-pointer-dereference-in-reopen-failure-path.patch
This is a note to let you know that I've just added the patch titled
Btrfs: fix an integer overflow check
to the 4.9-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:
btrfs-fix-an-integer-overflow-check.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Fri, 17 Mar 2017 23:51:20 +0300
Subject: Btrfs: fix an integer overflow check
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 457ae7268b29c33dee1c0feb143a15f6029d177b ]
This isn't super serious because you need CAP_ADMIN to run this code.
I added this integer overflow check last year but apparently I am
rubbish at writing integer overflow checks... There are two issues.
First, access_ok() works on unsigned long type and not u64 so on 32 bit
systems the access_ok() could be checking a truncated size. The other
issue is that we should be using a stricter limit so we don't overflow
the kzalloc() setting ctx->clone_roots later in the function after the
access_ok():
alloc_size = sizeof(struct clone_root) * (arg->clone_sources_count + 1);
sctx->clone_roots = kzalloc(alloc_size, GFP_KERNEL | __GFP_NOWARN);
Fixes: f5ecec3ce21f ("btrfs: send: silence an integer overflow warning")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
[ added comment ]
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/send.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -6196,8 +6196,13 @@ long btrfs_ioctl_send(struct file *mnt_f
goto out;
}
+ /*
+ * Check that we don't overflow at later allocations, we request
+ * clone_sources_count + 1 items, and compare to unsigned long inside
+ * access_ok.
+ */
if (arg->clone_sources_count >
- ULLONG_MAX / sizeof(*arg->clone_sources)) {
+ ULONG_MAX / sizeof(struct clone_root) - 1) {
ret = -EINVAL;
goto out;
}
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/bna-integer-overflow-bug-in-debugfs.patch
queue-4.9/btrfs-fix-an-integer-overflow-check.patch
queue-4.9/ib-rxe-double-free-on-error.patch
This is a note to let you know that I've just added the patch titled
bna: avoid writing uninitialized data into hw registers
to the 4.9-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:
bna-avoid-writing-uninitialized-data-into-hw-registers.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 23 Mar 2017 17:07:26 +0100
Subject: bna: avoid writing uninitialized data into hw registers
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit a5af83925363eb85d467933e3d6ec5a87001eb7c ]
The latest gcc-7 snapshot warns about bfa_ioc_send_enable/bfa_ioc_send_disable
writing undefined values into the hardware registers:
drivers/net/ethernet/brocade/bna/bfa_ioc.c: In function 'bfa_iocpf_sm_disabling_entry':
arch/arm/include/asm/io.h:109:22: error: '*((void *)&disable_req+4)' is used uninitialized in this function [-Werror=uninitialized]
arch/arm/include/asm/io.h:109:22: error: '*((void *)&disable_req+8)' is used uninitialized in this function [-Werror=uninitialized]
The two functions look like they should do the same thing, but only one
of them initializes the time stamp and clscode field. The fact that we
only get a warning for one of the two functions seems to be arbitrary,
based on the inlining decisions in the compiler.
To address this, I'm making both functions do the same thing:
- set the clscode from the ioc structure in both
- set the time stamp from ktime_get_real_seconds (which also
avoids the signed-integer overflow in 2038 and extends the
well-defined behavior until 2106).
- zero-fill the reserved field
Fixes: 8b230ed8ec96 ("bna: Brocade 10Gb Ethernet device driver")
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/net/ethernet/brocade/bna/bfa_ioc.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/brocade/bna/bfa_ioc.c
+++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
@@ -1930,13 +1930,13 @@ static void
bfa_ioc_send_enable(struct bfa_ioc *ioc)
{
struct bfi_ioc_ctrl_req enable_req;
- struct timeval tv;
bfi_h2i_set(enable_req.mh, BFI_MC_IOC, BFI_IOC_H2I_ENABLE_REQ,
bfa_ioc_portid(ioc));
enable_req.clscode = htons(ioc->clscode);
- do_gettimeofday(&tv);
- enable_req.tv_sec = ntohl(tv.tv_sec);
+ enable_req.rsvd = htons(0);
+ /* overflow in 2106 */
+ enable_req.tv_sec = ntohl(ktime_get_real_seconds());
bfa_ioc_mbox_send(ioc, &enable_req, sizeof(struct bfi_ioc_ctrl_req));
}
@@ -1947,6 +1947,10 @@ bfa_ioc_send_disable(struct bfa_ioc *ioc
bfi_h2i_set(disable_req.mh, BFI_MC_IOC, BFI_IOC_H2I_DISABLE_REQ,
bfa_ioc_portid(ioc));
+ disable_req.clscode = htons(ioc->clscode);
+ disable_req.rsvd = htons(0);
+ /* overflow in 2106 */
+ disable_req.tv_sec = ntohl(ktime_get_real_seconds());
bfa_ioc_mbox_send(ioc, &disable_req, sizeof(struct bfi_ioc_ctrl_req));
}
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/hwmon-asus_atk0110-fix-uninitialized-data-access.patch
queue-4.9/bna-avoid-writing-uninitialized-data-into-hw-registers.patch
queue-4.9/virtio-balloon-use-actual-number-of-stats-for-stats-queue-buffers.patch
queue-4.9/virtio_balloon-prevent-uninitialized-variable-use.patch
queue-4.9/isdn-kcapi-avoid-uninitialized-data.patch
This is a note to let you know that I've just added the patch titled
bna: integer overflow bug in debugfs
to the 4.9-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:
bna-integer-overflow-bug-in-debugfs.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Fri, 17 Mar 2017 23:52:35 +0300
Subject: bna: integer overflow bug in debugfs
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 13e2d5187f6b965ba3556caedb914baf81b98ed2 ]
We could allocate less memory than intended because we do:
bnad->regdata = kzalloc(len << 2, GFP_KERNEL);
The shift can overflow leading to a crash. This is debugfs code so the
impact is very small.
Fixes: 7afc5dbde091 ("bna: Add debugfs interface.")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Acked-by: Rasesh Mody <rasesh.mody(a)cavium.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/brocade/bna/bnad_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/brocade/bna/bnad_debugfs.c
+++ b/drivers/net/ethernet/brocade/bna/bnad_debugfs.c
@@ -325,7 +325,7 @@ bnad_debugfs_write_regrd(struct file *fi
return PTR_ERR(kern_buf);
rc = sscanf(kern_buf, "%x:%x", &addr, &len);
- if (rc < 2) {
+ if (rc < 2 || len > UINT_MAX >> 2) {
netdev_warn(bnad->netdev, "failed to read user buffer\n");
kfree(kern_buf);
return -EINVAL;
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/bna-integer-overflow-bug-in-debugfs.patch
queue-4.9/btrfs-fix-an-integer-overflow-check.patch
queue-4.9/ib-rxe-double-free-on-error.patch
This is a note to let you know that I've just added the patch titled
backlight: pwm_bl: Fix overflow condition
to the 4.9-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:
backlight-pwm_bl-fix-overflow-condition.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Derek Basehore <dbasehore(a)chromium.org>
Date: Tue, 29 Aug 2017 13:34:34 -0700
Subject: backlight: pwm_bl: Fix overflow condition
From: Derek Basehore <dbasehore(a)chromium.org>
[ Upstream commit 5d0c49acebc9488e37db95f1d4a55644e545ffe7 ]
This fixes an overflow condition that can happen with high max
brightness and period values in compute_duty_cycle. This fixes it by
using a 64 bit variable for computing the duty cycle.
Signed-off-by: Derek Basehore <dbasehore(a)chromium.org>
Acked-by: Thierry Reding <thierry.reding(a)gmail.com>
Reviewed-by: Brian Norris <briannorris(a)chromium.org>
Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/backlight/pwm_bl.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -79,14 +79,17 @@ static void pwm_backlight_power_off(stru
static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
{
unsigned int lth = pb->lth_brightness;
- int duty_cycle;
+ u64 duty_cycle;
if (pb->levels)
duty_cycle = pb->levels[brightness];
else
duty_cycle = brightness;
- return (duty_cycle * (pb->period - lth) / pb->scale) + lth;
+ duty_cycle *= pb->period - lth;
+ do_div(duty_cycle, pb->scale);
+
+ return duty_cycle + lth;
}
static int pwm_backlight_update_status(struct backlight_device *bl)
Patches currently in stable-queue which might be from dbasehore(a)chromium.org are
queue-4.9/backlight-pwm_bl-fix-overflow-condition.patch
This is a note to let you know that I've just added the patch titled
ASoC: STI: Fix reader substream pointer set
to the 4.9-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:
asoc-sti-fix-reader-substream-pointer-set.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Arnaud Pouliquen <arnaud.pouliquen(a)st.com>
Date: Thu, 23 Mar 2017 19:39:54 +0100
Subject: ASoC: STI: Fix reader substream pointer set
From: Arnaud Pouliquen <arnaud.pouliquen(a)st.com>
[ Upstream commit 3c9d3f1bc2defd418b5933bbc928096c9c686d3b ]
reader->substream is used in IRQ handler for error case but is never set.
Set value to pcm substream on DAI startup and clean it on dai shutdown.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen(a)st.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/sti/uniperif_reader.c | 3 +++
1 file changed, 3 insertions(+)
--- a/sound/soc/sti/uniperif_reader.c
+++ b/sound/soc/sti/uniperif_reader.c
@@ -364,6 +364,8 @@ static int uni_reader_startup(struct snd
struct uniperif *reader = priv->dai_data.uni;
int ret;
+ reader->substream = substream;
+
if (!UNIPERIF_TYPE_IS_TDM(reader))
return 0;
@@ -393,6 +395,7 @@ static void uni_reader_shutdown(struct s
/* Stop the reader */
uni_reader_stop(reader);
}
+ reader->substream = NULL;
}
static const struct snd_soc_dai_ops uni_reader_dai_ops = {
Patches currently in stable-queue which might be from arnaud.pouliquen(a)st.com are
queue-4.9/asoc-sti-fix-reader-substream-pointer-set.patch
This is a note to let you know that I've just added the patch titled
ASoC: img-parallel-out: Add pm_runtime_get/put to set_fmt callback
to the 4.9-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:
asoc-img-parallel-out-add-pm_runtime_get-put-to-set_fmt-callback.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Ed Blake <ed.blake(a)sondrel.com>
Date: Mon, 2 Oct 2017 11:00:33 +0100
Subject: ASoC: img-parallel-out: Add pm_runtime_get/put to set_fmt callback
From: Ed Blake <ed.blake(a)sondrel.com>
[ Upstream commit c70458890ff15d858bd347fa9f563818bcd6e457 ]
Add pm_runtime_get_sync and pm_runtime_put calls to set_fmt callback
function. This fixes a bus error during boot when CONFIG_SUSPEND is
defined when this function gets called while the device is runtime
disabled and device registers are accessed while the clock is disabled.
Signed-off-by: Ed Blake <ed.blake(a)sondrel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/img/img-parallel-out.c | 2 ++
1 file changed, 2 insertions(+)
--- a/sound/soc/img/img-parallel-out.c
+++ b/sound/soc/img/img-parallel-out.c
@@ -166,9 +166,11 @@ static int img_prl_out_set_fmt(struct sn
return -EINVAL;
}
+ pm_runtime_get_sync(prl->dev);
reg = img_prl_out_readl(prl, IMG_PRL_OUT_CTL);
reg = (reg & ~IMG_PRL_OUT_CTL_EDGE_MASK) | control_set;
img_prl_out_writel(prl, reg, IMG_PRL_OUT_CTL);
+ pm_runtime_put(prl->dev);
return 0;
}
Patches currently in stable-queue which might be from ed.blake(a)sondrel.com are
queue-4.9/asoc-img-parallel-out-add-pm_runtime_get-put-to-set_fmt-callback.patch
This is a note to let you know that I've just added the patch titled
arm: kprobes: Fix the return address of multiple kretprobes
to the 4.9-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:
arm-kprobes-fix-the-return-address-of-multiple-kretprobes.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Masami Hiramatsu <mhiramat(a)kernel.org>
Date: Tue, 14 Feb 2017 00:05:59 +0900
Subject: arm: kprobes: Fix the return address of multiple kretprobes
From: Masami Hiramatsu <mhiramat(a)kernel.org>
[ Upstream commit 06553175f585b52509c7df37d6f4a50aacb7b211 ]
This is arm port of commit 737480a0d525 ("kprobes/x86:
Fix the return address of multiple kretprobes").
Fix the return address of subsequent kretprobes when multiple
kretprobes are set on the same function.
For example:
# cd /sys/kernel/debug/tracing
# echo "r:event1 sys_symlink" > kprobe_events
# echo "r:event2 sys_symlink" >> kprobe_events
# echo 1 > events/kprobes/enable
# ln -s /tmp/foo /tmp/bar
(without this patch)
# cat trace | grep -v ^#
ln-82 [000] dn.2 68.446525: event1: (kretprobe_trampoline+0x0/0x18 <- SyS_symlink)
ln-82 [000] dn.2 68.447831: event2: (ret_fast_syscall+0x0/0x1c <- SyS_symlink)
(with this patch)
# cat trace | grep -v ^#
ln-81 [000] dn.1 39.463469: event1: (ret_fast_syscall+0x0/0x1c <- SyS_symlink)
ln-81 [000] dn.1 39.464701: event2: (ret_fast_syscall+0x0/0x1c <- SyS_symlink)
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: KUMANO Syuhei <kumano.prog(a)gmail.com>
Signed-off-by: Jon Medhurst <tixy(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/probes/kprobes/core.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
--- a/arch/arm/probes/kprobes/core.c
+++ b/arch/arm/probes/kprobes/core.c
@@ -433,6 +433,7 @@ static __used __kprobes void *trampoline
struct hlist_node *tmp;
unsigned long flags, orig_ret_address = 0;
unsigned long trampoline_address = (unsigned long)&kretprobe_trampoline;
+ kprobe_opcode_t *correct_ret_addr = NULL;
INIT_HLIST_HEAD(&empty_rp);
kretprobe_hash_lock(current, &head, &flags);
@@ -455,14 +456,34 @@ static __used __kprobes void *trampoline
/* another task is sharing our hash bucket */
continue;
+ orig_ret_address = (unsigned long)ri->ret_addr;
+
+ if (orig_ret_address != trampoline_address)
+ /*
+ * This is the real return address. Any other
+ * instances associated with this task are for
+ * other calls deeper on the call stack
+ */
+ break;
+ }
+
+ kretprobe_assert(ri, orig_ret_address, trampoline_address);
+
+ correct_ret_addr = ri->ret_addr;
+ hlist_for_each_entry_safe(ri, tmp, head, hlist) {
+ if (ri->task != current)
+ /* another task is sharing our hash bucket */
+ continue;
+
+ orig_ret_address = (unsigned long)ri->ret_addr;
if (ri->rp && ri->rp->handler) {
__this_cpu_write(current_kprobe, &ri->rp->kp);
get_kprobe_ctlblk()->kprobe_status = KPROBE_HIT_ACTIVE;
+ ri->ret_addr = correct_ret_addr;
ri->rp->handler(ri, regs);
__this_cpu_write(current_kprobe, NULL);
}
- orig_ret_address = (unsigned long)ri->ret_addr;
recycle_rp_inst(ri, &empty_rp);
if (orig_ret_address != trampoline_address)
@@ -474,7 +495,6 @@ static __used __kprobes void *trampoline
break;
}
- kretprobe_assert(ri, orig_ret_address, trampoline_address);
kretprobe_hash_unlock(current, &flags);
hlist_for_each_entry_safe(ri, tmp, &empty_rp, hlist) {
Patches currently in stable-queue which might be from mhiramat(a)kernel.org are
queue-4.9/arm-kprobes-fix-the-return-address-of-multiple-kretprobes.patch
This is a note to let you know that I've just added the patch titled
arm: kprobes: Align stack to 8-bytes in test code
to the 4.9-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:
arm-kprobes-align-stack-to-8-bytes-in-test-code.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Jon Medhurst <tixy(a)linaro.org>
Date: Thu, 2 Mar 2017 13:04:09 +0000
Subject: arm: kprobes: Align stack to 8-bytes in test code
From: Jon Medhurst <tixy(a)linaro.org>
[ Upstream commit 974310d047f3c7788a51d10c8d255eebdb1fa857 ]
kprobes test cases need to have a stack that is aligned to an 8-byte
boundary because they call other functions (and the ARM ABI mandates
that alignment) and because test cases include 64-bit accesses to the
stack. Unfortunately, GCC doesn't ensure this alignment for inline
assembler and for the code in question seems to always misalign it by
pushing just the LR register onto the stack. We therefore need to
explicitly perform stack alignment at the start of each test case.
Without this fix, some test cases will generate alignment faults on
systems where alignment is enforced. Even if the kernel is configured to
handle these faults in software, triggering them is ugly. It also
exposes limitations in the fault handling code which doesn't cope with
writes to the stack. E.g. when handling this instruction
strd r6, [sp, #-64]!
the fault handling code will write to a stack location below the SP
value at the point the fault occurred, which coincides with where the
exception handler has pushed the saved register context. This results in
corruption of those registers.
Signed-off-by: Jon Medhurst <tixy(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/probes/kprobes/test-core.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
--- a/arch/arm/probes/kprobes/test-core.c
+++ b/arch/arm/probes/kprobes/test-core.c
@@ -976,7 +976,10 @@ static void coverage_end(void)
void __naked __kprobes_test_case_start(void)
{
__asm__ __volatile__ (
- "stmdb sp!, {r4-r11} \n\t"
+ "mov r2, sp \n\t"
+ "bic r3, r2, #7 \n\t"
+ "mov sp, r3 \n\t"
+ "stmdb sp!, {r2-r11} \n\t"
"sub sp, sp, #"__stringify(TEST_MEMORY_SIZE)"\n\t"
"bic r0, lr, #1 @ r0 = inline data \n\t"
"mov r1, sp \n\t"
@@ -996,7 +999,8 @@ void __naked __kprobes_test_case_end_32(
"movne pc, r0 \n\t"
"mov r0, r4 \n\t"
"add sp, sp, #"__stringify(TEST_MEMORY_SIZE)"\n\t"
- "ldmia sp!, {r4-r11} \n\t"
+ "ldmia sp!, {r2-r11} \n\t"
+ "mov sp, r2 \n\t"
"mov pc, r0 \n\t"
);
}
@@ -1012,7 +1016,8 @@ void __naked __kprobes_test_case_end_16(
"bxne r0 \n\t"
"mov r0, r4 \n\t"
"add sp, sp, #"__stringify(TEST_MEMORY_SIZE)"\n\t"
- "ldmia sp!, {r4-r11} \n\t"
+ "ldmia sp!, {r2-r11} \n\t"
+ "mov sp, r2 \n\t"
"bx r0 \n\t"
);
}
Patches currently in stable-queue which might be from tixy(a)linaro.org are
queue-4.9/arm-kprobes-fix-the-return-address-of-multiple-kretprobes.patch
queue-4.9/arm-kprobes-align-stack-to-8-bytes-in-test-code.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: am335x-evmsk: adjust mmc2 param to allow suspend
to the 4.9-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:
arm-dts-am335x-evmsk-adjust-mmc2-param-to-allow-suspend.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: "Reizer, Eyal" <eyalr(a)ti.com>
Date: Sun, 26 Mar 2017 08:53:10 +0000
Subject: ARM: dts: am335x-evmsk: adjust mmc2 param to allow suspend
From: "Reizer, Eyal" <eyalr(a)ti.com>
[ Upstream commit 9bcf53f34a2c1cebc45cc12e273dcd5f51fbc099 ]
mmc2 used for wl12xx was missing the keep-power-in suspend
parameter. As a result the board couldn't reach suspend state.
Signed-off-by: Eyal Reizer <eyalr(a)ti.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/am335x-evmsk.dts | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -668,6 +668,7 @@
ti,non-removable;
bus-width = <4>;
cap-power-off-card;
+ keep-power-in-suspend;
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins>;
Patches currently in stable-queue which might be from eyalr(a)ti.com are
queue-4.9/arm-dts-am335x-evmsk-adjust-mmc2-param-to-allow-suspend.patch
This is a note to let you know that I've just added the patch titled
ARM: dma-mapping: disallow dma_get_sgtable() for non-kernel managed memory
to the 4.9-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:
arm-dma-mapping-disallow-dma_get_sgtable-for-non-kernel-managed-memory.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Russell King <rmk+kernel(a)armlinux.org.uk>
Date: Wed, 29 Mar 2017 17:12:47 +0100
Subject: ARM: dma-mapping: disallow dma_get_sgtable() for non-kernel managed memory
From: Russell King <rmk+kernel(a)armlinux.org.uk>
[ Upstream commit 916a008b4b8ecc02fbd035cfb133773dba1ff3d7 ]
dma_get_sgtable() tries to create a scatterlist table containing valid
struct page pointers for the coherent memory allocation passed in to it.
However, memory can be declared via dma_declare_coherent_memory(), or
via other reservation schemes which means that coherent memory is not
guaranteed to be backed by struct pages. In such cases, the resulting
scatterlist table contains pointers to invalid pages, which causes
kernel oops later.
This patch adds detection of such memory, and refuses to create a
scatterlist table for such memory.
Reported-by: Shuah Khan <shuahkhan(a)gmail.com>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mm/dma-mapping.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -930,13 +930,31 @@ static void arm_coherent_dma_free(struct
__arm_dma_free(dev, size, cpu_addr, handle, attrs, true);
}
+/*
+ * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
+ * that the intention is to allow exporting memory allocated via the
+ * coherent DMA APIs through the dma_buf API, which only accepts a
+ * scattertable. This presents a couple of problems:
+ * 1. Not all memory allocated via the coherent DMA APIs is backed by
+ * a struct page
+ * 2. Passing coherent DMA memory into the streaming APIs is not allowed
+ * as we will try to flush the memory through a different alias to that
+ * actually being used (and the flushes are redundant.)
+ */
int arm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t handle, size_t size,
unsigned long attrs)
{
- struct page *page = pfn_to_page(dma_to_pfn(dev, handle));
+ unsigned long pfn = dma_to_pfn(dev, handle);
+ struct page *page;
int ret;
+ /* If the PFN is not valid, we do not have a struct page */
+ if (!pfn_valid(pfn))
+ return -ENXIO;
+
+ page = pfn_to_page(pfn);
+
ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
if (unlikely(ret))
return ret;
Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are
queue-4.9/arm-dma-mapping-disallow-dma_get_sgtable-for-non-kernel-managed-memory.patch
queue-4.9/rtc-pl031-make-interrupt-optional.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: ti: fix PCI bus dtc warnings
to the 4.9-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:
arm-dts-ti-fix-pci-bus-dtc-warnings.patch
and it can be found in the queue-4.9 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 09:02:40 CET 2017
From: Rob Herring <robh(a)kernel.org>
Date: Tue, 21 Mar 2017 21:03:01 -0500
Subject: ARM: dts: ti: fix PCI bus dtc warnings
From: Rob Herring <robh(a)kernel.org>
[ Upstream commit 7d79f6098d82f8c09914d7799bc96891ad9c3baf ]
dtc recently added PCI bus checks. Fix these warnings.
Signed-off-by: Rob Herring <robh(a)kernel.org>
Cc: "Benoît Cousson" <bcousson(a)baylibre.com>
Cc: Tony Lindgren <tony(a)atomide.com>
Cc: linux-omap(a)vger.kernel.org
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/dra7.dtsi | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -282,6 +282,7 @@
device_type = "pci";
ranges = <0x81000000 0 0 0x03000 0 0x00010000
0x82000000 0 0x20013000 0x13000 0 0xffed000>;
+ bus-range = <0x00 0xff>;
#interrupt-cells = <1>;
num-lanes = <1>;
linux,pci-domain = <0>;
@@ -318,6 +319,7 @@
device_type = "pci";
ranges = <0x81000000 0 0 0x03000 0 0x00010000
0x82000000 0 0x30013000 0x13000 0 0xffed000>;
+ bus-range = <0x00 0xff>;
#interrupt-cells = <1>;
num-lanes = <1>;
linux,pci-domain = <1>;
Patches currently in stable-queue which might be from robh(a)kernel.org are
queue-4.9/arm-dts-ti-fix-pci-bus-dtc-warnings.patch
commit 12841f87b7a8ceb3d54f171660f72a86941bfcb3 upstream, for 4.3.
During an eeh a kernel-oops is reported if no vPHB is allocated to the
AFU. This happens as during AFU init, an error in creation of vPHB is
a non-fatal error. Hence afu->phb should always be checked for NULL
before iterating over it for the virtual AFU pci devices.
This patch fixes the kenel-oops by adding a NULL pointer check for
afu->phb before it is dereferenced.
Fixes: 9e8df8a21963 ("cxl: EEH support")
Cc: stable(a)vger.kernel.org # v4.3+
Signed-off-by: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com>
Acked-by: Andrew Donnellan <andrew.donnellan(a)au1.ibm.com>
Acked-by: Frederic Barrat <fbarrat(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
---
Changelog:
- Rebased the patch on 4.3 stable tree
---
drivers/misc/cxl/pci.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 85761d7eb333..b982329f3837 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -1328,6 +1328,9 @@ static pci_ers_result_t cxl_vphb_error_detected(struct cxl_afu *afu,
/* There should only be one entry, but go through the list
* anyway
*/
+ if (afu->phb == NULL)
+ return result;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
if (!afu_dev->driver)
continue;
@@ -1368,6 +1371,10 @@ static pci_ers_result_t cxl_pci_error_detected(struct pci_dev *pdev,
*/
for (i = 0; i < adapter->slices; i++) {
afu = adapter->afu[i];
+ /*
+ * Tell the AFU drivers; but we don't care what they
+ * say, we're going away.
+ */
cxl_vphb_error_detected(afu, state);
}
return PCI_ERS_RESULT_DISCONNECT;
@@ -1491,6 +1498,9 @@ static pci_ers_result_t cxl_pci_slot_reset(struct pci_dev *pdev)
if (cxl_afu_select_best_mode(afu))
goto err;
+ if (afu->phb == NULL)
+ continue;
+
cxl_pci_vphb_reconfigure(afu);
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
@@ -1555,6 +1565,9 @@ static void cxl_pci_resume(struct pci_dev *pdev)
for (i = 0; i < adapter->slices; i++) {
afu = adapter->afu[i];
+ if (afu->phb == NULL)
+ continue;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
if (afu_dev->driver && afu_dev->driver->err_handler &&
afu_dev->driver->err_handler->resume)
--
2.14.3
This is a note to let you know that I've just added the patch titled
cxl: Check if vphb exists before iterating over AFU devices
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:
cxl-check-if-vphb-exists-before-iterating-over-afu-devices.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 12841f87b7a8ceb3d54f171660f72a86941bfcb3 Mon Sep 17 00:00:00 2001
From: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com>
Date: Thu, 23 Nov 2017 09:08:57 +0530
Subject: cxl: Check if vphb exists before iterating over AFU devices
From: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com>
commit 12841f87b7a8ceb3d54f171660f72a86941bfcb3 upstream.
During an eeh a kernel-oops is reported if no vPHB is allocated to the
AFU. This happens as during AFU init, an error in creation of vPHB is
a non-fatal error. Hence afu->phb should always be checked for NULL
before iterating over it for the virtual AFU pci devices.
This patch fixes the kenel-oops by adding a NULL pointer check for
afu->phb before it is dereferenced.
Fixes: 9e8df8a21963 ("cxl: EEH support")
Signed-off-by: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com>
Acked-by: Andrew Donnellan <andrew.donnellan(a)au1.ibm.com>
Acked-by: Frederic Barrat <fbarrat(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/cxl/pci.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -1329,6 +1329,9 @@ static pci_ers_result_t cxl_vphb_error_d
/* There should only be one entry, but go through the list
* anyway
*/
+ if (afu->phb == NULL)
+ return result;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
if (!afu_dev->driver)
continue;
@@ -1369,6 +1372,10 @@ static pci_ers_result_t cxl_pci_error_de
*/
for (i = 0; i < adapter->slices; i++) {
afu = adapter->afu[i];
+ /*
+ * Tell the AFU drivers; but we don't care what they
+ * say, we're going away.
+ */
cxl_vphb_error_detected(afu, state);
}
return PCI_ERS_RESULT_DISCONNECT;
@@ -1492,6 +1499,9 @@ static pci_ers_result_t cxl_pci_slot_res
if (cxl_afu_select_best_mode(afu))
goto err;
+ if (afu->phb == NULL)
+ continue;
+
cxl_pci_vphb_reconfigure(afu);
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
@@ -1556,6 +1566,9 @@ static void cxl_pci_resume(struct pci_de
for (i = 0; i < adapter->slices; i++) {
afu = adapter->afu[i];
+ if (afu->phb == NULL)
+ continue;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
if (afu_dev->driver && afu_dev->driver->err_handler &&
afu_dev->driver->err_handler->resume)
Patches currently in stable-queue which might be from vaibhav(a)linux.vnet.ibm.com are
queue-4.4/cxl-check-if-vphb-exists-before-iterating-over-afu-devices.patch
commit 12841f87b7a8ceb3d54f171660f72a86941bfcb3 upstream, for 4.9.
During an eeh a kernel-oops is reported if no vPHB is allocated to the
AFU. This happens as during AFU init, an error in creation of vPHB is
a non-fatal error. Hence afu->phb should always be checked for NULL
before iterating over it for the virtual AFU pci devices.
This patch fixes the kenel-oops by adding a NULL pointer check for
afu->phb before it is dereferenced.
Fixes: 9e8df8a21963 ("cxl: EEH support")
Cc: stable(a)vger.kernel.org
Signed-off-by: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com>
Acked-by: Andrew Donnellan <andrew.donnellan(a)au1.ibm.com>
Acked-by: Frederic Barrat <fbarrat(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
---
Changelog:
Rebased the upstream patch over stable 4.9 tree
---
drivers/misc/cxl/pci.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index eef202d4399b..a5422f483ad5 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -1758,6 +1758,9 @@ static pci_ers_result_t cxl_vphb_error_detected(struct cxl_afu *afu,
/* There should only be one entry, but go through the list
* anyway
*/
+ if (afu->phb == NULL)
+ return result;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
if (!afu_dev->driver)
continue;
@@ -1801,6 +1804,11 @@ static pci_ers_result_t cxl_pci_error_detected(struct pci_dev *pdev,
/* Only participate in EEH if we are on a virtual PHB */
if (afu->phb == NULL)
return PCI_ERS_RESULT_NONE;
+
+ /*
+ * Tell the AFU drivers; but we don't care what they
+ * say, we're going away.
+ */
cxl_vphb_error_detected(afu, state);
}
return PCI_ERS_RESULT_DISCONNECT;
@@ -1941,6 +1949,9 @@ static pci_ers_result_t cxl_pci_slot_reset(struct pci_dev *pdev)
if (cxl_afu_select_best_mode(afu))
goto err;
+ if (afu->phb == NULL)
+ continue;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
/* Reset the device context.
* TODO: make this less disruptive
@@ -2003,6 +2014,9 @@ static void cxl_pci_resume(struct pci_dev *pdev)
for (i = 0; i < adapter->slices; i++) {
afu = adapter->afu[i];
+ if (afu->phb == NULL)
+ continue;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
if (afu_dev->driver && afu_dev->driver->err_handler &&
afu_dev->driver->err_handler->resume)
--
2.14.3
Before unregistering the led classes, we have to be sure there is no
more events in the input pipeline.
Closing the input node before removing the led classes flushes the
pipeline and this prevents segfaults.
Found with https://github.com/whot/fuzzydevice
Link: https://bugzilla.kernel.org/show_bug.cgi?id=197679
Cc: stable(a)vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
---
drivers/input/input-leds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/input-leds.c b/drivers/input/input-leds.c
index c86eb3d648bf..8aefcc186a02 100644
--- a/drivers/input/input-leds.c
+++ b/drivers/input/input-leds.c
@@ -211,6 +211,7 @@ static void input_leds_disconnect(struct input_handle *handle)
int i;
cancel_delayed_work_sync(&leds->init_work);
+ input_close_device(handle);
for (i = 0; i < leds->num_leds; i++) {
struct input_led *led = &leds->leds[i];
@@ -219,7 +220,6 @@ static void input_leds_disconnect(struct input_handle *handle)
kfree(led->cdev.name);
}
- input_close_device(handle);
input_unregister_handle(handle);
kfree(leds);
--
2.14.3
If a bio is throttled and splitted after throttling, the bio could be
resubmited and enters the throttling again. This will cause part of the
bio is charged multiple times. If the cgroup has an IO limit, the double
charge will significantly harm the performance. The bio split becomes
quite common after arbitrary bio size change.
To fix this, we always set the BIO_THROTTLED flag if a bio is throttled.
If the bio is cloned/slitted, we copy the flag to new bio too to avoid
double charge. However cloned bio could be directed to a new disk,
keeping the flag will have problem. The observation is we always set new
disk for the bio in this case, so we can clear the flag in
bio_set_dev().
This issue exists a long time, arbitrary bio size change makes it worse,
so this should go into stable at least since v4.2.
V1-> V2: Not add extra field in bio based on discussion with Tejun
Cc: Tejun Heo <tj(a)kernel.org>
Cc: Vivek Goyal <vgoyal(a)redhat.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Shaohua Li <shli(a)fb.com>
---
block/bio.c | 2 ++
block/blk-throttle.c | 8 +-------
include/linux/bio.h | 2 ++
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index 8338304..d1d4d51 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -598,6 +598,8 @@ void __bio_clone_fast(struct bio *bio, struct bio *bio_src)
*/
bio->bi_disk = bio_src->bi_disk;
bio_set_flag(bio, BIO_CLONED);
+ if (bio_flagged(bio_src, BIO_THROTTLED))
+ bio_set_flag(bio, BIO_THROTTLED);
bio->bi_opf = bio_src->bi_opf;
bio->bi_write_hint = bio_src->bi_write_hint;
bio->bi_iter = bio_src->bi_iter;
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index ee6d7b0..f90fec1 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -2222,13 +2222,7 @@ bool blk_throtl_bio(struct request_queue *q, struct blkcg_gq *blkg,
out_unlock:
spin_unlock_irq(q->queue_lock);
out:
- /*
- * As multiple blk-throtls may stack in the same issue path, we
- * don't want bios to leave with the flag set. Clear the flag if
- * being issued.
- */
- if (!throttled)
- bio_clear_flag(bio, BIO_THROTTLED);
+ bio_set_flag(bio, BIO_THROTTLED);
#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
if (throttled || !td->track_bio_latency)
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 9c75f58..27b5bac 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -504,6 +504,8 @@ extern unsigned int bvec_nr_vecs(unsigned short idx);
#define bio_set_dev(bio, bdev) \
do { \
+ if ((bio)->bi_disk != (bdev)->bd_disk) \
+ bio_clear_flag(bio, BIO_THROTTLED);\
(bio)->bi_disk = (bdev)->bd_disk; \
(bio)->bi_partno = (bdev)->bd_partno; \
} while (0)
--
2.9.5
This is a note to let you know that I've just added the patch titled
cxl: Check if vphb exists before iterating over AFU devices
to the 4.9-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:
cxl-check-if-vphb-exists-before-iterating-over-afu-devices.patch
and it can be found in the queue-4.9 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 12841f87b7a8ceb3d54f171660f72a86941bfcb3 Mon Sep 17 00:00:00 2001
From: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com>
Date: Thu, 23 Nov 2017 09:08:57 +0530
Subject: cxl: Check if vphb exists before iterating over AFU devices
From: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com>
commit 12841f87b7a8ceb3d54f171660f72a86941bfcb3 upstream.
During an eeh a kernel-oops is reported if no vPHB is allocated to the
AFU. This happens as during AFU init, an error in creation of vPHB is
a non-fatal error. Hence afu->phb should always be checked for NULL
before iterating over it for the virtual AFU pci devices.
This patch fixes the kenel-oops by adding a NULL pointer check for
afu->phb before it is dereferenced.
Fixes: 9e8df8a21963 ("cxl: EEH support")
Signed-off-by: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com>
Acked-by: Andrew Donnellan <andrew.donnellan(a)au1.ibm.com>
Acked-by: Frederic Barrat <fbarrat(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/cxl/pci.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -1758,6 +1758,9 @@ static pci_ers_result_t cxl_vphb_error_d
/* There should only be one entry, but go through the list
* anyway
*/
+ if (afu->phb == NULL)
+ return result;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
if (!afu_dev->driver)
continue;
@@ -1801,6 +1804,11 @@ static pci_ers_result_t cxl_pci_error_de
/* Only participate in EEH if we are on a virtual PHB */
if (afu->phb == NULL)
return PCI_ERS_RESULT_NONE;
+
+ /*
+ * Tell the AFU drivers; but we don't care what they
+ * say, we're going away.
+ */
cxl_vphb_error_detected(afu, state);
}
return PCI_ERS_RESULT_DISCONNECT;
@@ -1941,6 +1949,9 @@ static pci_ers_result_t cxl_pci_slot_res
if (cxl_afu_select_best_mode(afu))
goto err;
+ if (afu->phb == NULL)
+ continue;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
/* Reset the device context.
* TODO: make this less disruptive
@@ -2003,6 +2014,9 @@ static void cxl_pci_resume(struct pci_de
for (i = 0; i < adapter->slices; i++) {
afu = adapter->afu[i];
+ if (afu->phb == NULL)
+ continue;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
if (afu_dev->driver && afu_dev->driver->err_handler &&
afu_dev->driver->err_handler->resume)
Patches currently in stable-queue which might be from vaibhav(a)linux.vnet.ibm.com are
queue-4.9/cxl-check-if-vphb-exists-before-iterating-over-afu-devices.patch
This is a note to let you know that I've just added the patch titled
arm64: Initialise high_memory global variable earlier
to the 4.9-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:
arm64-initialise-high_memory-global-variable-earlier.patch
and it can be found in the queue-4.9 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 f24e5834a2c3f6c5f814a417f858226f0a010ade Mon Sep 17 00:00:00 2001
From: Steve Capper <steve.capper(a)arm.com>
Date: Mon, 4 Dec 2017 14:13:05 +0000
Subject: arm64: Initialise high_memory global variable earlier
From: Steve Capper <steve.capper(a)arm.com>
commit f24e5834a2c3f6c5f814a417f858226f0a010ade upstream.
The high_memory global variable is used by
cma_declare_contiguous(.) before it is defined.
We don't notice this as we compute __pa(high_memory - 1), and it looks
like we're processing a VA from the direct linear map.
This problem becomes apparent when we flip the kernel virtual address
space and the linear map is moved to the bottom of the kernel VA space.
This patch moves the initialisation of high_memory before it used.
Fixes: f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory boundary")
Signed-off-by: Steve Capper <steve.capper(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/mm/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -296,6 +296,7 @@ void __init arm64_memblock_init(void)
arm64_dma_phys_limit = max_zone_dma_phys();
else
arm64_dma_phys_limit = PHYS_MASK + 1;
+ high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
dma_contiguous_reserve(arm64_dma_phys_limit);
memblock_allow_resize();
@@ -322,7 +323,6 @@ void __init bootmem_init(void)
sparse_init();
zone_sizes_init(min, max);
- high_memory = __va((max << PAGE_SHIFT) - 1) + 1;
memblock_dump_all();
}
Patches currently in stable-queue which might be from steve.capper(a)arm.com are
queue-4.9/arm64-initialise-high_memory-global-variable-earlier.patch
This is a note to let you know that I've just added the patch titled
arm64: Initialise high_memory global variable earlier
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:
arm64-initialise-high_memory-global-variable-earlier.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 f24e5834a2c3f6c5f814a417f858226f0a010ade Mon Sep 17 00:00:00 2001
From: Steve Capper <steve.capper(a)arm.com>
Date: Mon, 4 Dec 2017 14:13:05 +0000
Subject: arm64: Initialise high_memory global variable earlier
From: Steve Capper <steve.capper(a)arm.com>
commit f24e5834a2c3f6c5f814a417f858226f0a010ade upstream.
The high_memory global variable is used by
cma_declare_contiguous(.) before it is defined.
We don't notice this as we compute __pa(high_memory - 1), and it looks
like we're processing a VA from the direct linear map.
This problem becomes apparent when we flip the kernel virtual address
space and the linear map is moved to the bottom of the kernel VA space.
This patch moves the initialisation of high_memory before it used.
Fixes: f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory boundary")
Signed-off-by: Steve Capper <steve.capper(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/mm/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -178,6 +178,7 @@ void __init arm64_memblock_init(void)
arm64_dma_phys_limit = max_zone_dma_phys();
else
arm64_dma_phys_limit = PHYS_MASK + 1;
+ high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
dma_contiguous_reserve(arm64_dma_phys_limit);
memblock_allow_resize();
@@ -202,7 +203,6 @@ void __init bootmem_init(void)
sparse_init();
zone_sizes_init(min, max);
- high_memory = __va((max << PAGE_SHIFT) - 1) + 1;
max_pfn = max_low_pfn = max;
}
Patches currently in stable-queue which might be from steve.capper(a)arm.com are
queue-4.4/arm64-initialise-high_memory-global-variable-earlier.patch
This is a note to let you know that I've just added the patch titled
vfio/pci: Virtualize Maximum Payload Size
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
vfio-pci-virtualize-maximum-payload-size.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Alex Williamson <alex.williamson(a)redhat.com>
Date: Mon, 2 Oct 2017 12:39:09 -0600
Subject: vfio/pci: Virtualize Maximum Payload Size
From: Alex Williamson <alex.williamson(a)redhat.com>
[ Upstream commit 523184972b282cd9ca17a76f6ca4742394856818 ]
With virtual PCI-Express chipsets, we now see userspace/guest drivers
trying to match the physical MPS setting to a virtual downstream port.
Of course a lone physical device surrounded by virtual interconnects
cannot make a correct decision for a proper MPS setting. Instead,
let's virtualize the MPS control register so that writes through to
hardware are disallowed. Userspace drivers like QEMU assume they can
write anything to the device and we'll filter out anything dangerous.
Since mismatched MPS can lead to AER and other faults, let's add it
to the kernel side rather than relying on userspace virtualization to
handle it.
Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com>
Reviewed-by: Eric Auger <eric.auger(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/vfio/pci/vfio_pci_config.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/vfio/pci/vfio_pci_config.c
+++ b/drivers/vfio/pci/vfio_pci_config.c
@@ -849,11 +849,13 @@ static int __init init_pci_cap_exp_perm(
/*
* Allow writes to device control fields, except devctl_phantom,
- * which could confuse IOMMU, and the ARI bit in devctl2, which
+ * which could confuse IOMMU, MPS, which can break communication
+ * with other physical devices, and the ARI bit in devctl2, which
* is set at probe time. FLR gets virtualized via our writefn.
*/
p_setw(perm, PCI_EXP_DEVCTL,
- PCI_EXP_DEVCTL_BCR_FLR, ~PCI_EXP_DEVCTL_PHANTOM);
+ PCI_EXP_DEVCTL_BCR_FLR | PCI_EXP_DEVCTL_PAYLOAD,
+ ~PCI_EXP_DEVCTL_PHANTOM);
p_setw(perm, PCI_EXP_DEVCTL2, NO_VIRT, ~PCI_EXP_DEVCTL2_ARI);
return 0;
}
Patches currently in stable-queue which might be from alex.williamson(a)redhat.com are
queue-4.14/pci-avoid-bus-reset-if-bridge-itself-is-broken.patch
queue-4.14/vfio-pci-virtualize-maximum-payload-size.patch
This is a note to let you know that I've just added the patch titled
tracing: Exclude 'generic fields' from histograms
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tracing-exclude-generic-fields-from-histograms.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Tom Zanussi <tom.zanussi(a)linux.intel.com>
Date: Fri, 22 Sep 2017 14:58:17 -0500
Subject: tracing: Exclude 'generic fields' from histograms
From: Tom Zanussi <tom.zanussi(a)linux.intel.com>
[ Upstream commit a15f7fc20389a8827d5859907568b201234d4b79 ]
There are a small number of 'generic fields' (comm/COMM/cpu/CPU) that
are found by trace_find_event_field() but are only meant for
filtering. Specifically, they unlike normal fields, they have a size
of 0 and thus wreak havoc when used as a histogram key.
Exclude these (return -EINVAL) when used as histogram keys.
Link: http://lkml.kernel.org/r/956154cbc3e8a4f0633d619b886c97f0f0edf7b4.150610504…
Signed-off-by: Tom Zanussi <tom.zanussi(a)linux.intel.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>
---
kernel/trace/trace_events_hist.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -450,7 +450,7 @@ static int create_val_field(struct hist_
}
field = trace_find_event_field(file->event_call, field_name);
- if (!field) {
+ if (!field || !field->size) {
ret = -EINVAL;
goto out;
}
@@ -548,7 +548,7 @@ static int create_key_field(struct hist_
}
field = trace_find_event_field(file->event_call, field_name);
- if (!field) {
+ if (!field || !field->size) {
ret = -EINVAL;
goto out;
}
Patches currently in stable-queue which might be from tom.zanussi(a)linux.intel.com are
queue-4.14/tracing-exclude-generic-fields-from-histograms.patch
This is a note to let you know that I've just added the patch titled
staging: greybus: light: Release memory obtained by kasprintf
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
staging-greybus-light-release-memory-obtained-by-kasprintf.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Sat, 23 Sep 2017 13:25:30 +0530
Subject: staging: greybus: light: Release memory obtained by kasprintf
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
[ Upstream commit 04820da21050b35eed68aa046115d810163ead0c ]
Free memory region, if gb_lights_channel_config is not successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Reviewed-by: Rui Miguel Silva <rmfrfs(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/greybus/light.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/staging/greybus/light.c
+++ b/drivers/staging/greybus/light.c
@@ -925,6 +925,8 @@ static void __gb_lights_led_unregister(s
return;
led_classdev_unregister(cdev);
+ kfree(cdev->name);
+ cdev->name = NULL;
channel->led = NULL;
}
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.14/staging-greybus-light-release-memory-obtained-by-kasprintf.patch
This is a note to let you know that I've just added the patch titled
sctp: silence warns on sctp_stream_init allocations
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sctp-silence-warns-on-sctp_stream_init-allocations.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Date: Tue, 3 Oct 2017 19:20:08 -0300
Subject: sctp: silence warns on sctp_stream_init allocations
From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
[ Upstream commit 1ae2eaaa229bc350b6f38fbf4ab9c873532aecfb ]
As SCTP supports up to 65535 streams, that can lead to very large
allocations in sctp_stream_init(). As Xin Long noticed, systems with
small amounts of memory are more prone to not have enough memory and
dump warnings on dmesg initiated by user actions. Thus, silence them.
Also, if the reallocation of stream->out is not necessary, skip it and
keep the memory we already have.
Reported-by: Xin Long <lucien.xin(a)gmail.com>
Tested-by: Xin Long <lucien.xin(a)gmail.com>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner(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/sctp/stream.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/net/sctp/stream.c
+++ b/net/sctp/stream.c
@@ -40,9 +40,14 @@ int sctp_stream_init(struct sctp_stream
{
int i;
+ gfp |= __GFP_NOWARN;
+
/* Initial stream->out size may be very big, so free it and alloc
- * a new one with new outcnt to save memory.
+ * a new one with new outcnt to save memory if needed.
*/
+ if (outcnt == stream->outcnt)
+ goto in;
+
kfree(stream->out);
stream->out = kcalloc(outcnt, sizeof(*stream->out), gfp);
@@ -53,6 +58,7 @@ int sctp_stream_init(struct sctp_stream
for (i = 0; i < stream->outcnt; i++)
stream->out[i].state = SCTP_STREAM_OPEN;
+in:
if (!incnt)
return 0;
Patches currently in stable-queue which might be from marcelo.leitner(a)gmail.com are
queue-4.14/sctp-silence-warns-on-sctp_stream_init-allocations.patch
This is a note to let you know that I've just added the patch titled
tcp: fix under-evaluated ssthresh in TCP Vegas
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tcp-fix-under-evaluated-ssthresh-in-tcp-vegas.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Hoang Tran <tranviethoang.vn(a)gmail.com>
Date: Wed, 27 Sep 2017 18:30:58 +0200
Subject: tcp: fix under-evaluated ssthresh in TCP Vegas
From: Hoang Tran <tranviethoang.vn(a)gmail.com>
[ Upstream commit cf5d74b85ef40c202c76d90959db4d850f301b95 ]
With the commit 76174004a0f19785 (tcp: do not slow start when cwnd equals
ssthresh), the comparison to the reduced cwnd in tcp_vegas_ssthresh() would
under-evaluate the ssthresh.
Signed-off-by: Hoang Tran <hoang.tran(a)uclouvain.be>
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/ipv4/tcp_vegas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/tcp_vegas.c
+++ b/net/ipv4/tcp_vegas.c
@@ -158,7 +158,7 @@ EXPORT_SYMBOL_GPL(tcp_vegas_cwnd_event);
static inline u32 tcp_vegas_ssthresh(struct tcp_sock *tp)
{
- return min(tp->snd_ssthresh, tp->snd_cwnd-1);
+ return min(tp->snd_ssthresh, tp->snd_cwnd);
}
static void tcp_vegas_cong_avoid(struct sock *sk, u32 ack, u32 acked)
Patches currently in stable-queue which might be from tranviethoang.vn(a)gmail.com are
queue-4.14/tcp-fix-under-evaluated-ssthresh-in-tcp-vegas.patch
This is a note to let you know that I've just added the patch titled
scsi: mpt3sas: Fix IO error occurs on pulling out a drive from RAID1 volume created on two SATA drive
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-mpt3sas-fix-io-error-occurs-on-pulling-out-a-drive-from-raid1-volume-created-on-two-sata-drive.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Sreekanth Reddy <sreekanth.reddy(a)broadcom.com>
Date: Tue, 10 Oct 2017 18:41:18 +0530
Subject: scsi: mpt3sas: Fix IO error occurs on pulling out a drive from RAID1 volume created on two SATA drive
From: Sreekanth Reddy <sreekanth.reddy(a)broadcom.com>
[ Upstream commit 2ce9a3645299ba1752873d333d73f67620f4550b ]
Whenever an I/O for a RAID volume fails with IOCStatus
MPI2_IOCSTATUS_SCSI_IOC_TERMINATED and SCSIStatus equal to
(MPI2_SCSI_STATE_TERMINATED | MPI2_SCSI_STATE_NO_SCSI_STATUS) then
return the I/O to SCSI midlayer with "DID_RESET" (i.e. retry the IO
infinite times) set in the host byte.
Previously, the driver was completing the I/O with "DID_SOFT_ERROR"
which causes the I/O to be quickly retried. However, firmware needed
more time and hence I/Os were failing.
Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy(a)broadcom.com>
Reviewed-by: Tomas Henzl <thenzl(a)redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -4804,6 +4804,11 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *i
} else if (log_info == VIRTUAL_IO_FAILED_RETRY) {
scmd->result = DID_RESET << 16;
break;
+ } else if ((scmd->device->channel == RAID_CHANNEL) &&
+ (scsi_state == (MPI2_SCSI_STATE_TERMINATED |
+ MPI2_SCSI_STATE_NO_SCSI_STATUS))) {
+ scmd->result = DID_RESET << 16;
+ break;
}
scmd->result = DID_SOFT_ERROR << 16;
break;
Patches currently in stable-queue which might be from sreekanth.reddy(a)broadcom.com are
queue-4.14/scsi-mpt3sas-fix-io-error-occurs-on-pulling-out-a-drive-from-raid1-volume-created-on-two-sata-drive.patch
This is a note to let you know that I've just added the patch titled
scsi: lpfc: PLOGI failures during NPIV testing
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-lpfc-plogi-failures-during-npiv-testing.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Dick Kennedy <dick.kennedy(a)broadcom.com>
Date: Fri, 29 Sep 2017 17:34:32 -0700
Subject: scsi: lpfc: PLOGI failures during NPIV testing
From: Dick Kennedy <dick.kennedy(a)broadcom.com>
[ Upstream commit e8bcf0ae4c0346fdc78ebefe0eefcaa6a6622d38 ]
Local Reject/Invalid RPI errors seen during discovery.
Temporary RPI cleanup was occurring regardless of SLI rev. It's only
necessary on SLI-4.
Adjust the test for whether cleanup is necessary.
Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com>
Signed-off-by: James Smart <james.smart(a)broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/lpfc/lpfc_hbadisc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/scsi/lpfc/lpfc_hbadisc.c
+++ b/drivers/scsi/lpfc/lpfc_hbadisc.c
@@ -4983,7 +4983,8 @@ lpfc_nlp_remove(struct lpfc_vport *vport
lpfc_cancel_retry_delay_tmo(vport, ndlp);
if ((ndlp->nlp_flag & NLP_DEFER_RM) &&
!(ndlp->nlp_flag & NLP_REG_LOGIN_SEND) &&
- !(ndlp->nlp_flag & NLP_RPI_REGISTERED)) {
+ !(ndlp->nlp_flag & NLP_RPI_REGISTERED) &&
+ phba->sli_rev != LPFC_SLI_REV4) {
/* For this case we need to cleanup the default rpi
* allocated by the firmware.
*/
Patches currently in stable-queue which might be from dick.kennedy(a)broadcom.com are
queue-4.14/scsi-lpfc-fix-warning-messages-when-nvme_target_fc-not-defined.patch
queue-4.14/scsi-lpfc-plogi-failures-during-npiv-testing.patch
queue-4.14/scsi-lpfc-fix-secure-firmware-updates.patch
This is a note to let you know that I've just added the patch titled
scsi: lpfc: Fix warning messages when NVME_TARGET_FC not defined
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-lpfc-fix-warning-messages-when-nvme_target_fc-not-defined.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Dick Kennedy <dick.kennedy(a)broadcom.com>
Date: Fri, 29 Sep 2017 17:34:31 -0700
Subject: scsi: lpfc: Fix warning messages when NVME_TARGET_FC not defined
From: Dick Kennedy <dick.kennedy(a)broadcom.com>
[ Upstream commit 2299e4323d2bf6e0728fdc6b9e8e9704978d2dd7 ]
Warning messages when NVME_TARGET_FC not defined on ppc builds
The lpfc_nvmet_replenish_context() function is only meaningful when NVME
target mode enabled. Surround the function body with ifdefs for target
mode enablement.
Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com>
Signed-off-by: James Smart <james.smart(a)broadcom.com>
Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au>
Reviewed-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/lpfc/lpfc_nvmet.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/scsi/lpfc/lpfc_nvmet.c
+++ b/drivers/scsi/lpfc/lpfc_nvmet.c
@@ -1464,6 +1464,7 @@ static struct lpfc_nvmet_ctxbuf *
lpfc_nvmet_replenish_context(struct lpfc_hba *phba,
struct lpfc_nvmet_ctx_info *current_infop)
{
+#if (IS_ENABLED(CONFIG_NVME_TARGET_FC))
struct lpfc_nvmet_ctxbuf *ctx_buf = NULL;
struct lpfc_nvmet_ctx_info *get_infop;
int i;
@@ -1511,6 +1512,7 @@ lpfc_nvmet_replenish_context(struct lpfc
get_infop = get_infop->nvmet_ctx_next_cpu;
}
+#endif
/* Nothing found, all contexts for the MRQ are in-flight */
return NULL;
}
Patches currently in stable-queue which might be from dick.kennedy(a)broadcom.com are
queue-4.14/scsi-lpfc-fix-warning-messages-when-nvme_target_fc-not-defined.patch
queue-4.14/scsi-lpfc-plogi-failures-during-npiv-testing.patch
queue-4.14/scsi-lpfc-fix-secure-firmware-updates.patch
This is a note to let you know that I've just added the patch titled
scsi: lpfc: Fix secure firmware updates
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-lpfc-fix-secure-firmware-updates.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Dick Kennedy <dick.kennedy(a)broadcom.com>
Date: Fri, 29 Sep 2017 17:34:42 -0700
Subject: scsi: lpfc: Fix secure firmware updates
From: Dick Kennedy <dick.kennedy(a)broadcom.com>
[ Upstream commit 184fc2b9a8bcbda9c14d0a1e7fbecfc028c7702e ]
Firmware update fails with: status x17 add_status x56 on the final write
If multiple DMA buffers are used for the download, some firmware revs
have difficulty with signatures and crcs split across the dma buffer
boundaries. Resolve by making all writes be a single 4k page in length.
Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com>
Signed-off-by: James Smart <james.smart(a)broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/lpfc/lpfc_hw4.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/lpfc/lpfc_hw4.h
+++ b/drivers/scsi/lpfc/lpfc_hw4.h
@@ -3636,7 +3636,7 @@ struct lpfc_mbx_get_port_name {
#define MB_CEQ_STATUS_QUEUE_FLUSHING 0x4
#define MB_CQE_STATUS_DMA_FAILED 0x5
-#define LPFC_MBX_WR_CONFIG_MAX_BDE 8
+#define LPFC_MBX_WR_CONFIG_MAX_BDE 1
struct lpfc_mbx_wr_object {
struct mbox_header header;
union {
Patches currently in stable-queue which might be from dick.kennedy(a)broadcom.com are
queue-4.14/scsi-lpfc-fix-warning-messages-when-nvme_target_fc-not-defined.patch
queue-4.14/scsi-lpfc-plogi-failures-during-npiv-testing.patch
queue-4.14/scsi-lpfc-fix-secure-firmware-updates.patch
This is a note to let you know that I've just added the patch titled
scsi: cxgb4i: fix Tx skb leak
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-cxgb4i-fix-tx-skb-leak.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Varun Prakash <varun(a)chelsio.com>
Date: Wed, 11 Oct 2017 19:33:07 +0530
Subject: scsi: cxgb4i: fix Tx skb leak
From: Varun Prakash <varun(a)chelsio.com>
[ Upstream commit 9b3a081fb62158b50bcc90522ca2423017544367 ]
In case of connection reset Tx skb queue can have some skbs which are
not transmitted so purge Tx skb queue in release_offload_resources() to
avoid skb leak.
Signed-off-by: Varun Prakash <varun(a)chelsio.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -1575,6 +1575,7 @@ static void release_offload_resources(st
csk, csk->state, csk->flags, csk->tid);
cxgbi_sock_free_cpl_skbs(csk);
+ cxgbi_sock_purge_write_queue(csk);
if (csk->wr_cred != csk->wr_max_cred) {
cxgbi_sock_purge_wr_queue(csk);
cxgbi_sock_reset_wr_list(csk);
Patches currently in stable-queue which might be from varun(a)chelsio.com are
queue-4.14/scsi-cxgb4i-fix-tx-skb-leak.patch
This is a note to let you know that I've just added the patch titled
rtc: pl031: make interrupt optional
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rtc-pl031-make-interrupt-optional.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Russell King <rmk+kernel(a)armlinux.org.uk>
Date: Fri, 29 Sep 2017 11:22:15 +0100
Subject: rtc: pl031: make interrupt optional
From: Russell King <rmk+kernel(a)armlinux.org.uk>
[ Upstream commit 5b64a2965dfdfca8039e93303c64e2b15c19ff0c ]
On some platforms, the interrupt for the PL031 is optional. Avoid
trying to claim the interrupt if it's not specified.
Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/rtc/rtc-pl031.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/rtc/rtc-pl031.c
@@ -308,7 +308,8 @@ static int pl031_remove(struct amba_devi
dev_pm_clear_wake_irq(&adev->dev);
device_init_wakeup(&adev->dev, false);
- free_irq(adev->irq[0], ldata);
+ if (adev->irq[0])
+ free_irq(adev->irq[0], ldata);
rtc_device_unregister(ldata->rtc);
iounmap(ldata->base);
kfree(ldata);
@@ -381,12 +382,13 @@ static int pl031_probe(struct amba_devic
goto out_no_rtc;
}
- if (request_irq(adev->irq[0], pl031_interrupt,
- vendor->irqflags, "rtc-pl031", ldata)) {
- ret = -EIO;
- goto out_no_irq;
+ if (adev->irq[0]) {
+ ret = request_irq(adev->irq[0], pl031_interrupt,
+ vendor->irqflags, "rtc-pl031", ldata);
+ if (ret)
+ goto out_no_irq;
+ dev_pm_set_wake_irq(&adev->dev, adev->irq[0]);
}
- dev_pm_set_wake_irq(&adev->dev, adev->irq[0]);
return 0;
out_no_irq:
Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are
queue-4.14/rtc-pl031-make-interrupt-optional.patch
This is a note to let you know that I've just added the patch titled
rtc: set the alarm to the next expiring timer
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rtc-set-the-alarm-to-the-next-expiring-timer.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Alexandre Belloni <alexandre.belloni(a)free-electrons.com>
Date: Thu, 28 Sep 2017 13:53:27 +0200
Subject: rtc: set the alarm to the next expiring timer
From: Alexandre Belloni <alexandre.belloni(a)free-electrons.com>
[ Upstream commit 74717b28cb32e1ad3c1042cafd76b264c8c0f68d ]
If there is any non expired timer in the queue, the RTC alarm is never set.
This is an issue when adding a timer that expires before the next non
expired timer.
Ensure the RTC alarm is set in that case.
Fixes: 2b2f5ff00f63 ("rtc: interface: ignore expired timers when enqueuing new timers")
Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/rtc/interface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -779,7 +779,7 @@ static int rtc_timer_enqueue(struct rtc_
}
timerqueue_add(&rtc->timerqueue, &timer->node);
- if (!next) {
+ if (!next || ktime_before(timer->node.expires, next->expires)) {
struct rtc_wkalrm alarm;
int err;
alarm.time = rtc_ktime_to_tm(timer->node.expires);
Patches currently in stable-queue which might be from alexandre.belloni(a)free-electrons.com are
queue-4.14/rtc-set-the-alarm-to-the-next-expiring-timer.patch
queue-4.14/rtc-pl031-make-interrupt-optional.patch
This is a note to let you know that I've just added the patch titled
RDMA/hns: Avoid NULL pointer exception
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-hns-avoid-null-pointer-exception.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: "Wei Hu(Xavier)" <xavier.huwei(a)huawei.com>
Date: Fri, 29 Sep 2017 23:10:12 +0800
Subject: RDMA/hns: Avoid NULL pointer exception
From: "Wei Hu(Xavier)" <xavier.huwei(a)huawei.com>
[ Upstream commit 5e437b1d7e8d31ff9a4b8e898eb3a6cee309edd9 ]
After the loop in hns_roce_v1_mr_free_work_fn function, it is possible that
all qps will have been freed (in which case ne will be 0). If that
happens, then later in the function when we dereference hr_qp we will
get an exception. Check ne is not 0 to make sure we actually have an
hr_qp left to work on.
This patch fixes the smatch error as below:
drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1009 hns_roce_v1_mr_free_work_fn()
error: we previously assumed 'hr_qp' could be null
Signed-off-by: Wei Hu (Xavier) <xavier.huwei(a)huawei.com>
Signed-off-by: Lijun Ou <oulijun(a)huawei.com>
Signed-off-by: Shaobo Xu <xushaobo2(a)huawei.com>
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/hns/hns_roce_hw_v1.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
@@ -1001,6 +1001,11 @@ static void hns_roce_v1_mr_free_work_fn(
}
}
+ if (!ne) {
+ dev_err(dev, "Reseved loop qp is absent!\n");
+ goto free_work;
+ }
+
do {
ret = hns_roce_v1_poll_cq(&mr_free_cq->ib_cq, ne, wc);
if (ret < 0) {
Patches currently in stable-queue which might be from xavier.huwei(a)huawei.com are
queue-4.14/rdma-hns-avoid-null-pointer-exception.patch
This is a note to let you know that I've just added the patch titled
powerpc/xmon: Avoid tripping SMP hardlockup watchdog
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-xmon-avoid-tripping-smp-hardlockup-watchdog.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Fri, 29 Sep 2017 13:29:40 +1000
Subject: powerpc/xmon: Avoid tripping SMP hardlockup watchdog
From: Nicholas Piggin <npiggin(a)gmail.com>
[ Upstream commit 064996d62a33ffe10264b5af5dca92d54f60f806 ]
The SMP hardlockup watchdog cross-checks other CPUs for lockups, which
causes xmon headaches because it's assuming interrupts hard disabled
means no watchdog troubles. Try to improve that by calling
touch_nmi_watchdog() in obvious places where secondaries are spinning.
Also annotate these spin loops with spin_begin/end calls.
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.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/xmon/xmon.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -530,14 +530,19 @@ static int xmon_core(struct pt_regs *reg
waiting:
secondary = 1;
+ spin_begin();
while (secondary && !xmon_gate) {
if (in_xmon == 0) {
- if (fromipi)
+ if (fromipi) {
+ spin_end();
goto leave;
+ }
secondary = test_and_set_bit(0, &in_xmon);
}
- barrier();
+ spin_cpu_relax();
+ touch_nmi_watchdog();
}
+ spin_end();
if (!secondary && !xmon_gate) {
/* we are the first cpu to come in */
@@ -568,21 +573,25 @@ static int xmon_core(struct pt_regs *reg
mb();
xmon_gate = 1;
barrier();
+ touch_nmi_watchdog();
}
cmdloop:
while (in_xmon) {
if (secondary) {
+ spin_begin();
if (cpu == xmon_owner) {
if (!test_and_set_bit(0, &xmon_taken)) {
secondary = 0;
+ spin_end();
continue;
}
/* missed it */
while (cpu == xmon_owner)
- barrier();
+ spin_cpu_relax();
}
- barrier();
+ spin_cpu_relax();
+ touch_nmi_watchdog();
} else {
cmd = cmds(regs);
if (cmd != 0) {
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.14/cpuidle-fix-broadcast-control-when-broadcast-can-not-be-entered.patch
queue-4.14/powerpc-xmon-avoid-tripping-smp-hardlockup-watchdog.patch
queue-4.14/powerpc-watchdog-do-not-trigger-smp-crash-from-touch_nmi_watchdog.patch
This is a note to let you know that I've just added the patch titled
powerpc/watchdog: Do not trigger SMP crash from touch_nmi_watchdog
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-watchdog-do-not-trigger-smp-crash-from-touch_nmi_watchdog.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Fri, 29 Sep 2017 13:29:39 +1000
Subject: powerpc/watchdog: Do not trigger SMP crash from touch_nmi_watchdog
From: Nicholas Piggin <npiggin(a)gmail.com>
[ Upstream commit 80e4d70b06863e0104e5a0dc78aa3710297fbd4b ]
In xmon, touch_nmi_watchdog() is not expected to be checking that
other CPUs have not touched the watchdog, so the code will just call
touch_nmi_watchdog() once before re-enabling hard interrupts.
Just update our CPU's state, and ignore apparently stuck SMP threads.
Arguably touch_nmi_watchdog should check for SMP lockups, and callers
should be fixed, but that's not trivial for the input code of xmon.
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.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/kernel/watchdog.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/arch/powerpc/kernel/watchdog.c
+++ b/arch/powerpc/kernel/watchdog.c
@@ -276,9 +276,12 @@ void arch_touch_nmi_watchdog(void)
{
unsigned long ticks = tb_ticks_per_usec * wd_timer_period_ms * 1000;
int cpu = smp_processor_id();
+ u64 tb = get_tb();
- if (get_tb() - per_cpu(wd_timer_tb, cpu) >= ticks)
- watchdog_timer_interrupt(cpu);
+ if (tb - per_cpu(wd_timer_tb, cpu) >= ticks) {
+ per_cpu(wd_timer_tb, cpu) = tb;
+ wd_smp_clear_cpu_pending(cpu, tb);
+ }
}
EXPORT_SYMBOL(arch_touch_nmi_watchdog);
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.14/cpuidle-fix-broadcast-control-when-broadcast-can-not-be-entered.patch
queue-4.14/powerpc-xmon-avoid-tripping-smp-hardlockup-watchdog.patch
queue-4.14/powerpc-watchdog-do-not-trigger-smp-crash-from-touch_nmi_watchdog.patch
This is a note to let you know that I've just added the patch titled
PM / OPP: Move error message to debug level
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pm-opp-move-error-message-to-debug-level.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Fabio Estevam <fabio.estevam(a)nxp.com>
Date: Fri, 29 Sep 2017 14:39:49 -0300
Subject: PM / OPP: Move error message to debug level
From: Fabio Estevam <fabio.estevam(a)nxp.com>
[ Upstream commit 035ed07208dc501d023873447113f3f178592156 ]
On some i.MX6 platforms which do not have speed grading
check, opp table will not be created in platform code,
so cpufreq driver prints the following error message:
cpu cpu0: dev_pm_opp_get_opp_count: OPP table not found (-19)
However, this is not really an error in this case because the
imx6q-cpufreq driver first calls dev_pm_opp_get_opp_count()
and if it fails, it means that platform code does not provide
OPP and then dev_pm_opp_of_add_table() will be called.
In order to avoid such confusing error message, move it to
debug level.
It is up to the caller of dev_pm_opp_get_opp_count() to check its
return value and decide if it will print an error or not.
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/power/opp/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -296,7 +296,7 @@ int dev_pm_opp_get_opp_count(struct devi
opp_table = _find_opp_table(dev);
if (IS_ERR(opp_table)) {
count = PTR_ERR(opp_table);
- dev_err(dev, "%s: OPP table not found (%d)\n",
+ dev_dbg(dev, "%s: OPP table not found (%d)\n",
__func__, count);
return count;
}
Patches currently in stable-queue which might be from fabio.estevam(a)nxp.com are
queue-4.14/pm-opp-move-error-message-to-debug-level.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.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-create-sr-iov-virtfn-physfn-links-before-attaching-driver.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 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
@@ -162,7 +162,6 @@ int pci_iov_add_virtfn(struct pci_dev *d
pci_device_add(virtfn, virtfn->bus);
- pci_bus_add_device(virtfn);
sprintf(buf, "virtfn%u", id);
rc = sysfs_create_link(&dev->dev.kobj, &virtfn->dev.kobj, buf);
if (rc)
@@ -173,6 +172,8 @@ int pci_iov_add_virtfn(struct pci_dev *d
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.14/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: Avoid bus reset if bridge itself is broken
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-avoid-bus-reset-if-bridge-itself-is-broken.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 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
@@ -4356,6 +4356,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.14/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/AER: Report non-fatal errors only to the affected endpoint
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-aer-report-non-fatal-errors-only-to-the-affected-endpoint.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 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
@@ -390,7 +390,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.14/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
optee: fix invalid of_node_put() in optee_driver_init()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
optee-fix-invalid-of_node_put-in-optee_driver_init.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f044113113dd95ba73916bde10e804d3cdfa2662 Mon Sep 17 00:00:00 2001
From: Jens Wiklander <jens.wiklander(a)linaro.org>
Date: Mon, 9 Oct 2017 11:11:49 +0200
Subject: optee: fix invalid of_node_put() in optee_driver_init()
From: Jens Wiklander <jens.wiklander(a)linaro.org>
commit f044113113dd95ba73916bde10e804d3cdfa2662 upstream.
The first node supplied to of_find_matching_node() has its reference
counter decreased as part of call to that function. In optee_driver_init()
after calling of_find_matching_node() it's invalid to call of_node_put() on
the supplied node again.
So remove the invalid call to of_node_put().
Reported-by: Alex Shi <alex.shi(a)linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org>
Cc: <andi(a)linux-stable.l.notmuch.email>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tee/optee/core.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -590,7 +590,6 @@ static int __init optee_driver_init(void
return -ENODEV;
np = of_find_matching_node(fw_np, optee_match);
- of_node_put(fw_np);
if (!np)
return -ENODEV;
Patches currently in stable-queue which might be from jens.wiklander(a)linaro.org are
queue-4.14/optee-fix-invalid-of_node_put-in-optee_driver_init.patch
This is a note to let you know that I've just added the patch titled
net: ipv6: send NS for DAD when link operationally up
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-ipv6-send-ns-for-dad-when-link-operationally-up.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Mike Manning <mmanning(a)brocade.com>
Date: Mon, 25 Sep 2017 22:01:36 +0100
Subject: net: ipv6: send NS for DAD when link operationally up
From: Mike Manning <mmanning(a)brocade.com>
[ Upstream commit 1f372c7bfb23286d2bf4ce0423ab488e86b74bb2 ]
The NS for DAD are sent on admin up as long as a valid qdisc is found.
A race condition exists by which these packets will not egress the
interface if the operational state of the lower device is not yet up.
The solution is to delay DAD until the link is operationally up
according to RFC2863. Rather than only doing this, follow the existing
code checks by deferring IPv6 device initialization altogether. The fix
allows DAD on devices like tunnels that are controlled by userspace
control plane. The fix has no impact on regular deployments, but means
that there is no IPv6 connectivity until the port has been opened in
the case of port-based network access control, which should be
desirable.
Signed-off-by: Mike Manning <mmanning(a)brocade.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/addrconf.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -303,10 +303,10 @@ static struct ipv6_devconf ipv6_devconf_
.disable_policy = 0,
};
-/* Check if a valid qdisc is available */
-static inline bool addrconf_qdisc_ok(const struct net_device *dev)
+/* Check if link is ready: is it up and is a valid qdisc available */
+static inline bool addrconf_link_ready(const struct net_device *dev)
{
- return !qdisc_tx_is_noop(dev);
+ return netif_oper_up(dev) && !qdisc_tx_is_noop(dev);
}
static void addrconf_del_rs_timer(struct inet6_dev *idev)
@@ -451,7 +451,7 @@ static struct inet6_dev *ipv6_add_dev(st
ndev->token = in6addr_any;
- if (netif_running(dev) && addrconf_qdisc_ok(dev))
+ if (netif_running(dev) && addrconf_link_ready(dev))
ndev->if_flags |= IF_READY;
ipv6_mc_init_dev(ndev);
@@ -3404,7 +3404,7 @@ static int addrconf_notify(struct notifi
/* restore routes for permanent addresses */
addrconf_permanent_addr(dev);
- if (!addrconf_qdisc_ok(dev)) {
+ if (!addrconf_link_ready(dev)) {
/* device is not ready yet. */
pr_info("ADDRCONF(NETDEV_UP): %s: link is not ready\n",
dev->name);
@@ -3419,7 +3419,7 @@ static int addrconf_notify(struct notifi
run_pending = 1;
}
} else if (event == NETDEV_CHANGE) {
- if (!addrconf_qdisc_ok(dev)) {
+ if (!addrconf_link_ready(dev)) {
/* device is still not ready. */
break;
}
Patches currently in stable-queue which might be from mmanning(a)brocade.com are
queue-4.14/net-ipv6-send-ns-for-dad-when-link-operationally-up.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.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-phy-at803x-change-error-to-einval-for-invalid-mac.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 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
@@ -167,7 +167,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.14/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
md: always set THREAD_WAKEUP and wake up wqueue if thread existed
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
md-always-set-thread_wakeup-and-wake-up-wqueue-if-thread-existed.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Guoqing Jiang <gqjiang(a)suse.com>
Date: Mon, 9 Oct 2017 10:32:48 +0800
Subject: md: always set THREAD_WAKEUP and wake up wqueue if thread existed
From: Guoqing Jiang <gqjiang(a)suse.com>
[ Upstream commit d1d90147c9680aaec4a5757932c2103c42c9c23b ]
Since commit 4ad23a976413 ("MD: use per-cpu counter for writes_pending"),
the wait_queue is only got invoked if THREAD_WAKEUP is not set previously.
With above change, I can see process_metadata_update could always hang on
the wait queue, because mddev->thread could stay on 'D' status and the
THREAD_WAKEUP flag is not cleared since there are lots of place to wake up
mddev->thread. Then deadlock happened as follows:
linux175:~ # ps aux|grep md|grep D
root 20117 0.0 0.0 0 0 ? D 03:45 0:00 [md0_raid1]
root 20125 0.0 0.0 0 0 ? D 03:45 0:00 [md0_cluster_rec]
linux175:~ # cat /proc/20117/stack
[<ffffffffa0635604>] dlm_lock_sync+0x94/0xd0 [md_cluster]
[<ffffffffa0635674>] lock_token+0x34/0xd0 [md_cluster]
[<ffffffffa0635804>] metadata_update_start+0x64/0x110 [md_cluster]
[<ffffffffa04d985b>] md_update_sb.part.58+0x9b/0x860 [md_mod]
[<ffffffffa04da035>] md_update_sb+0x15/0x30 [md_mod]
[<ffffffffa04dc066>] md_check_recovery+0x266/0x490 [md_mod]
[<ffffffffa06450e2>] raid1d+0x42/0x810 [raid1]
[<ffffffffa04d2252>] md_thread+0x122/0x150 [md_mod]
[<ffffffff81091741>] kthread+0x101/0x140
linux175:~ # cat /proc/20125/stack
[<ffffffffa0636679>] recv_daemon+0x3f9/0x5c0 [md_cluster]
[<ffffffffa04d2252>] md_thread+0x122/0x150 [md_mod]
[<ffffffff81091741>] kthread+0x101/0x140
So let's revert the part of code in the commit to resovle the problem since
we can't get lots of benefits of previous change.
Fixes: 4ad23a976413 ("MD: use per-cpu counter for writes_pending")
Signed-off-by: Guoqing Jiang <gqjiang(a)suse.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/md.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -7468,8 +7468,8 @@ void md_wakeup_thread(struct md_thread *
{
if (thread) {
pr_debug("md: waking up MD thread %s.\n", thread->tsk->comm);
- if (!test_and_set_bit(THREAD_WAKEUP, &thread->flags))
- wake_up(&thread->wqueue);
+ set_bit(THREAD_WAKEUP, &thread->flags);
+ wake_up(&thread->wqueue);
}
}
EXPORT_SYMBOL(md_wakeup_thread);
Patches currently in stable-queue which might be from gqjiang(a)suse.com are
queue-4.14/md-always-set-thread_wakeup-and-wake-up-wqueue-if-thread-existed.patch
This is a note to let you know that I've just added the patch titled
leds: pca955x: Don't invert requested value in pca955x_gpio_set_value()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
leds-pca955x-don-t-invert-requested-value-in-pca955x_gpio_set_value.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Andrew Jeffery <andrew(a)aj.id.au>
Date: Fri, 1 Sep 2017 15:08:58 +0930
Subject: leds: pca955x: Don't invert requested value in pca955x_gpio_set_value()
From: Andrew Jeffery <andrew(a)aj.id.au>
[ Upstream commit 52ca7d0f7bdad832b291ed979146443533ee79c0 ]
The PCA9552 lines can be used either for driving LEDs or as GPIOs. The
manual states that for LEDs, the operation is open-drain:
The LSn LED select registers determine the source of the LED data.
00 = output is set LOW (LED on)
01 = output is set high-impedance (LED off; default)
10 = output blinks at PWM0 rate
11 = output blinks at PWM1 rate
For GPIOs it suggests a pull-up so that the open-case drives the line
high:
For use as output, connect external pull-up resistor to the pin
and size it according to the DC recommended operating
characteristics. LED output pin is HIGH when the output is
programmed as high-impedance, and LOW when the output is
programmed LOW through the ‘LED selector’ register. The output
can be pulse-width controlled when PWM0 or PWM1 are used.
Now, I have a hardware design that uses the LED controller to control
LEDs. However, for $reasons, we're using the leds-gpio driver to drive
the them. The reasons are here are a tangent but lead to the discovery
of the inversion, which manifested as the LEDs being set to full
brightness at boot when we expected them to be off.
As we're driving the LEDs through leds-gpio, this means wending our way
through the gpiochip abstractions. So with that in mind we need to
describe an active-low GPIO configuration to drive the LEDs as though
they were GPIOs.
The set() gpiochip callback in leds-pca955x does the following:
...
if (val)
pca955x_led_set(&led->led_cdev, LED_FULL);
else
pca955x_led_set(&led->led_cdev, LED_OFF);
...
Where LED_FULL = 255. pca955x_led_set() in turn does:
...
switch (value) {
case LED_FULL:
ls = pca955x_ledsel(ls, ls_led, PCA955X_LS_LED_ON);
break;
...
Where PCA955X_LS_LED_ON is defined as:
#define PCA955X_LS_LED_ON 0x0 /* Output LOW */
So here we have some type confusion: We've crossed domains from GPIO
behaviour to LED behaviour without accounting for possible inversions
in the process.
Stepping back to leds-gpio for a moment, during probe() we call
create_gpio_led(), which eventually executes:
if (template->default_state == LEDS_GPIO_DEFSTATE_KEEP) {
state = gpiod_get_value_cansleep(led_dat->gpiod);
if (state < 0)
return state;
} else {
state = (template->default_state == LEDS_GPIO_DEFSTATE_ON);
}
...
ret = gpiod_direction_output(led_dat->gpiod, state);
In the devicetree the GPIO is annotated as active-low, and
gpiod_get_value_cansleep() handles this for us:
int gpiod_get_value_cansleep(const struct gpio_desc *desc)
{
int value;
might_sleep_if(extra_checks);
VALIDATE_DESC(desc);
value = _gpiod_get_raw_value(desc);
if (value < 0)
return value;
if (test_bit(FLAG_ACTIVE_LOW, &desc->flags))
value = !value;
return value;
}
_gpiod_get_raw_value() in turn calls through the get() callback for the
gpiochip implementation, so returning to our get() implementation in
leds-pca955x we find we extract the raw value from hardware:
static int pca955x_gpio_get_value(struct gpio_chip *gc, unsigned int offset)
{
struct pca955x *pca955x = gpiochip_get_data(gc);
struct pca955x_led *led = &pca955x->leds[offset];
u8 reg = pca955x_read_input(pca955x->client, led->led_num / 8);
return !!(reg & (1 << (led->led_num % 8)));
}
This behaviour is not symmetric with that of set(), where the val is
inverted by the driver.
Closing the loop on the GPIO_ACTIVE_LOW inversions,
gpiod_direction_output(), like gpiod_get_value_cansleep(), handles it
for us:
int gpiod_direction_output(struct gpio_desc *desc, int value)
{
VALIDATE_DESC(desc);
if (test_bit(FLAG_ACTIVE_LOW, &desc->flags))
value = !value;
else
value = !!value;
return _gpiod_direction_output_raw(desc, value);
}
All-in-all, with a value of 'keep' for default-state property in a
leds-gpio child node, the current state of the hardware will in-fact be
inverted; precisely the opposite of what was intended.
Rework leds-pca955x so that we avoid the incorrect inversion and clarify
the semantics with respect to GPIO.
Signed-off-by: Andrew Jeffery <andrew(a)aj.id.au>
Reviewed-by: Cédric Le Goater <clg(a)kaod.org>
Tested-by: Joel Stanley <joel(a)jms.id.au>
Tested-by: Matt Spinler <mspinler(a)linux.vnet.ibm.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/leds/leds-pca955x.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/drivers/leds/leds-pca955x.c
+++ b/drivers/leds/leds-pca955x.c
@@ -61,6 +61,10 @@
#define PCA955X_LS_BLINK0 0x2 /* Blink at PWM0 rate */
#define PCA955X_LS_BLINK1 0x3 /* Blink at PWM1 rate */
+#define PCA955X_GPIO_INPUT LED_OFF
+#define PCA955X_GPIO_HIGH LED_OFF
+#define PCA955X_GPIO_LOW LED_FULL
+
enum pca955x_type {
pca9550,
pca9551,
@@ -329,9 +333,9 @@ static int pca955x_set_value(struct gpio
struct pca955x_led *led = &pca955x->leds[offset];
if (val)
- return pca955x_led_set(&led->led_cdev, LED_FULL);
- else
- return pca955x_led_set(&led->led_cdev, LED_OFF);
+ return pca955x_led_set(&led->led_cdev, PCA955X_GPIO_HIGH);
+
+ return pca955x_led_set(&led->led_cdev, PCA955X_GPIO_LOW);
}
static void pca955x_gpio_set_value(struct gpio_chip *gc, unsigned int offset,
@@ -355,8 +359,11 @@ static int pca955x_gpio_get_value(struct
static int pca955x_gpio_direction_input(struct gpio_chip *gc,
unsigned int offset)
{
- /* To use as input ensure pin is not driven */
- return pca955x_set_value(gc, offset, 0);
+ struct pca955x *pca955x = gpiochip_get_data(gc);
+ struct pca955x_led *led = &pca955x->leds[offset];
+
+ /* To use as input ensure pin is not driven. */
+ return pca955x_led_set(&led->led_cdev, PCA955X_GPIO_INPUT);
}
static int pca955x_gpio_direction_output(struct gpio_chip *gc,
Patches currently in stable-queue which might be from andrew(a)aj.id.au are
queue-4.14/leds-pca955x-don-t-invert-requested-value-in-pca955x_gpio_set_value.patch
This is a note to let you know that I've just added the patch titled
kvm, mm: account kvm related kmem slabs to kmemcg
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-mm-account-kvm-related-kmem-slabs-to-kmemcg.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Shakeel Butt <shakeelb(a)google.com>
Date: Thu, 5 Oct 2017 18:07:24 -0700
Subject: kvm, mm: account kvm related kmem slabs to kmemcg
From: Shakeel Butt <shakeelb(a)google.com>
[ Upstream commit 46bea48ac241fe0b413805952dda74dd0c09ba8b ]
The kvm slabs can consume a significant amount of system memory
and indeed in our production environment we have observed that
a lot of machines are spending significant amount of memory that
can not be left as system memory overhead. Also the allocations
from these slabs can be triggered directly by user space applications
which has access to kvm and thus a buggy application can leak
such memory. So, these caches should be accounted to kmemcg.
Signed-off-by: Shakeel Butt <shakeelb(a)google.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/mmu.c | 4 ++--
virt/kvm/kvm_main.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -5476,13 +5476,13 @@ int kvm_mmu_module_init(void)
pte_list_desc_cache = kmem_cache_create("pte_list_desc",
sizeof(struct pte_list_desc),
- 0, 0, NULL);
+ 0, SLAB_ACCOUNT, NULL);
if (!pte_list_desc_cache)
goto nomem;
mmu_page_header_cache = kmem_cache_create("kvm_mmu_page_header",
sizeof(struct kvm_mmu_page),
- 0, 0, NULL);
+ 0, SLAB_ACCOUNT, NULL);
if (!mmu_page_header_cache)
goto nomem;
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -4018,7 +4018,7 @@ int kvm_init(void *opaque, unsigned vcpu
if (!vcpu_align)
vcpu_align = __alignof__(struct kvm_vcpu);
kvm_vcpu_cache = kmem_cache_create("kvm_vcpu", vcpu_size, vcpu_align,
- 0, NULL);
+ SLAB_ACCOUNT, NULL);
if (!kvm_vcpu_cache) {
r = -ENOMEM;
goto out_free_3;
Patches currently in stable-queue which might be from shakeelb(a)google.com are
queue-4.14/kvm-mm-account-kvm-related-kmem-slabs-to-kmemcg.patch
This is a note to let you know that I've just added the patch titled
ipv6: grab rt->rt6i_ref before allocating pcpu rt
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipv6-grab-rt-rt6i_ref-before-allocating-pcpu-rt.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Wei Wang <weiwan(a)google.com>
Date: Fri, 6 Oct 2017 12:06:04 -0700
Subject: ipv6: grab rt->rt6i_ref before allocating pcpu rt
From: Wei Wang <weiwan(a)google.com>
[ Upstream commit a94b9367e044ba672c9f4105eb1516ff6ff4948a ]
After rwlock is replaced with rcu and spinlock, ip6_pol_route() will be
called with only rcu held. That means rt6 route deletion could happen
simultaneously with rt6_make_pcpu_rt(). This could potentially cause
memory leak if rt6_release() is called right before rt6_make_pcpu_rt()
on the same route.
This patch grabs rt->rt6i_ref safely before calling rt6_make_pcpu_rt()
to make sure rt6_release() will not get triggered while
rt6_make_pcpu_rt() is in progress. And rt6_release() is called after
rt6_make_pcpu_rt() is finished.
Note: As we are incrementing rt->rt6i_ref in ip6_pol_route(), there is a
very slim chance that fib6_purge_rt() will be triggered unnecessarily
when deleting a route if ip6_pol_route() running on another thread picks
this route as well and tries to make pcpu cache for it.
Signed-off-by: Wei Wang <weiwan(a)google.com>
Signed-off-by: Martin KaFai Lau <kafai(a)fb.com>
Signed-off-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/ipv6/route.c | 58 +++++++++++++++++++++++++++----------------------------
1 file changed, 29 insertions(+), 29 deletions(-)
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1055,7 +1055,6 @@ static struct rt6_info *rt6_get_pcpu_rou
static struct rt6_info *rt6_make_pcpu_route(struct rt6_info *rt)
{
- struct fib6_table *table = rt->rt6i_table;
struct rt6_info *pcpu_rt, *prev, **p;
pcpu_rt = ip6_rt_pcpu_alloc(rt);
@@ -1066,28 +1065,20 @@ static struct rt6_info *rt6_make_pcpu_ro
return net->ipv6.ip6_null_entry;
}
- read_lock_bh(&table->tb6_lock);
- if (rt->rt6i_pcpu) {
- p = this_cpu_ptr(rt->rt6i_pcpu);
- prev = cmpxchg(p, NULL, pcpu_rt);
- if (prev) {
- /* If someone did it before us, return prev instead */
- dst_release_immediate(&pcpu_rt->dst);
- pcpu_rt = prev;
- }
- } else {
- /* rt has been removed from the fib6 tree
- * before we have a chance to acquire the read_lock.
- * In this case, don't brother to create a pcpu rt
- * since rt is going away anyway. The next
- * dst_check() will trigger a re-lookup.
- */
+ dst_hold(&pcpu_rt->dst);
+ p = this_cpu_ptr(rt->rt6i_pcpu);
+ prev = cmpxchg(p, NULL, pcpu_rt);
+ if (prev) {
+ /* If someone did it before us, return prev instead */
+ /* release refcnt taken by ip6_rt_pcpu_alloc() */
+ dst_release_immediate(&pcpu_rt->dst);
+ /* release refcnt taken by above dst_hold() */
dst_release_immediate(&pcpu_rt->dst);
- pcpu_rt = rt;
+ dst_hold(&prev->dst);
+ pcpu_rt = prev;
}
- dst_hold(&pcpu_rt->dst);
+
rt6_dst_from_metrics_check(pcpu_rt);
- read_unlock_bh(&table->tb6_lock);
return pcpu_rt;
}
@@ -1177,19 +1168,28 @@ redo_rt6_select:
if (pcpu_rt) {
read_unlock_bh(&table->tb6_lock);
} else {
- /* We have to do the read_unlock first
- * because rt6_make_pcpu_route() may trigger
- * ip6_dst_gc() which will take the write_lock.
- */
- dst_hold(&rt->dst);
- read_unlock_bh(&table->tb6_lock);
- pcpu_rt = rt6_make_pcpu_route(rt);
- dst_release(&rt->dst);
+ /* atomic_inc_not_zero() is needed when using rcu */
+ if (atomic_inc_not_zero(&rt->rt6i_ref)) {
+ /* We have to do the read_unlock first
+ * because rt6_make_pcpu_route() may trigger
+ * ip6_dst_gc() which will take the write_lock.
+ *
+ * No dst_hold() on rt is needed because grabbing
+ * rt->rt6i_ref makes sure rt can't be released.
+ */
+ read_unlock_bh(&table->tb6_lock);
+ pcpu_rt = rt6_make_pcpu_route(rt);
+ rt6_release(rt);
+ } else {
+ /* rt is already removed from tree */
+ read_unlock_bh(&table->tb6_lock);
+ pcpu_rt = net->ipv6.ip6_null_entry;
+ dst_hold(&pcpu_rt->dst);
+ }
}
trace_fib6_table_lookup(net, pcpu_rt, table->tb6_id, fl6);
return pcpu_rt;
-
}
}
EXPORT_SYMBOL_GPL(ip6_pol_route);
Patches currently in stable-queue which might be from weiwan(a)google.com are
queue-4.14/ipv6-grab-rt-rt6i_ref-before-allocating-pcpu-rt.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.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ixgbe-fix-use-of-uninitialized-padding.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 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
@@ -3781,10 +3781,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, &fw_cmd,
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -900,6 +900,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_hic_unlocked(hw, (u32 *)&buffer, sizeof(buffer),
IXGBE_HI_COMMAND_TIMEOUT);
Patches currently in stable-queue which might be from emil.s.tantilov(a)intel.com are
queue-4.14/ixgbe-fix-use-of-uninitialized-padding.patch
This is a note to let you know that I've just added the patch titled
ip_gre: check packet length and mtu correctly in erspan tx
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ip_gre-check-packet-length-and-mtu-correctly-in-erspan-tx.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: William Tu <u9012063(a)gmail.com>
Date: Thu, 5 Oct 2017 12:07:12 -0700
Subject: ip_gre: check packet length and mtu correctly in erspan tx
From: William Tu <u9012063(a)gmail.com>
[ Upstream commit f192970de860d3ab90aa9e2a22853201a57bde78 ]
Similarly to early patch for erspan_xmit(), the ARPHDR_ETHER device
is the length of the whole ether packet. So skb->len should subtract
the dev->hard_header_len.
Fixes: 1a66a836da63 ("gre: add collect_md mode to ERSPAN tunnel")
Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
Signed-off-by: William Tu <u9012063(a)gmail.com>
Cc: Xin Long <lucien.xin(a)gmail.com>
Cc: David Laight <David.Laight(a)aculab.com>
Reviewed-by: Xin Long <lucien.xin(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/ipv4/ip_gre.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -579,8 +579,8 @@ static void erspan_fb_xmit(struct sk_buf
if (gre_handle_offloads(skb, false))
goto err_free_rt;
- if (skb->len > dev->mtu) {
- pskb_trim(skb, dev->mtu);
+ if (skb->len > dev->mtu + dev->hard_header_len) {
+ pskb_trim(skb, dev->mtu + dev->hard_header_len);
truncate = true;
}
@@ -731,8 +731,8 @@ static netdev_tx_t erspan_xmit(struct sk
if (skb_cow_head(skb, dev->needed_headroom))
goto free_skb;
- if (skb->len - dev->hard_header_len > dev->mtu) {
- pskb_trim(skb, dev->mtu);
+ if (skb->len > dev->mtu + dev->hard_header_len) {
+ pskb_trim(skb, dev->mtu + dev->hard_header_len);
truncate = true;
}
Patches currently in stable-queue which might be from u9012063(a)gmail.com are
queue-4.14/ip_gre-check-packet-length-and-mtu-correctly-in-erspan-tx.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.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
igb-check-memory-allocation-failure.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 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
@@ -3162,6 +3162,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.14/crypto-lrw-fix-an-error-handling-path-in-create.patch
queue-4.14/igb-check-memory-allocation-failure.patch
This is a note to let you know that I've just added the patch titled
IB/rxe: check for allocation failure on elem
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-rxe-check-for-allocation-failure-on-elem.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Colin Ian King <colin.king(a)canonical.com>
Date: Fri, 8 Sep 2017 15:37:45 +0100
Subject: IB/rxe: check for allocation failure on elem
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 4831ca9e4a8e48cb27e0a792f73250390827a228 ]
The allocation for elem may fail (especially because we're using
GFP_ATOMIC) so best to check for a null return. This fixes a potential
null pointer dereference when assigning elem->pool.
Detected by CoverityScan CID#1357507 ("Dereference null return value")
Fixes: 8700e3e7c485 ("Soft RoCE driver")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
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/sw/rxe/rxe_pool.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/infiniband/sw/rxe/rxe_pool.c
+++ b/drivers/infiniband/sw/rxe/rxe_pool.c
@@ -404,6 +404,8 @@ void *rxe_alloc(struct rxe_pool *pool)
elem = kmem_cache_zalloc(pool_cache(pool),
(pool->flags & RXE_POOL_ATOMIC) ?
GFP_ATOMIC : GFP_KERNEL);
+ if (!elem)
+ return NULL;
elem->pool = pool;
kref_init(&elem->ref_cnt);
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.14/ib-rxe-check-for-allocation-failure-on-elem.patch
This is a note to let you know that I've just added the patch titled
ibmvnic: Set state UP
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ibmvnic-set-state-up.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Mick Tarsel <mjtarsel(a)linux.vnet.ibm.com>
Date: Thu, 28 Sep 2017 13:53:18 -0700
Subject: ibmvnic: Set state UP
From: Mick Tarsel <mjtarsel(a)linux.vnet.ibm.com>
[ Upstream commit e876a8a7e9dd89dc88c12ca2e81beb478dbe9897 ]
State is initially reported as UNKNOWN. Before register call
netif_carrier_off(). Once the device is opened, call netif_carrier_on() in
order to set the state to UP.
Signed-off-by: Mick Tarsel <mjtarsel(a)linux.vnet.ibm.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/ibm/ibmvnic.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -927,6 +927,7 @@ static int ibmvnic_open(struct net_devic
}
rc = __ibmvnic_open(netdev);
+ netif_carrier_on(netdev);
mutex_unlock(&adapter->reset_lock);
return rc;
@@ -3899,6 +3900,7 @@ static int ibmvnic_probe(struct vio_dev
if (rc)
goto ibmvnic_init_fail;
+ netif_carrier_off(netdev);
rc = register_netdev(netdev);
if (rc) {
dev_err(&dev->dev, "failed to register netdev rc=%d\n", rc);
Patches currently in stable-queue which might be from mjtarsel(a)linux.vnet.ibm.com are
queue-4.14/ibmvnic-set-state-up.patch
This is a note to let you know that I've just added the patch titled
i40e: use the safe hash table iterator when deleting mac filters
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i40e-use-the-safe-hash-table-iterator-when-deleting-mac-filters.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Lihong Yang <lihong.yang(a)intel.com>
Date: Thu, 7 Sep 2017 08:05:46 -0400
Subject: i40e: use the safe hash table iterator when deleting mac filters
From: Lihong Yang <lihong.yang(a)intel.com>
[ Upstream commit 784548c40d6f43eff2297220ad7800dc04be03c6 ]
This patch replaces hash_for_each function with hash_for_each_safe
when calling __i40e_del_filter. The hash_for_each_safe function is
the right one to use when iterating over a hash table to safely remove
a hash entry. Otherwise, incorrect values may be read from freed memory.
Detected by CoverityScan, CID 1402048 Read from pointer after free
Signed-off-by: Lihong Yang <lihong.yang(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/i40e/i40e_virtchnl_pf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -2779,6 +2779,7 @@ int i40e_ndo_set_vf_mac(struct net_devic
struct i40e_mac_filter *f;
struct i40e_vf *vf;
int ret = 0;
+ struct hlist_node *h;
int bkt;
/* validate the request */
@@ -2817,7 +2818,7 @@ int i40e_ndo_set_vf_mac(struct net_devic
/* Delete all the filters for this VSI - we're going to kill it
* anyway.
*/
- hash_for_each(vsi->mac_filter_hash, bkt, f, hlist)
+ hash_for_each_safe(vsi->mac_filter_hash, bkt, h, f, hlist)
__i40e_del_filter(vsi, f);
spin_unlock_bh(&vsi->mac_filter_hash_lock);
Patches currently in stable-queue which might be from lihong.yang(a)intel.com are
queue-4.14/i40e-use-the-safe-hash-table-iterator-when-deleting-mac-filters.patch
This is a note to let you know that I've just added the patch titled
IB/opa_vnic: Properly return the total MACs in UC MAC list
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-opa_vnic-properly-return-the-total-macs-in-uc-mac-list.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Niranjana Vishwanathapura <niranjana.vishwanathapura(a)intel.com>
Date: Tue, 26 Sep 2017 06:44:07 -0700
Subject: IB/opa_vnic: Properly return the total MACs in UC MAC list
From: Niranjana Vishwanathapura <niranjana.vishwanathapura(a)intel.com>
[ Upstream commit b77eb45e0d9c324245d165656ab3b38b6f386436 ]
Do not include EM specified MAC address in total MACs of the
UC MAC list.
Reviewed-by: Sudeep Dutt <sudeep.dutt(a)intel.com>
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura(a)intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com>
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/ulp/opa_vnic/opa_vnic_vema_iface.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/infiniband/ulp/opa_vnic/opa_vnic_vema_iface.c
+++ b/drivers/infiniband/ulp/opa_vnic/opa_vnic_vema_iface.c
@@ -348,7 +348,7 @@ void opa_vnic_query_mcast_macs(struct op
void opa_vnic_query_ucast_macs(struct opa_vnic_adapter *adapter,
struct opa_veswport_iface_macs *macs)
{
- u16 start_idx, tot_macs, num_macs, idx = 0, count = 0;
+ u16 start_idx, tot_macs, num_macs, idx = 0, count = 0, em_macs = 0;
struct netdev_hw_addr *ha;
start_idx = be16_to_cpu(macs->start_idx);
@@ -359,8 +359,10 @@ void opa_vnic_query_ucast_macs(struct op
/* Do not include EM specified MAC address */
if (!memcmp(adapter->info.vport.base_mac_addr, ha->addr,
- ARRAY_SIZE(adapter->info.vport.base_mac_addr)))
+ ARRAY_SIZE(adapter->info.vport.base_mac_addr))) {
+ em_macs++;
continue;
+ }
if (start_idx > idx++)
continue;
@@ -383,7 +385,7 @@ void opa_vnic_query_ucast_macs(struct op
}
tot_macs = netdev_hw_addr_list_count(&adapter->netdev->dev_addrs) +
- netdev_uc_count(adapter->netdev);
+ netdev_uc_count(adapter->netdev) - em_macs;
macs->tot_macs_in_lst = cpu_to_be16(tot_macs);
macs->num_macs_in_msg = cpu_to_be16(count);
macs->gen_count = cpu_to_be16(adapter->info.vport.uc_macs_gen_count);
Patches currently in stable-queue which might be from niranjana.vishwanathapura(a)intel.com are
queue-4.14/ib-opa_vnic-properly-clear-mac-table-digest.patch
queue-4.14/ib-opa_vnic-properly-return-the-total-macs-in-uc-mac-list.patch
This is a note to let you know that I've just added the patch titled
IB/opa_vnic: Properly clear Mac Table Digest
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-opa_vnic-properly-clear-mac-table-digest.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Scott Franco <safranco(a)intel.com>
Date: Tue, 26 Sep 2017 06:44:13 -0700
Subject: IB/opa_vnic: Properly clear Mac Table Digest
From: Scott Franco <safranco(a)intel.com>
[ Upstream commit 4bbdfe25600c1909c26747d0b5c39fd0e409bb87 ]
Clear the MAC table digest when the MAC table is freed.
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura(a)intel.com>
Signed-off-by: Scott Franco <safranco(a)intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com>
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/ulp/opa_vnic/opa_vnic_encap.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/infiniband/ulp/opa_vnic/opa_vnic_encap.c
+++ b/drivers/infiniband/ulp/opa_vnic/opa_vnic_encap.c
@@ -139,6 +139,7 @@ void opa_vnic_release_mac_tbl(struct opa
rcu_assign_pointer(adapter->mactbl, NULL);
synchronize_rcu();
opa_vnic_free_mac_tbl(mactbl);
+ adapter->info.vport.mac_tbl_digest = 0;
mutex_unlock(&adapter->mactbl_lock);
}
Patches currently in stable-queue which might be from safranco(a)intel.com are
queue-4.14/ib-opa_vnic-properly-clear-mac-table-digest.patch
This is a note to let you know that I've just added the patch titled
i40e/i40evf: spread CPU affinity hints across online CPUs only
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i40e-i40evf-spread-cpu-affinity-hints-across-online-cpus-only.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Jacob Keller <jacob.e.keller(a)intel.com>
Date: Tue, 29 Aug 2017 05:32:31 -0400
Subject: i40e/i40evf: spread CPU affinity hints across online CPUs only
From: Jacob Keller <jacob.e.keller(a)intel.com>
[ Upstream commit be664cbefc50977aaefc868ba6a1109ec9b7449d ]
Currently, when setting up the IRQ for a q_vector, we set an affinity
hint based on the v_idx of that q_vector. Meaning a loop iterates on
v_idx, which is an incremental value, and the cpumask is created based
on this value.
This is a problem in systems with multiple logical CPUs per core (like in
simultaneous multithreading (SMT) scenarios). If we disable some logical
CPUs, by turning SMT off for example, we will end up with a sparse
cpu_online_mask, i.e., only the first CPU in a core is online, and
incremental filling in q_vector cpumask might lead to multiple offline
CPUs being assigned to q_vectors.
Example: if we have a system with 8 cores each one containing 8 logical
CPUs (SMT == 8 in this case), we have 64 CPUs in total. But if SMT is
disabled, only the 1st CPU in each core remains online, so the
cpu_online_mask in this case would have only 8 bits set, in a sparse way.
In general case, when SMT is off the cpu_online_mask has only C bits set:
0, 1*N, 2*N, ..., C*(N-1) where
C == # of cores;
N == # of logical CPUs per core.
In our example, only bits 0, 8, 16, 24, 32, 40, 48, 56 would be set.
Instead, we should only assign hints for CPUs which are online. Even
better, the kernel already provides a function, cpumask_local_spread()
which takes an index and returns a CPU, spreading the interrupts across
local NUMA nodes first, and then remote ones if necessary.
Since we generally have a 1:1 mapping between vectors and CPUs, there
is no real advantage to spreading vectors to local CPUs first. In order
to avoid mismatch of the default XPS hints, we'll pass -1 so that it
spreads across all CPUs without regard to the node locality.
Note that we don't need to change the q_vector->affinity_mask as this is
initialized to cpu_possible_mask, until an actual affinity is set and
then notified back to us.
Signed-off-by: Jacob Keller <jacob.e.keller(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/i40e/i40e_main.c | 16 +++++++++++-----
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 9 ++++++---
2 files changed, 17 insertions(+), 8 deletions(-)
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -2874,14 +2874,15 @@ static void i40e_vsi_free_rx_resources(s
static void i40e_config_xps_tx_ring(struct i40e_ring *ring)
{
struct i40e_vsi *vsi = ring->vsi;
+ int cpu;
if (!ring->q_vector || !ring->netdev)
return;
if ((vsi->tc_config.numtc <= 1) &&
!test_and_set_bit(__I40E_TX_XPS_INIT_DONE, &ring->state)) {
- netif_set_xps_queue(ring->netdev,
- get_cpu_mask(ring->q_vector->v_idx),
+ cpu = cpumask_local_spread(ring->q_vector->v_idx, -1);
+ netif_set_xps_queue(ring->netdev, get_cpu_mask(cpu),
ring->queue_index);
}
@@ -3471,6 +3472,7 @@ static int i40e_vsi_request_irq_msix(str
int tx_int_idx = 0;
int vector, err;
int irq_num;
+ int cpu;
for (vector = 0; vector < q_vectors; vector++) {
struct i40e_q_vector *q_vector = vsi->q_vectors[vector];
@@ -3506,10 +3508,14 @@ static int i40e_vsi_request_irq_msix(str
q_vector->affinity_notify.notify = i40e_irq_affinity_notify;
q_vector->affinity_notify.release = i40e_irq_affinity_release;
irq_set_affinity_notifier(irq_num, &q_vector->affinity_notify);
- /* get_cpu_mask returns a static constant mask with
- * a permanent lifetime so it's ok to use here.
+ /* Spread affinity hints out across online CPUs.
+ *
+ * get_cpu_mask returns a static constant mask with
+ * a permanent lifetime so it's ok to pass to
+ * irq_set_affinity_hint without making a copy.
*/
- irq_set_affinity_hint(irq_num, get_cpu_mask(q_vector->v_idx));
+ cpu = cpumask_local_spread(q_vector->v_idx, -1);
+ irq_set_affinity_hint(irq_num, get_cpu_mask(cpu));
}
vsi->irqs_ready = true;
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -546,6 +546,7 @@ i40evf_request_traffic_irqs(struct i40ev
unsigned int vector, q_vectors;
unsigned int rx_int_idx = 0, tx_int_idx = 0;
int irq_num, err;
+ int cpu;
i40evf_irq_disable(adapter);
/* Decrement for Other and TCP Timer vectors */
@@ -584,10 +585,12 @@ i40evf_request_traffic_irqs(struct i40ev
q_vector->affinity_notify.release =
i40evf_irq_affinity_release;
irq_set_affinity_notifier(irq_num, &q_vector->affinity_notify);
- /* get_cpu_mask returns a static constant mask with
- * a permanent lifetime so it's ok to use here.
+ /* Spread the IRQ affinity hints across online CPUs. Note that
+ * get_cpu_mask returns a mask with a permanent lifetime so
+ * it's safe to use as a hint for irq_set_affinity_hint.
*/
- irq_set_affinity_hint(irq_num, get_cpu_mask(q_vector->v_idx));
+ cpu = cpumask_local_spread(q_vector->v_idx, -1);
+ irq_set_affinity_hint(irq_num, get_cpu_mask(cpu));
}
return 0;
Patches currently in stable-queue which might be from jacob.e.keller(a)intel.com are
queue-4.14/fm10k-fix-mis-ordered-parameters-in-declaration-for-.ndo_set_vf_bw.patch
queue-4.14/fm10k-ensure-we-process-sm-mbx-when-processing-vf-mbx.patch
queue-4.14/i40e-i40evf-spread-cpu-affinity-hints-across-online-cpus-only.patch
This is a note to let you know that I've just added the patch titled
i40e: fix client notify of VF reset
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i40e-fix-client-notify-of-vf-reset.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Alan Brady <alan.brady(a)intel.com>
Date: Tue, 22 Aug 2017 06:57:53 -0400
Subject: i40e: fix client notify of VF reset
From: Alan Brady <alan.brady(a)intel.com>
[ Upstream commit c53d11f669c0e7d0daf46a717b6712ad0b09de99 ]
Currently there is a bug in which the PF driver fails to inform clients
of a VF reset which then causes clients to leak resources. The bug
exists because we were incorrectly checking the I40E_VF_STATE_PRE_ENABLE
bit.
When a VF is first init we go through a reset to initialize variables
and allocate resources but we don't want to inform clients of this first
reset since the client isn't fully enabled yet so we set a state bit
signifying we're in a "pre-enabled" client state. During the first
reset we should be clearing the bit, allowing all following resets to
notify the client of the reset when the bit is not set. This patch
fixes the issue by negating the 'test_and_clear_bit' check to accurately
reflect the behavior we want.
Signed-off-by: Alan Brady <alan.brady(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/i40e/i40e_virtchnl_pf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -1008,8 +1008,8 @@ static void i40e_cleanup_reset_vf(struct
set_bit(I40E_VF_STATE_ACTIVE, &vf->vf_states);
clear_bit(I40E_VF_STATE_DISABLED, &vf->vf_states);
/* Do not notify the client during VF init */
- if (test_and_clear_bit(I40E_VF_STATE_PRE_ENABLE,
- &vf->vf_states))
+ if (!test_and_clear_bit(I40E_VF_STATE_PRE_ENABLE,
+ &vf->vf_states))
i40e_notify_client_of_vf_reset(pf, abs_vf_id);
vf->num_vlan = 0;
}
Patches currently in stable-queue which might be from alan.brady(a)intel.com are
queue-4.14/i40e-fix-client-notify-of-vf-reset.patch
This is a note to let you know that I've just added the patch titled
fm10k: fix mis-ordered parameters in declaration for .ndo_set_vf_bw
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
fm10k-fix-mis-ordered-parameters-in-declaration-for-.ndo_set_vf_bw.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Jacob Keller <jacob.e.keller(a)intel.com>
Date: Fri, 11 Aug 2017 11:14:58 -0700
Subject: fm10k: fix mis-ordered parameters in declaration for .ndo_set_vf_bw
From: Jacob Keller <jacob.e.keller(a)intel.com>
[ Upstream commit 3e256ac5b1ec307e5dd5a4c99fbdbc651446c738 ]
We've had support for setting both a minimum and maximum bandwidth via
.ndo_set_vf_bw since commit 883a9ccbae56 ("fm10k: Add support for SR-IOV
to driver", 2014-09-20).
Likely because we do not support minimum rates, the declaration
mis-ordered the "unused" parameter, which causes warnings when analyzed
with cppcheck.
Fix this warning by properly declaring the min_rate and max_rate
variables in the declaration and definition (rather than using
"unused"). Also rename "rate" to max_rate so as to clarify that we only
support setting the maximum rate.
Signed-off-by: Jacob Keller <jacob.e.keller(a)intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh(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/fm10k/fm10k.h | 4 ++--
drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 9 +++++----
2 files changed, 7 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/intel/fm10k/fm10k.h
+++ b/drivers/net/ethernet/intel/fm10k/fm10k.h
@@ -526,8 +526,8 @@ s32 fm10k_iov_update_pvid(struct fm10k_i
int fm10k_ndo_set_vf_mac(struct net_device *netdev, int vf_idx, u8 *mac);
int fm10k_ndo_set_vf_vlan(struct net_device *netdev,
int vf_idx, u16 vid, u8 qos, __be16 vlan_proto);
-int fm10k_ndo_set_vf_bw(struct net_device *netdev, int vf_idx, int rate,
- int unused);
+int fm10k_ndo_set_vf_bw(struct net_device *netdev, int vf_idx,
+ int __always_unused min_rate, int max_rate);
int fm10k_ndo_get_vf_config(struct net_device *netdev,
int vf_idx, struct ifla_vf_info *ivi);
--- a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
@@ -482,7 +482,7 @@ int fm10k_ndo_set_vf_vlan(struct net_dev
}
int fm10k_ndo_set_vf_bw(struct net_device *netdev, int vf_idx,
- int __always_unused unused, int rate)
+ int __always_unused min_rate, int max_rate)
{
struct fm10k_intfc *interface = netdev_priv(netdev);
struct fm10k_iov_data *iov_data = interface->iov_data;
@@ -493,14 +493,15 @@ int fm10k_ndo_set_vf_bw(struct net_devic
return -EINVAL;
/* rate limit cannot be less than 10Mbs or greater than link speed */
- if (rate && ((rate < FM10K_VF_TC_MIN) || rate > FM10K_VF_TC_MAX))
+ if (max_rate &&
+ (max_rate < FM10K_VF_TC_MIN || max_rate > FM10K_VF_TC_MAX))
return -EINVAL;
/* store values */
- iov_data->vf_info[vf_idx].rate = rate;
+ iov_data->vf_info[vf_idx].rate = max_rate;
/* update hardware configuration */
- hw->iov.ops.configure_tc(hw, vf_idx, rate);
+ hw->iov.ops.configure_tc(hw, vf_idx, max_rate);
return 0;
}
Patches currently in stable-queue which might be from jacob.e.keller(a)intel.com are
queue-4.14/fm10k-fix-mis-ordered-parameters-in-declaration-for-.ndo_set_vf_bw.patch
queue-4.14/fm10k-ensure-we-process-sm-mbx-when-processing-vf-mbx.patch
queue-4.14/i40e-i40evf-spread-cpu-affinity-hints-across-online-cpus-only.patch
This is a note to let you know that I've just added the patch titled
fm10k: ensure we process SM mbx when processing VF mbx
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
fm10k-ensure-we-process-sm-mbx-when-processing-vf-mbx.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Jacob Keller <jacob.e.keller(a)intel.com>
Date: Mon, 2 Oct 2017 07:17:50 -0700
Subject: fm10k: ensure we process SM mbx when processing VF mbx
From: Jacob Keller <jacob.e.keller(a)intel.com>
[ Upstream commit 17a91809942ca32c70026d2d5ba3348a2c4fdf8f ]
When we process VF mailboxes, the driver is likely going to also queue
up messages to the switch manager. This process merely queues up the
FIFO, but doesn't actually begin the transmission process. Because we
hold the mailbox lock during this VF processing, the PF<->SM mailbox is
not getting processed at this time. Ensure that we actually process the
PF<->SM mailbox in between each PF<->VF mailbox.
This should ensure prompt transmission of the messages queued up after
each VF message is received and handled.
Signed-off-by: Jacob Keller <jacob.e.keller(a)intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh(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/fm10k/fm10k_iov.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
@@ -126,6 +126,9 @@ process_mbx:
struct fm10k_mbx_info *mbx = &vf_info->mbx;
u16 glort = vf_info->glort;
+ /* process the SM mailbox first to drain outgoing messages */
+ hw->mbx.ops.process(hw, &hw->mbx);
+
/* verify port mapping is valid, if not reset port */
if (vf_info->vf_flags && !fm10k_glort_valid_pf(hw, glort))
hw->iov.ops.reset_lport(hw, vf_info);
Patches currently in stable-queue which might be from jacob.e.keller(a)intel.com are
queue-4.14/fm10k-fix-mis-ordered-parameters-in-declaration-for-.ndo_set_vf_bw.patch
queue-4.14/fm10k-ensure-we-process-sm-mbx-when-processing-vf-mbx.patch
queue-4.14/i40e-i40evf-spread-cpu-affinity-hints-across-online-cpus-only.patch
This is a note to let you know that I've just added the patch titled
drm/vc4: Avoid using vrefresh==0 mode in DSI htotal math.
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-vc4-avoid-using-vrefresh-0-mode-in-dsi-htotal-math.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Eric Anholt <eric(a)anholt.net>
Date: Tue, 15 Aug 2017 16:47:19 -0700
Subject: drm/vc4: Avoid using vrefresh==0 mode in DSI htotal math.
From: Eric Anholt <eric(a)anholt.net>
[ Upstream commit af2eca53206c59ce9308a4f5f46c4a104a179b6b ]
The incoming mode might have a missing vrefresh field if it came from
drmModeSetCrtc(), which the kernel is supposed to calculate using
drm_mode_vrefresh(). We could either use that or the adjusted_mode's
original vrefresh value.
However, we can maintain a more exact vrefresh value (not just the
integer approximation), by scaling by the ratio of our clocks.
v2: Use math suggested by Andrzej Hajda instead.
v3: Simplify math now that adjusted_mode->clock isn't padded.
v4: Drop some parens.
Signed-off-by: Eric Anholt <eric(a)anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20170815234722.20700-2-eric@a…
Reviewed-by: Andrzej Hajda <a.hajda(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/vc4/vc4_dsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -866,7 +866,8 @@ static bool vc4_dsi_encoder_mode_fixup(s
adjusted_mode->clock = pixel_clock_hz / 1000 + 1;
/* Given the new pixel clock, adjust HFP to keep vrefresh the same. */
- adjusted_mode->htotal = pixel_clock_hz / (mode->vrefresh * mode->vtotal);
+ adjusted_mode->htotal = adjusted_mode->clock * mode->htotal /
+ mode->clock;
adjusted_mode->hsync_end += adjusted_mode->htotal - mode->htotal;
adjusted_mode->hsync_start += adjusted_mode->htotal - mode->htotal;
Patches currently in stable-queue which might be from eric(a)anholt.net are
queue-4.14/drm-vc4-avoid-using-vrefresh-0-mode-in-dsi-htotal-math.patch
This is a note to let you know that I've just added the patch titled
crypto: lrw - Fix an error handling path in 'create()'
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-lrw-fix-an-error-handling-path-in-create.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Christophe Jaillet <christophe.jaillet(a)wanadoo.fr>
Date: Sun, 8 Oct 2017 11:39:49 +0200
Subject: crypto: lrw - Fix an error handling path in 'create()'
From: Christophe Jaillet <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 616129cc6e75fb4da6681c16c981fa82dfe5e4c7 ]
All error handling paths 'goto err_drop_spawn' except this one.
In order to avoid some resources leak, we should do it as well here.
Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher")
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
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>
---
crypto/lrw.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -610,8 +610,10 @@ static int create(struct crypto_template
ecb_name[len - 1] = 0;
if (snprintf(inst->alg.base.cra_name, CRYPTO_MAX_ALG_NAME,
- "lrw(%s)", ecb_name) >= CRYPTO_MAX_ALG_NAME)
- return -ENAMETOOLONG;
+ "lrw(%s)", ecb_name) >= CRYPTO_MAX_ALG_NAME) {
+ err = -ENAMETOOLONG;
+ goto err_drop_spawn;
+ }
}
inst->alg.base.cra_flags = alg->base.cra_flags & CRYPTO_ALG_ASYNC;
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.14/crypto-lrw-fix-an-error-handling-path-in-create.patch
queue-4.14/igb-check-memory-allocation-failure.patch
This is a note to let you know that I've just added the patch titled
drm: Add retries for lspcon mode detection
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-add-retries-for-lspcon-mode-detection.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Shashank Sharma <shashank.sharma(a)intel.com>
Date: Thu, 12 Oct 2017 22:10:08 +0530
Subject: drm: Add retries for lspcon mode detection
From: Shashank Sharma <shashank.sharma(a)intel.com>
[ Upstream commit f687e25a7a245952349f1f9f9cc238ac5a3be258 ]
>From the CI builds, its been observed that during a driver
reload/insert, dp dual mode read function sometimes fails to
read from LSPCON device over i2c-over-aux channel.
This patch:
- adds some delay and few retries, allowing a scope for these
devices to settle down and respond.
- changes one error log's level from ERROR->DEBUG as we want
to call it an error only after all the retries are exhausted.
V2: Addressed review comments from Jani (for loop for retry)
V3: Addressed review comments from Imre (break on partial read too)
V3: Addressed review comments from Ville/Imre (Add the retries
exclusively for LSPCON, not for all dp_dual_mode devices)
V4: Added r-b from Imre, sending it to dri-devel (Jani)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102294
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102295
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102359
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103186
Cc: Ville Syrjala <ville.syrjala(a)linux.intel.com>
Cc: Imre Deak <imre.deak(a)intel.com>
Cc: Jani Nikula <jani.nikula(a)linux.intel.com>
Reviewed-by: Imre Deak <imre.deak(a)intel.com>
Acked-by: Dave Airlie <airlied(a)gmail.com>
Signed-off-by: Shashank Sharma <shashank.sharma(a)intel.com>
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1507826408-19322-1-git-send-e…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -410,6 +410,7 @@ int drm_lspcon_get_mode(struct i2c_adapt
{
u8 data;
int ret = 0;
+ int retry;
if (!mode) {
DRM_ERROR("NULL input\n");
@@ -417,10 +418,19 @@ int drm_lspcon_get_mode(struct i2c_adapt
}
/* Read Status: i2c over aux */
- ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_LSPCON_CURRENT_MODE,
- &data, sizeof(data));
+ for (retry = 0; retry < 6; retry++) {
+ if (retry)
+ usleep_range(500, 1000);
+
+ ret = drm_dp_dual_mode_read(adapter,
+ DP_DUAL_MODE_LSPCON_CURRENT_MODE,
+ &data, sizeof(data));
+ if (!ret)
+ break;
+ }
+
if (ret < 0) {
- DRM_ERROR("LSPCON read(0x80, 0x41) failed\n");
+ DRM_DEBUG_KMS("LSPCON read(0x80, 0x41) failed\n");
return -EFAULT;
}
Patches currently in stable-queue which might be from shashank.sharma(a)intel.com are
queue-4.14/drm-add-retries-for-lspcon-mode-detection.patch
This is a note to let you know that I've just added the patch titled
crypto: crypto4xx - increase context and scatter ring buffer elements
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-crypto4xx-increase-context-and-scatter-ring-buffer-elements.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Christian Lamparter <chunkeey(a)gmail.com>
Date: Wed, 4 Oct 2017 01:00:08 +0200
Subject: crypto: crypto4xx - increase context and scatter ring buffer elements
From: Christian Lamparter <chunkeey(a)gmail.com>
[ Upstream commit 778f81d6cdb7d25360f082ac0384d5103f04eca5 ]
If crypto4xx is used in conjunction with dm-crypt, the available
ring buffer elements are not enough to handle the load properly.
On an aes-cbc-essiv:sha256 encrypted swap partition the read
performance is abyssal: (tested with hdparm -t)
/dev/mapper/swap_crypt:
Timing buffered disk reads: 14 MB in 3.68 seconds = 3.81 MB/sec
The patch increases both PPC4XX_NUM_SD and PPC4XX_NUM_PD to 256.
This improves the performance considerably:
/dev/mapper/swap_crypt:
Timing buffered disk reads: 104 MB in 3.03 seconds = 34.31 MB/sec
Furthermore, PPC4XX_LAST_SD, PPC4XX_LAST_GD and PPC4XX_LAST_PD
can be easily calculated from their respective PPC4XX_NUM_*
constant.
Signed-off-by: Christian Lamparter <chunkeey(a)gmail.com>
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/amcc/crypto4xx_core.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/crypto/amcc/crypto4xx_core.h
+++ b/drivers/crypto/amcc/crypto4xx_core.h
@@ -34,12 +34,12 @@
#define PPC405EX_CE_RESET 0x00000008
#define CRYPTO4XX_CRYPTO_PRIORITY 300
-#define PPC4XX_LAST_PD 63
-#define PPC4XX_NUM_PD 64
-#define PPC4XX_LAST_GD 1023
+#define PPC4XX_NUM_PD 256
+#define PPC4XX_LAST_PD (PPC4XX_NUM_PD - 1)
#define PPC4XX_NUM_GD 1024
-#define PPC4XX_LAST_SD 63
-#define PPC4XX_NUM_SD 64
+#define PPC4XX_LAST_GD (PPC4XX_NUM_GD - 1)
+#define PPC4XX_NUM_SD 256
+#define PPC4XX_LAST_SD (PPC4XX_NUM_SD - 1)
#define PPC4XX_SD_BUFFER_SIZE 2048
#define PD_ENTRY_INUSE 1
Patches currently in stable-queue which might be from chunkeey(a)gmail.com are
queue-4.14/crypto-crypto4xx-increase-context-and-scatter-ring-buffer-elements.patch
This is a note to let you know that I've just added the patch titled
cpuidle: fix broadcast control when broadcast can not be entered
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
cpuidle-fix-broadcast-control-when-broadcast-can-not-be-entered.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Fri, 1 Sep 2017 14:29:56 +1000
Subject: cpuidle: fix broadcast control when broadcast can not be entered
From: Nicholas Piggin <npiggin(a)gmail.com>
[ Upstream commit f187851b9b4a76952b1158b86434563dd2031103 ]
When failing to enter broadcast timer mode for an idle state that
requires it, a new state is selected that does not require broadcast,
but the broadcast variable remains set. This causes
tick_broadcast_exit to be called despite not having entered broadcast
mode.
This causes the WARN_ON_ONCE(!irqs_disabled()) to trigger in some
cases. It does not appear to cause problems for code today, but seems
to violate the interface so should be fixed.
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/cpuidle/cpuidle.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -208,6 +208,7 @@ int cpuidle_enter_state(struct cpuidle_d
return -EBUSY;
}
target_state = &drv->states[index];
+ broadcast = false;
}
/* Take note of the planned idle state. */
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.14/cpuidle-fix-broadcast-control-when-broadcast-can-not-be-entered.patch
queue-4.14/powerpc-xmon-avoid-tripping-smp-hardlockup-watchdog.patch
queue-4.14/powerpc-watchdog-do-not-trigger-smp-crash-from-touch_nmi_watchdog.patch
This is a note to let you know that I've just added the patch titled
clk: sunxi-ng: sun5i: Fix bit offset of audio PLL post-divider
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-sunxi-ng-sun5i-fix-bit-offset-of-audio-pll-post-divider.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Chen-Yu Tsai <wens(a)csie.org>
Date: Thu, 12 Oct 2017 16:36:57 +0800
Subject: clk: sunxi-ng: sun5i: Fix bit offset of audio PLL post-divider
From: Chen-Yu Tsai <wens(a)csie.org>
[ Upstream commit d51fe3ba9773c8b6fc79f82bbe75d64baf604292 ]
The post-divider for the audio PLL is in bits [29:26], as specified
in the user manual, not [19:16] as currently programmed in the code.
The post-divider has a default register value of 2, i.e. a divider
of 3. This means the clock rate fed to the audio codec would be off.
This was discovered when porting sigma-delta modulation for the PLL
to sun5i, which needs the post-divider to be 1.
Fix the bit offset, so we do actually force the post-divider to a
certain value.
Fixes: 5e73761786d6 ("clk: sunxi-ng: Add sun5i CCU driver")
Signed-off-by: Chen-Yu Tsai <wens(a)csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/sunxi-ng/ccu-sun5i.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/clk/sunxi-ng/ccu-sun5i.c
+++ b/drivers/clk/sunxi-ng/ccu-sun5i.c
@@ -982,8 +982,8 @@ static void __init sun5i_ccu_init(struct
/* Force the PLL-Audio-1x divider to 4 */
val = readl(reg + SUN5I_PLL_AUDIO_REG);
- val &= ~GENMASK(19, 16);
- writel(val | (3 << 16), reg + SUN5I_PLL_AUDIO_REG);
+ val &= ~GENMASK(29, 26);
+ writel(val | (3 << 26), reg + SUN5I_PLL_AUDIO_REG);
/*
* Use the peripheral PLL as the AHB parent, instead of CPU /
Patches currently in stable-queue which might be from wens(a)csie.org are
queue-4.14/clk-sunxi-ng-nm-check-if-requested-rate-is-supported-by-fractional-clock.patch
queue-4.14/clk-sunxi-ng-sun6i-rename-hdmi-ddc-clock-to-avoid-name-collision.patch
queue-4.14/clk-sunxi-ng-sun5i-fix-bit-offset-of-audio-pll-post-divider.patch
This is a note to let you know that I've just added the patch titled
clk: sunxi-ng: sun6i: Rename HDMI DDC clock to avoid name collision
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-sunxi-ng-sun6i-rename-hdmi-ddc-clock-to-avoid-name-collision.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Chen-Yu Tsai <wens(a)csie.org>
Date: Fri, 29 Sep 2017 16:22:54 +0800
Subject: clk: sunxi-ng: sun6i: Rename HDMI DDC clock to avoid name collision
From: Chen-Yu Tsai <wens(a)csie.org>
[ Upstream commit 7f3ed79188f2f094d0ee366fa858857fb7f511ba ]
The HDMI DDC clock found in the CCU is the parent of the actual DDC
clock within the HDMI controller. That clock is also named "hdmi-ddc".
Rename the one in the CCU to "ddc". This makes more sense than renaming
the one in the HDMI controller to something else.
Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
Signed-off-by: Chen-Yu Tsai <wens(a)csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -608,7 +608,7 @@ static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_cl
0x150, 0, 4, 24, 2, BIT(31),
CLK_SET_RATE_PARENT);
-static SUNXI_CCU_GATE(hdmi_ddc_clk, "hdmi-ddc", "osc24M", 0x150, BIT(30), 0);
+static SUNXI_CCU_GATE(hdmi_ddc_clk, "ddc", "osc24M", 0x150, BIT(30), 0);
static SUNXI_CCU_GATE(ps_clk, "ps", "lcd1-ch1", 0x140, BIT(31), 0);
Patches currently in stable-queue which might be from wens(a)csie.org are
queue-4.14/clk-sunxi-ng-nm-check-if-requested-rate-is-supported-by-fractional-clock.patch
queue-4.14/clk-sunxi-ng-sun6i-rename-hdmi-ddc-clock-to-avoid-name-collision.patch
queue-4.14/clk-sunxi-ng-sun5i-fix-bit-offset-of-audio-pll-post-divider.patch
This is a note to let you know that I've just added the patch titled
clk: sunxi-ng: nm: Check if requested rate is supported by fractional clock
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-sunxi-ng-nm-check-if-requested-rate-is-supported-by-fractional-clock.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Chen-Yu Tsai <wens(a)csie.org>
Date: Thu, 12 Oct 2017 16:36:58 +0800
Subject: clk: sunxi-ng: nm: Check if requested rate is supported by fractional clock
From: Chen-Yu Tsai <wens(a)csie.org>
[ Upstream commit 4cdbc40d64d4b8303a97e29a52862e4d99502beb ]
The round_rate callback for N-M-factor style clocks does not check if
the requested clock rate is supported by the fractional clock mode.
While this doesn't affect usage in practice, since the clock rates
are also supported through N-M factors, it does not match the set_rate
code.
Add a check to the round_rate callback so it matches the set_rate
callback.
Fixes: 6174a1e24b0d ("clk: sunxi-ng: Add N-M-factor clock support")
Signed-off-by: Chen-Yu Tsai <wens(a)csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/sunxi-ng/ccu_nm.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/clk/sunxi-ng/ccu_nm.c
+++ b/drivers/clk/sunxi-ng/ccu_nm.c
@@ -99,6 +99,9 @@ static long ccu_nm_round_rate(struct clk
struct ccu_nm *nm = hw_to_ccu_nm(hw);
struct _ccu_nm _nm;
+ if (ccu_frac_helper_has_rate(&nm->common, &nm->frac, rate))
+ return rate;
+
_nm.min_n = nm->n.min ?: 1;
_nm.max_n = nm->n.max ?: 1 << nm->n.width;
_nm.min_m = 1;
Patches currently in stable-queue which might be from wens(a)csie.org are
queue-4.14/clk-sunxi-ng-nm-check-if-requested-rate-is-supported-by-fractional-clock.patch
queue-4.14/clk-sunxi-ng-sun6i-rename-hdmi-ddc-clock-to-avoid-name-collision.patch
queue-4.14/clk-sunxi-ng-sun5i-fix-bit-offset-of-audio-pll-post-divider.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: hci_bcm: Fix setting of irq trigger type
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-hci_bcm-fix-setting-of-irq-trigger-type.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 4 Oct 2017 20:43:36 +0200
Subject: Bluetooth: hci_bcm: Fix setting of irq trigger type
From: Hans de Goede <hdegoede(a)redhat.com>
[ Upstream commit 227630cccdbb8f8a1b24ac26517b75079c9a69c9 ]
This commit fixes 2 issues with host-wake irq trigger type handling
in hci_bcm:
1) bcm_setup_sleep sets sleep_params.host_wake_active based on
bcm_device.irq_polarity, but bcm_request_irq was always requesting
IRQF_TRIGGER_RISING as trigger type independent of irq_polarity.
This was a problem when the irq is described as a GpioInt rather then
an Interrupt in the DSDT as for GpioInt-s the value passed to request_irq
is honored. This commit fixes this by requesting the correct trigger
type depending on bcm_device.irq_polarity.
2) bcm_device.irq_polarity was used to directly store an ACPI polarity
value (ACPI_ACTIVE_*). This is undesirable because hci_bcm is also
used with device-tree and checking for something like ACPI_ACTIVE_LOW
in a non ACPI specific function like bcm_request_irq feels wrong.
This commit fixes this by renaming irq_polarity to irq_active_low
and changing its type to a bool.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/hci_bcm.c | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -68,7 +68,7 @@ struct bcm_device {
u32 init_speed;
u32 oper_speed;
int irq;
- u8 irq_polarity;
+ bool irq_active_low;
#ifdef CONFIG_PM
struct hci_uart *hu;
@@ -213,7 +213,9 @@ static int bcm_request_irq(struct bcm_da
}
err = devm_request_irq(&bdev->pdev->dev, bdev->irq, bcm_host_wake,
- IRQF_TRIGGER_RISING, "host_wake", bdev);
+ bdev->irq_active_low ? IRQF_TRIGGER_FALLING :
+ IRQF_TRIGGER_RISING,
+ "host_wake", bdev);
if (err)
goto unlock;
@@ -253,7 +255,7 @@ static int bcm_setup_sleep(struct hci_ua
struct sk_buff *skb;
struct bcm_set_sleep_mode sleep_params = default_sleep_params;
- sleep_params.host_wake_active = !bcm->dev->irq_polarity;
+ sleep_params.host_wake_active = !bcm->dev->irq_active_low;
skb = __hci_cmd_sync(hu->hdev, 0xfc27, sizeof(sleep_params),
&sleep_params, HCI_INIT_TIMEOUT);
@@ -690,10 +692,8 @@ static const struct acpi_gpio_mapping ac
};
#ifdef CONFIG_ACPI
-static u8 acpi_active_low = ACPI_ACTIVE_LOW;
-
/* IRQ polarity of some chipsets are not defined correctly in ACPI table. */
-static const struct dmi_system_id bcm_wrong_irq_dmi_table[] = {
+static const struct dmi_system_id bcm_active_low_irq_dmi_table[] = {
{
.ident = "Asus T100TA",
.matches = {
@@ -701,7 +701,6 @@ static const struct dmi_system_id bcm_wr
"ASUSTeK COMPUTER INC."),
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100TA"),
},
- .driver_data = &acpi_active_low,
},
{
.ident = "Asus T100CHI",
@@ -710,7 +709,6 @@ static const struct dmi_system_id bcm_wr
"ASUSTeK COMPUTER INC."),
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100CHI"),
},
- .driver_data = &acpi_active_low,
},
{ /* Handle ThinkPad 8 tablets with BCM2E55 chipset ACPI ID */
.ident = "Lenovo ThinkPad 8",
@@ -718,7 +716,6 @@ static const struct dmi_system_id bcm_wr
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "ThinkPad 8"),
},
- .driver_data = &acpi_active_low,
},
{ }
};
@@ -733,13 +730,13 @@ static int bcm_resource(struct acpi_reso
switch (ares->type) {
case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
irq = &ares->data.extended_irq;
- dev->irq_polarity = irq->polarity;
+ dev->irq_active_low = irq->polarity == ACPI_ACTIVE_LOW;
break;
case ACPI_RESOURCE_TYPE_GPIO:
gpio = &ares->data.gpio;
if (gpio->connection_type == ACPI_RESOURCE_GPIO_TYPE_INT)
- dev->irq_polarity = gpio->polarity;
+ dev->irq_active_low = gpio->polarity == ACPI_ACTIVE_LOW;
break;
case ACPI_RESOURCE_TYPE_SERIAL_BUS:
@@ -834,11 +831,11 @@ static int bcm_acpi_probe(struct bcm_dev
return ret;
acpi_dev_free_resource_list(&resources);
- dmi_id = dmi_first_match(bcm_wrong_irq_dmi_table);
+ dmi_id = dmi_first_match(bcm_active_low_irq_dmi_table);
if (dmi_id) {
bt_dev_warn(dev, "%s: Overwriting IRQ polarity to active low",
dmi_id->ident);
- dev->irq_polarity = *(u8 *)dmi_id->driver_data;
+ dev->irq_active_low = true;
}
return 0;
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.14/bluetooth-hci_uart_set_flow_control-fix-null-deref-when-using-serdev.patch
queue-4.14/bluetooth-hci_bcm-fix-setting-of-irq-trigger-type.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: hci_uart_set_flow_control: Fix NULL deref when using serdev
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-hci_uart_set_flow_control-fix-null-deref-when-using-serdev.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 4 Oct 2017 20:43:35 +0200
Subject: Bluetooth: hci_uart_set_flow_control: Fix NULL deref when using serdev
From: Hans de Goede <hdegoede(a)redhat.com>
[ Upstream commit 7841d554809b518a22349e7e39b6b63f8a48d0fb ]
Fix a NULL pointer deref (hu->tty) when calling hci_uart_set_flow_control
on hci_uart-s using serdev.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/hci_ldisc.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -41,6 +41,7 @@
#include <linux/ioctl.h>
#include <linux/skbuff.h>
#include <linux/firmware.h>
+#include <linux/serdev.h>
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
@@ -298,6 +299,12 @@ void hci_uart_set_flow_control(struct hc
unsigned int set = 0;
unsigned int clear = 0;
+ if (hu->serdev) {
+ serdev_device_set_flow_control(hu->serdev, !enable);
+ serdev_device_set_rts(hu->serdev, !enable);
+ return;
+ }
+
if (enable) {
/* Disable hardware flow control */
ktermios = tty->termios;
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.14/bluetooth-hci_uart_set_flow_control-fix-null-deref-when-using-serdev.patch
queue-4.14/bluetooth-hci_bcm-fix-setting-of-irq-trigger-type.patch
This is a note to let you know that I've just added the patch titled
block,bfq: Disable writeback throttling
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
block-bfq-disable-writeback-throttling.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Luca Miccio <lucmiccio(a)gmail.com>
Date: Mon, 9 Oct 2017 16:27:21 +0200
Subject: block,bfq: Disable writeback throttling
From: Luca Miccio <lucmiccio(a)gmail.com>
[ Upstream commit b5dc5d4d1f4ff9032eb6c21a3c571a1317dc9289 ]
Similarly to CFQ, BFQ has its write-throttling heuristics, and it
is better not to combine them with further write-throttling
heuristics of a different nature.
So this commit disables write-back throttling for a device if BFQ
is used as I/O scheduler for that device.
Signed-off-by: Luca Miccio <lucmiccio(a)gmail.com>
Signed-off-by: Paolo Valente <paolo.valente(a)linaro.org>
Tested-by: Oleksandr Natalenko <oleksandr(a)natalenko.name>
Tested-by: Lee Tibbert <lee.tibbert(a)gmail.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/bfq-iosched.c | 3 ++-
block/blk-wbt.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -108,6 +108,7 @@
#include "blk-mq-tag.h"
#include "blk-mq-sched.h"
#include "bfq-iosched.h"
+#include "blk-wbt.h"
#define BFQ_BFQQ_FNS(name) \
void bfq_mark_bfqq_##name(struct bfq_queue *bfqq) \
@@ -4775,7 +4776,7 @@ static int bfq_init_queue(struct request
bfq_init_root_group(bfqd->root_group, bfqd);
bfq_init_entity(&bfqd->oom_bfqq.entity, bfqd->root_group);
-
+ wbt_disable_default(q);
return 0;
out_free:
--- a/block/blk-wbt.c
+++ b/block/blk-wbt.c
@@ -654,7 +654,7 @@ void wbt_set_write_cache(struct rq_wb *r
}
/*
- * Disable wbt, if enabled by default. Only called from CFQ.
+ * Disable wbt, if enabled by default.
*/
void wbt_disable_default(struct request_queue *q)
{
Patches currently in stable-queue which might be from lucmiccio(a)gmail.com are
queue-4.14/block-bfq-disable-writeback-throttling.patch
This is a note to let you know that I've just added the patch titled
backlight: pwm_bl: Fix overflow condition
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
backlight-pwm_bl-fix-overflow-condition.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Derek Basehore <dbasehore(a)chromium.org>
Date: Tue, 29 Aug 2017 13:34:34 -0700
Subject: backlight: pwm_bl: Fix overflow condition
From: Derek Basehore <dbasehore(a)chromium.org>
[ Upstream commit 5d0c49acebc9488e37db95f1d4a55644e545ffe7 ]
This fixes an overflow condition that can happen with high max
brightness and period values in compute_duty_cycle. This fixes it by
using a 64 bit variable for computing the duty cycle.
Signed-off-by: Derek Basehore <dbasehore(a)chromium.org>
Acked-by: Thierry Reding <thierry.reding(a)gmail.com>
Reviewed-by: Brian Norris <briannorris(a)chromium.org>
Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/backlight/pwm_bl.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -79,14 +79,17 @@ static void pwm_backlight_power_off(stru
static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
{
unsigned int lth = pb->lth_brightness;
- int duty_cycle;
+ u64 duty_cycle;
if (pb->levels)
duty_cycle = pb->levels[brightness];
else
duty_cycle = brightness;
- return (duty_cycle * (pb->period - lth) / pb->scale) + lth;
+ duty_cycle *= pb->period - lth;
+ do_div(duty_cycle, pb->scale);
+
+ return duty_cycle + lth;
}
static int pwm_backlight_update_status(struct backlight_device *bl)
Patches currently in stable-queue which might be from dbasehore(a)chromium.org are
queue-4.14/backlight-pwm_bl-fix-overflow-condition.patch
This is a note to let you know that I've just added the patch titled
ASoC: codecs: msm8916-wcd-analog: fix module autoload
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-codecs-msm8916-wcd-analog-fix-module-autoload.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
Date: Tue, 3 Oct 2017 11:49:51 +0200
Subject: ASoC: codecs: msm8916-wcd-analog: fix module autoload
From: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
[ Upstream commit 46d69e141d479585c105a4d5b2337cd2ce6967e5 ]
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo snd_soc_msm8916_analog | grep alias
$
After this patch:
$ modinfo snd_soc_msm8916_analog | grep alias
alias: of:N*T*Cqcom,pm8916-wcd-analog-codecC*
alias: of:N*T*Cqcom,pm8916-wcd-analog-codec
Signed-off-by: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/msm8916-wcd-analog.c | 2 ++
1 file changed, 2 insertions(+)
--- a/sound/soc/codecs/msm8916-wcd-analog.c
+++ b/sound/soc/codecs/msm8916-wcd-analog.c
@@ -1242,6 +1242,8 @@ static const struct of_device_id pm8916_
{ }
};
+MODULE_DEVICE_TABLE(of, pm8916_wcd_analog_spmi_match_table);
+
static struct platform_driver pm8916_wcd_analog_spmi_driver = {
.driver = {
.name = "qcom,pm8916-wcd-spmi-codec",
Patches currently in stable-queue which might be from nicolas.dechesne(a)linaro.org are
queue-4.14/asoc-codecs-msm8916-wcd-analog-fix-module-autoload.patch
This is a note to let you know that I've just added the patch titled
ASoC: img-parallel-out: Add pm_runtime_get/put to set_fmt callback
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-img-parallel-out-add-pm_runtime_get-put-to-set_fmt-callback.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Ed Blake <ed.blake(a)sondrel.com>
Date: Mon, 2 Oct 2017 11:00:33 +0100
Subject: ASoC: img-parallel-out: Add pm_runtime_get/put to set_fmt callback
From: Ed Blake <ed.blake(a)sondrel.com>
[ Upstream commit c70458890ff15d858bd347fa9f563818bcd6e457 ]
Add pm_runtime_get_sync and pm_runtime_put calls to set_fmt callback
function. This fixes a bus error during boot when CONFIG_SUSPEND is
defined when this function gets called while the device is runtime
disabled and device registers are accessed while the clock is disabled.
Signed-off-by: Ed Blake <ed.blake(a)sondrel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/img/img-parallel-out.c | 2 ++
1 file changed, 2 insertions(+)
--- a/sound/soc/img/img-parallel-out.c
+++ b/sound/soc/img/img-parallel-out.c
@@ -164,9 +164,11 @@ static int img_prl_out_set_fmt(struct sn
return -EINVAL;
}
+ pm_runtime_get_sync(prl->dev);
reg = img_prl_out_readl(prl, IMG_PRL_OUT_CTL);
reg = (reg & ~IMG_PRL_OUT_CTL_EDGE_MASK) | control_set;
img_prl_out_writel(prl, reg, IMG_PRL_OUT_CTL);
+ pm_runtime_put(prl->dev);
return 0;
}
Patches currently in stable-queue which might be from ed.blake(a)sondrel.com are
queue-4.14/asoc-img-parallel-out-add-pm_runtime_get-put-to-set_fmt-callback.patch
This is a note to let you know that I've just added the patch titled
ASoC: codecs: msm8916-wcd-analog: fix micbias level
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-codecs-msm8916-wcd-analog-fix-micbias-level.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Jean-François Têtu <jean-francois.tetu(a)savoirfairelinux.com>
Date: Fri, 29 Sep 2017 16:19:44 -0400
Subject: ASoC: codecs: msm8916-wcd-analog: fix micbias level
From: Jean-François Têtu <jean-francois.tetu(a)savoirfairelinux.com>
[ Upstream commit 664611e7e02f76fbc5470ef545b2657ed25c292b ]
The macro used to set the microphone bias level causes the
snd_soc_write() call to overwrite other fields in the CDC_A_MICB_1_VAL
register. The macro also does not return the proper level value
to use. This fixes this by preserving all bits from the register
that are not the level while setting the level.
Signed-off-by: Jean-François Têtu <jean-francois.tetu(a)savoirfairelinux.com>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/msm8916-wcd-analog.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/sound/soc/codecs/msm8916-wcd-analog.c
+++ b/sound/soc/codecs/msm8916-wcd-analog.c
@@ -104,7 +104,7 @@
#define CDC_A_MICB_1_VAL (0xf141)
#define MICB_MIN_VAL 1600
#define MICB_STEP_SIZE 50
-#define MICB_VOLTAGE_REGVAL(v) ((v - MICB_MIN_VAL)/MICB_STEP_SIZE)
+#define MICB_VOLTAGE_REGVAL(v) (((v - MICB_MIN_VAL)/MICB_STEP_SIZE) << 3)
#define MICB_1_VAL_MICB_OUT_VAL_MASK GENMASK(7, 3)
#define MICB_1_VAL_MICB_OUT_VAL_V2P70V ((0x16) << 3)
#define MICB_1_VAL_MICB_OUT_VAL_V1P80V ((0x4) << 3)
@@ -349,8 +349,9 @@ static void pm8916_wcd_analog_micbias_en
| MICB_1_CTL_EXT_PRECHARG_EN_ENABLE);
if (wcd->micbias_mv) {
- snd_soc_write(codec, CDC_A_MICB_1_VAL,
- MICB_VOLTAGE_REGVAL(wcd->micbias_mv));
+ snd_soc_update_bits(codec, CDC_A_MICB_1_VAL,
+ MICB_1_VAL_MICB_OUT_VAL_MASK,
+ MICB_VOLTAGE_REGVAL(wcd->micbias_mv));
/*
* Special headset needs MICBIAS as 2.7V so wait for
* 50 msec for the MICBIAS to reach 2.7 volts.
Patches currently in stable-queue which might be from jean-francois.tetu(a)savoirfairelinux.com are
queue-4.14/asoc-codecs-msm8916-wcd-analog-fix-micbias-level.patch
This is a note to let you know that I've just added the patch titled
ARM: exynos_defconfig: Enable UAS support for Odroid HC1 board
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-exynos_defconfig-enable-uas-support-for-odroid-hc1-board.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 20 18:17:52 CET 2017
From: Marek Szyprowski <m.szyprowski(a)samsung.com>
Date: Mon, 2 Oct 2017 08:39:35 +0200
Subject: ARM: exynos_defconfig: Enable UAS support for Odroid HC1 board
From: Marek Szyprowski <m.szyprowski(a)samsung.com>
[ Upstream commit a99897f550de96841aecb811455a67ad7a4e39a7 ]
Odroid HC1 board has built-in JMicron USB to SATA bridge, which supports
UAS protocol. Compile-in support for it (instead of enabling it as module)
to make sure that all built-in storage devices are available for rootfs.
The bridge itself also supports fallback to standard USB Mass Storage
protocol, but USB Mass Storage class doesn't bind to it when UAS is
compiled as module and modules are not (yet) available.
Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/configs/exynos_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -244,7 +244,7 @@ CONFIG_USB_STORAGE_ONETOUCH=m
CONFIG_USB_STORAGE_KARMA=m
CONFIG_USB_STORAGE_CYPRESS_ATACB=m
CONFIG_USB_STORAGE_ENE_UB6250=m
-CONFIG_USB_UAS=m
+CONFIG_USB_UAS=y
CONFIG_USB_DWC3=y
CONFIG_USB_DWC2=y
CONFIG_USB_HSIC_USB3503=y
Patches currently in stable-queue which might be from m.szyprowski(a)samsung.com are
queue-4.14/arm-exynos_defconfig-enable-uas-support-for-odroid-hc1-board.patch
This is a note to let you know that I've just added the patch titled
arm64: Initialise high_memory global variable earlier
to the 3.18-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:
arm64-initialise-high_memory-global-variable-earlier.patch
and it can be found in the queue-3.18 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 f24e5834a2c3f6c5f814a417f858226f0a010ade Mon Sep 17 00:00:00 2001
From: Steve Capper <steve.capper(a)arm.com>
Date: Mon, 4 Dec 2017 14:13:05 +0000
Subject: arm64: Initialise high_memory global variable earlier
From: Steve Capper <steve.capper(a)arm.com>
commit f24e5834a2c3f6c5f814a417f858226f0a010ade upstream.
The high_memory global variable is used by
cma_declare_contiguous(.) before it is defined.
We don't notice this as we compute __pa(high_memory - 1), and it looks
like we're processing a VA from the direct linear map.
This problem becomes apparent when we flip the kernel virtual address
space and the linear map is moved to the bottom of the kernel VA space.
This patch moves the initialisation of high_memory before it used.
Fixes: f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory boundary")
Signed-off-by: Steve Capper <steve.capper(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/mm/init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -155,6 +155,8 @@ void __init arm64_memblock_init(void)
/* 4GB maximum for 32-bit only capable devices */
if (IS_ENABLED(CONFIG_ZONE_DMA))
dma_phys_limit = max_zone_dma_phys();
+
+ high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
dma_contiguous_reserve(dma_phys_limit);
memblock_allow_resize();
@@ -177,7 +179,6 @@ void __init bootmem_init(void)
sparse_init();
zone_sizes_init(min, max);
- high_memory = __va((max << PAGE_SHIFT) - 1) + 1;
max_pfn = max_low_pfn = max;
}
Patches currently in stable-queue which might be from steve.capper(a)arm.com are
queue-3.18/arm64-initialise-high_memory-global-variable-earlier.patch
Commit f24e5834a2c3f6c5f814a417f858226f0a010ade upstream.
The high_memory global variable is used by
cma_declare_contiguous(.) before it is defined.
We don't notice this as we compute __pa(high_memory - 1), and it looks
like we're processing a VA from the direct linear map.
This problem becomes apparent when we flip the kernel virtual address
space and the linear map is moved to the bottom of the kernel VA space.
This patch moves the initialisation of high_memory before it used.
Cc: <stable(a)vger.kernel.org>
Fixes: f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory boundary")
Signed-off-by: Steve Capper <steve.capper(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
---
arch/arm64/mm/init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 43245e15413e..ed8affdf8f58 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -155,6 +155,8 @@ void __init arm64_memblock_init(void)
/* 4GB maximum for 32-bit only capable devices */
if (IS_ENABLED(CONFIG_ZONE_DMA))
dma_phys_limit = max_zone_dma_phys();
+
+ high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
dma_contiguous_reserve(dma_phys_limit);
memblock_allow_resize();
@@ -177,7 +179,6 @@ void __init bootmem_init(void)
sparse_init();
zone_sizes_init(min, max);
- high_memory = __va((max << PAGE_SHIFT) - 1) + 1;
max_pfn = max_low_pfn = max;
}
--
2.11.0
Hi Greg,
While trying to boot 4.14 on a RPi3 I encountered the following log
lines which preceded a kernel panic:
> OF: ERROR: Bad of_node_put() on /soc/firmware
> CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.14.3 #1-NixOS
> Hardware name: Raspberry Pi 3 Model B (DT)
> Call trace:
> [] dump_backtrace+0x0/0x298
> [] show_stack+0x24/0x30
> [] dump_stack+0x98/0xbc
> [] of_node_release+0xa4/0xa8
> [] kobject_put+0x94/0x218
> [] of_node_put+0x24/0x30
> [] optee_driver_init+0x60/0x4c4
> [] do_one_initcall+0x5c/0x168
> [] kernel_init_freeable+0x18c/0x22c
> [] kernel_init+0x18/0x110
> [] ret_from_fork+0x10/0x18
The PI spits this out a couple of times, stumbles upon other things and
decides to panic. (The full output can be seen at [1])
The below patch was discovered on LKML [2], applied and
successfully tested. Boot succeeds and log looks normal again.
It would make sense to me to see that patch being included in the
(long term) stable release as well. Since optee was introduced with 4.11
there is no need to include this on 4.9.
I would appreciate if you could pull that commit into the stable queue.
commit f044113113dd95ba73916bde10e804d3cdfa2662
Author: Jens Wiklander <jens.wiklander(a)linaro.org>
Date: Mon Oct 9 11:11:49 2017 +0200
optee: fix invalid of_node_put() in optee_driver_init()
The first node supplied to of_find_matching_node() has its reference
counter decreased as part of call to that function. In optee_driver_init()
after calling of_find_matching_node() it's invalid to call of_node_put() on
the supplied node again.
So remove the invalid call to of_node_put().
Reported-by: Alex Shi <alex.shi(a)linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org>
Kind regards,
Andreas Rammhold
[1] https://gist.githubusercontent.com/andir/0de9163e9e31493658ff185f5fcf0616/r…
[2] https://lkml.org/lkml/2017/11/29/230
This is a note to let you know that I've just added the patch titled
x86/cpuid: Replace set/clear_bit32()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-cpuid-replace-set-clear_bit32.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 06dd688ddda5819025e014b79aea9af6ab475fa2 Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <tglx(a)linutronix.de>
Date: Thu, 2 Nov 2017 13:22:35 +0100
Subject: x86/cpuid: Replace set/clear_bit32()
From: Thomas Gleixner <tglx(a)linutronix.de>
commit 06dd688ddda5819025e014b79aea9af6ab475fa2 upstream.
Peter pointed out that the set/clear_bit32() variants are broken in various
aspects.
Replace them with open coded set/clear_bit() and type cast
cpu_info::x86_capability as it's done in all other places throughout x86.
Fixes: 0b00de857a64 ("x86/cpuid: Add generic table for CPUID dependencies")
Reported-by: Peter Ziljstra <peterz(a)infradead.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Andi Kleen <ak(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/cpuid-deps.c | 26 +++++++++++---------------
1 file changed, 11 insertions(+), 15 deletions(-)
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -62,23 +62,19 @@ const static struct cpuid_dep cpuid_deps
{}
};
-static inline void __clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit)
-{
- clear_bit32(bit, c->x86_capability);
-}
-
-static inline void __setup_clear_cpu_cap(unsigned int bit)
-{
- clear_cpu_cap(&boot_cpu_data, bit);
- set_bit32(bit, cpu_caps_cleared);
-}
-
static inline void clear_feature(struct cpuinfo_x86 *c, unsigned int feature)
{
- if (!c)
- __setup_clear_cpu_cap(feature);
- else
- __clear_cpu_cap(c, feature);
+ /*
+ * Note: This could use the non atomic __*_bit() variants, but the
+ * rest of the cpufeature code uses atomics as well, so keep it for
+ * consistency. Cleanup all of it separately.
+ */
+ if (!c) {
+ clear_cpu_cap(&boot_cpu_data, feature);
+ set_bit(feature, (unsigned long *)cpu_caps_cleared);
+ } else {
+ clear_bit(feature, (unsigned long *)c->x86_capability);
+ }
}
/* Take the capabilities and the BUG bits into account */
Patches currently in stable-queue which might be from tglx(a)linutronix.de are
queue-4.14/x86-asm-remove-unnecessary-n-t-in-front-of-cc_set-from-asm-templates.patch
queue-4.14/x86-cpuid-add-generic-table-for-cpuid-dependencies.patch
queue-4.14/objtool-don-t-report-end-of-section-error-after-an-empty-unwind-hint.patch
queue-4.14/x86-cpufeatures-enable-new-sse-avx-avx512-cpu-features.patch
queue-4.14/x86-cpuid-prevent-out-of-bound-access-in-do_clear_cpu_cap.patch
queue-4.14/x86-cpufeatures-re-tabulate-the-x86_feature-definitions.patch
queue-4.14/x86-cpuid-replace-set-clear_bit32.patch
This is a note to let you know that I've just added the patch titled
x86/cpuid: Prevent out of bound access in do_clear_cpu_cap()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-cpuid-prevent-out-of-bound-access-in-do_clear_cpu_cap.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 57b8b1a1856adaa849d02d547411a553a531022b Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <tglx(a)linutronix.de>
Date: Wed, 18 Oct 2017 19:39:35 +0200
Subject: x86/cpuid: Prevent out of bound access in do_clear_cpu_cap()
From: Thomas Gleixner <tglx(a)linutronix.de>
commit 57b8b1a1856adaa849d02d547411a553a531022b upstream.
do_clear_cpu_cap() allocates a bitmap to keep track of disabled feature
dependencies. That bitmap is sized NCAPINTS * BITS_PER_INIT. The possible
'features' which can be handed in are larger than this, because after the
capabilities the bug 'feature' bits occupy another 32bit. Not really
obvious...
So clearing any of the misfeature bits, as 32bit does for the F00F bug,
accesses that bitmap out of bounds thereby corrupting the stack.
Size the bitmap proper and add a sanity check to catch accidental out of
bound access.
Fixes: 0b00de857a64 ("x86/cpuid: Add generic table for CPUID dependencies")
Reported-by: kernel test robot <xiaolong.ye(a)intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Borislav Petkov <bp(a)alien8.de>
Link: https://lkml.kernel.org/r/20171018022023.GA12058@yexl-desktop
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/cpuid-deps.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -75,11 +75,17 @@ static inline void clear_feature(struct
__clear_cpu_cap(c, feature);
}
+/* Take the capabilities and the BUG bits into account */
+#define MAX_FEATURE_BITS ((NCAPINTS + NBUGINTS) * sizeof(u32) * 8)
+
static void do_clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature)
{
- bool changed;
- DECLARE_BITMAP(disable, NCAPINTS * sizeof(u32) * 8);
+ DECLARE_BITMAP(disable, MAX_FEATURE_BITS);
const struct cpuid_dep *d;
+ bool changed;
+
+ if (WARN_ON(feature >= MAX_FEATURE_BITS))
+ return;
clear_feature(c, feature);
Patches currently in stable-queue which might be from tglx(a)linutronix.de are
queue-4.14/x86-asm-remove-unnecessary-n-t-in-front-of-cc_set-from-asm-templates.patch
queue-4.14/x86-cpuid-add-generic-table-for-cpuid-dependencies.patch
queue-4.14/objtool-don-t-report-end-of-section-error-after-an-empty-unwind-hint.patch
queue-4.14/x86-cpufeatures-enable-new-sse-avx-avx512-cpu-features.patch
queue-4.14/x86-cpuid-prevent-out-of-bound-access-in-do_clear_cpu_cap.patch
queue-4.14/x86-cpufeatures-re-tabulate-the-x86_feature-definitions.patch
queue-4.14/x86-cpuid-replace-set-clear_bit32.patch
This is a note to let you know that I've just added the patch titled
x86/cpuid: Add generic table for CPUID dependencies
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-cpuid-add-generic-table-for-cpuid-dependencies.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0b00de857a648dafe7020878c7a27cf776f5edf4 Mon Sep 17 00:00:00 2001
From: Andi Kleen <ak(a)linux.intel.com>
Date: Fri, 13 Oct 2017 14:56:42 -0700
Subject: x86/cpuid: Add generic table for CPUID dependencies
From: Andi Kleen <ak(a)linux.intel.com>
commit 0b00de857a648dafe7020878c7a27cf776f5edf4 upstream.
Some CPUID features depend on other features. Currently it's
possible to to clear dependent features, but not clear the base features,
which can cause various interesting problems.
This patch implements a generic table to describe dependencies
between CPUID features, to be used by all code that clears
CPUID.
Some subsystems (like XSAVE) had an own implementation of this,
but it's better to do it all in a single place for everyone.
Then clear_cpu_cap and setup_clear_cpu_cap always look up
this table and clear all dependencies too.
This is intended to be a practical table: only for features
that make sense to clear. If someone for example clears FPU,
or other features that are essentially part of the required
base feature set, not much is going to work. Handling
that is right now out of scope. We're only handling
features which can be usefully cleared.
Signed-off-by: Andi Kleen <ak(a)linux.intel.com>
Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Jonathan McDowell <noodles(a)earth.li>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Link: http://lkml.kernel.org/r/20171013215645.23166-3-andi@firstfloor.org
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/cpufeature.h | 9 +-
arch/x86/include/asm/cpufeatures.h | 5 +
arch/x86/kernel/cpu/Makefile | 1
arch/x86/kernel/cpu/cpuid-deps.c | 113 +++++++++++++++++++++++++++++++++++++
4 files changed, 123 insertions(+), 5 deletions(-)
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -126,11 +126,10 @@ extern const char * const x86_bug_flags[
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
#define set_cpu_cap(c, bit) set_bit(bit, (unsigned long *)((c)->x86_capability))
-#define clear_cpu_cap(c, bit) clear_bit(bit, (unsigned long *)((c)->x86_capability))
-#define setup_clear_cpu_cap(bit) do { \
- clear_cpu_cap(&boot_cpu_data, bit); \
- set_bit(bit, (unsigned long *)cpu_caps_cleared); \
-} while (0)
+
+extern void setup_clear_cpu_cap(unsigned int bit);
+extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
+
#define setup_force_cpu_cap(bit) do { \
set_cpu_cap(&boot_cpu_data, bit); \
set_bit(bit, (unsigned long *)cpu_caps_set); \
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -22,6 +22,11 @@
* this feature bit is not displayed in /proc/cpuinfo at all.
*/
+/*
+ * When adding new features here that depend on other features,
+ * please update the table in kernel/cpu/cpuid-deps.c
+ */
+
/* Intel-defined CPU features, CPUID level 0x00000001 (edx), word 0 */
#define X86_FEATURE_FPU ( 0*32+ 0) /* Onboard FPU */
#define X86_FEATURE_VME ( 0*32+ 1) /* Virtual Mode Extensions */
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -23,6 +23,7 @@ obj-y += rdrand.o
obj-y += match.o
obj-y += bugs.o
obj-$(CONFIG_CPU_FREQ) += aperfmperf.o
+obj-y += cpuid-deps.o
obj-$(CONFIG_PROC_FS) += proc.o
obj-$(CONFIG_X86_FEATURE_NAMES) += capflags.o powerflags.o
--- /dev/null
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -0,0 +1,113 @@
+/* Declare dependencies between CPUIDs */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <asm/cpufeature.h>
+
+struct cpuid_dep {
+ unsigned int feature;
+ unsigned int depends;
+};
+
+/*
+ * Table of CPUID features that depend on others.
+ *
+ * This only includes dependencies that can be usefully disabled, not
+ * features part of the base set (like FPU).
+ *
+ * Note this all is not __init / __initdata because it can be
+ * called from cpu hotplug. It shouldn't do anything in this case,
+ * but it's difficult to tell that to the init reference checker.
+ */
+const static struct cpuid_dep cpuid_deps[] = {
+ { X86_FEATURE_XSAVEOPT, X86_FEATURE_XSAVE },
+ { X86_FEATURE_XSAVEC, X86_FEATURE_XSAVE },
+ { X86_FEATURE_XSAVES, X86_FEATURE_XSAVE },
+ { X86_FEATURE_AVX, X86_FEATURE_XSAVE },
+ { X86_FEATURE_PKU, X86_FEATURE_XSAVE },
+ { X86_FEATURE_MPX, X86_FEATURE_XSAVE },
+ { X86_FEATURE_XGETBV1, X86_FEATURE_XSAVE },
+ { X86_FEATURE_FXSR_OPT, X86_FEATURE_FXSR },
+ { X86_FEATURE_XMM, X86_FEATURE_FXSR },
+ { X86_FEATURE_XMM2, X86_FEATURE_XMM },
+ { X86_FEATURE_XMM3, X86_FEATURE_XMM2 },
+ { X86_FEATURE_XMM4_1, X86_FEATURE_XMM2 },
+ { X86_FEATURE_XMM4_2, X86_FEATURE_XMM2 },
+ { X86_FEATURE_XMM3, X86_FEATURE_XMM2 },
+ { X86_FEATURE_PCLMULQDQ, X86_FEATURE_XMM2 },
+ { X86_FEATURE_SSSE3, X86_FEATURE_XMM2, },
+ { X86_FEATURE_F16C, X86_FEATURE_XMM2, },
+ { X86_FEATURE_AES, X86_FEATURE_XMM2 },
+ { X86_FEATURE_SHA_NI, X86_FEATURE_XMM2 },
+ { X86_FEATURE_FMA, X86_FEATURE_AVX },
+ { X86_FEATURE_AVX2, X86_FEATURE_AVX, },
+ { X86_FEATURE_AVX512F, X86_FEATURE_AVX, },
+ { X86_FEATURE_AVX512IFMA, X86_FEATURE_AVX512F },
+ { X86_FEATURE_AVX512PF, X86_FEATURE_AVX512F },
+ { X86_FEATURE_AVX512ER, X86_FEATURE_AVX512F },
+ { X86_FEATURE_AVX512CD, X86_FEATURE_AVX512F },
+ { X86_FEATURE_AVX512DQ, X86_FEATURE_AVX512F },
+ { X86_FEATURE_AVX512BW, X86_FEATURE_AVX512F },
+ { X86_FEATURE_AVX512VL, X86_FEATURE_AVX512F },
+ { X86_FEATURE_AVX512VBMI, X86_FEATURE_AVX512F },
+ { X86_FEATURE_AVX512_4VNNIW, X86_FEATURE_AVX512F },
+ { X86_FEATURE_AVX512_4FMAPS, X86_FEATURE_AVX512F },
+ { X86_FEATURE_AVX512_VPOPCNTDQ, X86_FEATURE_AVX512F },
+ {}
+};
+
+static inline void __clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit)
+{
+ clear_bit32(bit, c->x86_capability);
+}
+
+static inline void __setup_clear_cpu_cap(unsigned int bit)
+{
+ clear_cpu_cap(&boot_cpu_data, bit);
+ set_bit32(bit, cpu_caps_cleared);
+}
+
+static inline void clear_feature(struct cpuinfo_x86 *c, unsigned int feature)
+{
+ if (!c)
+ __setup_clear_cpu_cap(feature);
+ else
+ __clear_cpu_cap(c, feature);
+}
+
+static void do_clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature)
+{
+ bool changed;
+ DECLARE_BITMAP(disable, NCAPINTS * sizeof(u32) * 8);
+ const struct cpuid_dep *d;
+
+ clear_feature(c, feature);
+
+ /* Collect all features to disable, handling dependencies */
+ memset(disable, 0, sizeof(disable));
+ __set_bit(feature, disable);
+
+ /* Loop until we get a stable state. */
+ do {
+ changed = false;
+ for (d = cpuid_deps; d->feature; d++) {
+ if (!test_bit(d->depends, disable))
+ continue;
+ if (__test_and_set_bit(d->feature, disable))
+ continue;
+
+ changed = true;
+ clear_feature(c, d->feature);
+ }
+ } while (changed);
+}
+
+void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature)
+{
+ do_clear_cpu_cap(c, feature);
+}
+
+void setup_clear_cpu_cap(unsigned int feature)
+{
+ do_clear_cpu_cap(NULL, feature);
+}
Patches currently in stable-queue which might be from ak(a)linux.intel.com are
queue-4.14/x86-cpuid-add-generic-table-for-cpuid-dependencies.patch
queue-4.14/x86-cpuid-prevent-out-of-bound-access-in-do_clear_cpu_cap.patch
queue-4.14/x86-cpuid-replace-set-clear_bit32.patch
This is a note to let you know that I've just added the patch titled
x86/cpufeatures: Enable new SSE/AVX/AVX512 CPU features
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-cpufeatures-enable-new-sse-avx-avx512-cpu-features.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c128dbfa0f879f8ce7b79054037889b0b2240728 Mon Sep 17 00:00:00 2001
From: Gayatri Kammela <gayatri.kammela(a)intel.com>
Date: Mon, 30 Oct 2017 18:20:29 -0700
Subject: x86/cpufeatures: Enable new SSE/AVX/AVX512 CPU features
From: Gayatri Kammela <gayatri.kammela(a)intel.com>
commit c128dbfa0f879f8ce7b79054037889b0b2240728 upstream.
Add a few new SSE/AVX/AVX512 instruction groups/features for enumeration
in /proc/cpuinfo: AVX512_VBMI2, GFNI, VAES, VPCLMULQDQ, AVX512_VNNI,
AVX512_BITALG.
CPUID.(EAX=7,ECX=0):ECX[bit 6] AVX512_VBMI2
CPUID.(EAX=7,ECX=0):ECX[bit 8] GFNI
CPUID.(EAX=7,ECX=0):ECX[bit 9] VAES
CPUID.(EAX=7,ECX=0):ECX[bit 10] VPCLMULQDQ
CPUID.(EAX=7,ECX=0):ECX[bit 11] AVX512_VNNI
CPUID.(EAX=7,ECX=0):ECX[bit 12] AVX512_BITALG
Detailed information of CPUID bits for these features can be found
in the Intel Architecture Instruction Set Extensions and Future Features
Programming Interface document (refer to Table 1-1. and Table 1-2.).
A copy of this document is available at
https://bugzilla.kernel.org/show_bug.cgi?id=197239
Signed-off-by: Gayatri Kammela <gayatri.kammela(a)intel.com>
Acked-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Andi Kleen <andi.kleen(a)intel.com>
Cc: Fenghua Yu <fenghua.yu(a)intel.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Ravi Shankar <ravi.v.shankar(a)intel.com>
Cc: Ricardo Neri <ricardo.neri(a)intel.com>
Cc: Yang Zhong <yang.zhong(a)intel.com>
Cc: bp(a)alien8.de
Link: http://lkml.kernel.org/r/1509412829-23380-1-git-send-email-gayatri.kammela@…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/cpufeatures.h | 6 ++++++
arch/x86/kernel/cpu/cpuid-deps.c | 6 ++++++
2 files changed, 12 insertions(+)
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -300,6 +300,12 @@
#define X86_FEATURE_AVX512VBMI (16*32+ 1) /* AVX512 Vector Bit Manipulation instructions*/
#define X86_FEATURE_PKU (16*32+ 3) /* Protection Keys for Userspace */
#define X86_FEATURE_OSPKE (16*32+ 4) /* OS Protection Keys Enable */
+#define X86_FEATURE_AVX512_VBMI2 (16*32+ 6) /* Additional AVX512 Vector Bit Manipulation Instructions */
+#define X86_FEATURE_GFNI (16*32+ 8) /* Galois Field New Instructions */
+#define X86_FEATURE_VAES (16*32+ 9) /* Vector AES */
+#define X86_FEATURE_VPCLMULQDQ (16*32+ 10) /* Carry-Less Multiplication Double Quadword */
+#define X86_FEATURE_AVX512_VNNI (16*32+ 11) /* Vector Neural Network Instructions */
+#define X86_FEATURE_AVX512_BITALG (16*32+12) /* Support for VPOPCNT[B,W] and VPSHUF-BITQMB */
#define X86_FEATURE_AVX512_VPOPCNTDQ (16*32+14) /* POPCNT for vectors of DW/QW */
#define X86_FEATURE_LA57 (16*32+16) /* 5-level page tables */
#define X86_FEATURE_RDPID (16*32+22) /* RDPID instruction */
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -50,6 +50,12 @@ const static struct cpuid_dep cpuid_deps
{ X86_FEATURE_AVX512BW, X86_FEATURE_AVX512F },
{ X86_FEATURE_AVX512VL, X86_FEATURE_AVX512F },
{ X86_FEATURE_AVX512VBMI, X86_FEATURE_AVX512F },
+ { X86_FEATURE_AVX512_VBMI2, X86_FEATURE_AVX512VL },
+ { X86_FEATURE_GFNI, X86_FEATURE_AVX512VL },
+ { X86_FEATURE_VAES, X86_FEATURE_AVX512VL },
+ { X86_FEATURE_VPCLMULQDQ, X86_FEATURE_AVX512VL },
+ { X86_FEATURE_AVX512_VNNI, X86_FEATURE_AVX512VL },
+ { X86_FEATURE_AVX512_BITALG, X86_FEATURE_AVX512VL },
{ X86_FEATURE_AVX512_4VNNIW, X86_FEATURE_AVX512F },
{ X86_FEATURE_AVX512_4FMAPS, X86_FEATURE_AVX512F },
{ X86_FEATURE_AVX512_VPOPCNTDQ, X86_FEATURE_AVX512F },
Patches currently in stable-queue which might be from gayatri.kammela(a)intel.com are
queue-4.14/x86-cpufeatures-enable-new-sse-avx-avx512-cpu-features.patch
This is a note to let you know that I've just added the patch titled
objtool: Don't report end of section error after an empty unwind hint
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
objtool-don-t-report-end-of-section-error-after-an-empty-unwind-hint.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 00d96180dc38ef872ac471c2d3e14b067cbd895d Mon Sep 17 00:00:00 2001
From: Josh Poimboeuf <jpoimboe(a)redhat.com>
Date: Mon, 18 Sep 2017 21:43:30 -0500
Subject: objtool: Don't report end of section error after an empty unwind hint
From: Josh Poimboeuf <jpoimboe(a)redhat.com>
commit 00d96180dc38ef872ac471c2d3e14b067cbd895d upstream.
If asm code specifies an UNWIND_HINT_EMPTY hint, don't warn if the
section ends unexpectedly. This can happen with the xen-head.S code
because the hypercall_page is "text" but it's all zeros.
Signed-off-by: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Cc: Jiri Slaby <jslaby(a)suse.cz>
Cc: Juergen Gross <jgross(a)suse.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/ddafe199dd8797e40e3c2777373347eba1d65572.150576406…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/objtool/check.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1757,11 +1757,14 @@ static int validate_branch(struct objtoo
if (insn->dead_end)
return 0;
- insn = next_insn;
- if (!insn) {
+ if (!next_insn) {
+ if (state.cfa.base == CFI_UNDEFINED)
+ return 0;
WARN("%s: unexpected end of section", sec->name);
return 1;
}
+
+ insn = next_insn;
}
return 0;
Patches currently in stable-queue which might be from jpoimboe(a)redhat.com are
queue-4.14/objtool-don-t-report-end-of-section-error-after-an-empty-unwind-hint.patch
queue-4.14/x86-cpufeatures-re-tabulate-the-x86_feature-definitions.patch
Commit 6b8322576e9d ("MIPS: Force CPUs to lose FP context during mode
switches") ensures that we react to PR_SET_FP_MODE prctl syscalls
quickly by broadcasting an IPI in order to cause CPUs to lose FPU access
when necessary. Whilst it achieves that, unfortunately it causes all
sorts of strange race conditions because:
1) The IPI may arrive at a point where the FPU is in the process of
being enabled, but that process is not yet complete leading to a
state we aren't prepared to handle. For example:
do_cpu invoked from kernel context![#1]:
CPU: 0 PID: 963 Comm: fp-prctl Not tainted 4.9.0-rc5-00323-g210db32-dirty #226
task: a8000000fd672e00 task.stack: a8000000fd630000
$ 0 : 0000000000000000 0000000000000001 0000000000000001 a8000000fd630000
$ 4 : a8000000fd672e00 0000000000000000 0000000000000453 0000000000000000
$ 8 : 0000000000000000 a8000000fd637c28 1000000000000000 0000000000000010
$12 : 00000000140084e0 ffffffff80109c00 0000000000000000 0000000000000002
$16 : ffffffff8092f080 a8000000fd672e00 ffffffff80107fe8 a8000000fd485000
$20 : ffffffff8084d328 ffffffff80940000 0000000000000009 ffffffff80930000
$24 : 0000000000000000 900000001612048c
$28 : a8000000fd630000 a8000000fd637ac0 ffffffff80937300 ffffffff8010807c
Hi : 0000000000000000
Lo : 0000000000000200
epc : ffffffff80115d38 _save_fp+0x10/0xa0
ra : ffffffff8010807c prepare_for_fp_mode_switch+0x94/0x1b0
Status: 140084e2 KX SX UX KERNEL EXL
Cause : 1080002c (ExcCode 0b)
PrId : 0001a428 (MIPS P6600)
Modules linked in:
Process fp-prctl (pid: 963, threadinfo=a8000000fd630000, task=a8000000fd672e00, tls=00000000756e67d0)
Stack : 0000000000000000 a8000000fd557dc0 0000000000000000 ffffffff801ca8e0
0000000000000000 a8000000fd637b9c 0000000000000009 ffffffff80923780
ffffffff80850000 ffffffff8011610c 00000000000000b8 ffffffff801a5084
ffffffff8084a370 ffffffff8084a388 ffffffff80923780 ffffffff80923828
0000000000010000 ffffffff809237a8 0000000000020000 ffffffff80a40000
000000000000007c 00000000004a0000 00000000756dedd0 ffffffff801a5188
a800000002014900 0000000000000001 ffffffff80923780 0000000080923828
ffffffff80923780 ffffffff80923780 ffffffff80923828 ffffffff801a521c
ffffffff80923780 ffffffff80923828 0000000000010000 ffffffff801a8f84
ffffffff80a40000 a8000000fd637c20 ffffffff80a39240 0000000000000001
...
Call Trace:
[<ffffffff80115d38>] _save_fp+0x10/0xa0
[<ffffffff8010807c>] prepare_for_fp_mode_switch+0x94/0x1b0
[<ffffffff801ca8e0>] flush_smp_call_function_queue+0xf8/0x230
[<ffffffff8011610c>] ipi_call_interrupt+0xc/0x20
[<ffffffff801a5084>] __handle_irq_event_percpu+0xc4/0x1a8
[<ffffffff801a5188>] handle_irq_event_percpu+0x20/0x68
[<ffffffff801a521c>] handle_irq_event+0x4c/0x88
[<ffffffff801a8f84>] handle_edge_irq+0x12c/0x210
[<ffffffff801a47a0>] generic_handle_irq+0x38/0x48
[<ffffffff804a2dbc>] gic_handle_shared_int+0x194/0x268
[<ffffffff801a47a0>] generic_handle_irq+0x38/0x48
[<ffffffff80107e60>] do_IRQ+0x18/0x28
[<ffffffff804a1524>] plat_irq_dispatch+0xc4/0x140
[<ffffffff80106230>] ret_from_irq+0x0/0x4
[<ffffffff8010fad4>] do_ri+0x4fc/0x7e8
[<ffffffff80106220>] ret_from_exception+0x0/0x10
2) The IPI may arrive during kernel use of the FPU, since we generally
only disable preemption around use of the FPU & leave interrupts
enabled. This can lead to us unexpectedly losing access to the FPU
in places where it previously had not been possible. For example:
do_cpu invoked from kernel context![#2]:
CPU: 2 PID: 7338 Comm: fp-prctl Tainted: G D 4.7.0-00424-g49b0c82
#2
task: 838e4000 ti: 88d38000 task.ti: 88d38000
$ 0 : 00000000 00000001 ffffffff 88d3fef8
$ 4 : 838e4000 88d38004 00000000 00000001
$ 8 : 3400fc01 801f8020 808e9100 24000000
$12 : dbffffff 807b69d8 807b0000 00000000
$16 : 00000000 80786150 00400fc4 809c0398
$20 : 809c0338 0040273c 88d3ff28 808e9d30
$24 : 808e9d30 00400fb4
$28 : 88d38000 88d3fe88 00000000 8011a2ac
Hi : 0040273c
Lo : 88d3ff28
epc : 80114178 _restore_fp+0x10/0xa0
ra : 8011a2ac mipsr2_decoder+0xd5c/0x1660
Status: 1400fc03 KERNEL EXL IE
Cause : 1080002c (ExcCode 0b)
PrId : 0001a920 (MIPS I6400)
Modules linked in:
Process fp-prctl (pid: 7338, threadinfo=88d38000, task=838e4000, tls=766527d0)
Stack : 00000000 00000000 00000000 88d3fe98 00000000 00000000 809c0398 809c0338
808e9100 00000000 88d3ff28 00400fc4 00400fc4 0040273c 7fb69e18 004a0000
004a0000 004a0000 7664add0 8010de18 00000000 00000000 88d3fef8 88d3ff28
808e9100 00000000 766527d0 8010e534 000c0000 85755000 8181d580 00000000
00000000 00000000 004a0000 00000000 766527d0 7fb69e18 004a0000 80105c20
...
Call Trace:
[<80114178>] _restore_fp+0x10/0xa0
[<8011a2ac>] mipsr2_decoder+0xd5c/0x1660
[<8010de18>] do_ri+0x90/0x6b8
[<80105c20>] ret_from_exception+0x0/0x10
At first glance a simple fix may seem to be to disable interrupts around
kernel use of the FPU rather than merely preemption, however this would
introduce further overhead outside of the mode switch path & doesn't
solve the third problem:
3) The IPI may arrive whilst the kernel is running code that will lead
to a preempt_disable() call & FPU usage soon. If this happens then
the IPI will be serviced & we'll proceed to enable an FPU whilst the
mode switch is in progress, leading to strange & inconsistent
behaviour.
Further to all of this is a separate but related problem:
4) There are various paths through which we may enable the FPU without
the user having triggered a coprocessor 1 disabled exception. These
paths are those in which we emulate instructions & then enable the
FPU with the expectation that the user might execute an FP
instruction shortly afterwards. However these paths have not
previously checked whether an FP mode switch is underway for the
task, and therefore could enable the FPU whilst such a mode switch
is in progress leading to strange & inconsistent behaviour for user
code.
This patch fixes all of the above by taking a step back & re-examining
our approach to FP mode switches. Up until now we have taken these basic
steps:
a) Prevent any threads that are part of the affected process from being
able to obtain ownership of the FPU.
b) Cause any threads that are part of the affected process and already
have ownership of an FPU to lose it.
c) Set the thread flags for each thread that is part of the affected
process to reflect the new FP mode.
d) Allow threads to obtain ownership of the FPU again.
This approach is however more complex than necessary. All that we really
require is that the mode switch has occurred for all threads that are
part of the affected process before mips_set_process_fp_mode(), and thus
the PR_SET_FP_MODE prctl() syscall, returns. This doesn't require that
we stop threads from owning or using an FPU whilst a mode switch occurs,
only that we force them to relinquish it after the mode switch has
occurred such that they next own an FPU with the correct mode
configured. Our basic steps therefore simplify to:
A) Set the thread flags for each thread that is part of the affected
process to reflect the new FP mode.
B) Cause any threads that are part of the affected process and already
have ownership of an FPU to lose it.
We implement B) by forcing each CPU which might be running a thread
which is part of the affected process to schedule a no-op function,
which causes the affected thread to lose its FPU ownership when it is
descheduled.
The end result is simpler FP mode switching with less overhead in the
FPU enable path (ie. enable_restore_fp_context()) and fewer moving
parts.
Signed-off-by: Paul Burton <paul.burton(a)mips.com>
Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Fixes: 6b8322576e9d ("MIPS: Force CPUs to lose FP context during mode switches")
Cc: James Hogan <jhogan(a)kernel.org>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: linux-mips(a)linux-mips.org
Cc: stable <stable(a)vger.kernel.org> # v4.0+
---
arch/mips/include/asm/mmu_context.h | 2 -
arch/mips/kernel/process.c | 80 +++++++++++++++++++------------------
arch/mips/kernel/traps.c | 7 ----
3 files changed, 42 insertions(+), 47 deletions(-)
diff --git a/arch/mips/include/asm/mmu_context.h b/arch/mips/include/asm/mmu_context.h
index da2004cef2d5..b509371a6b0c 100644
--- a/arch/mips/include/asm/mmu_context.h
+++ b/arch/mips/include/asm/mmu_context.h
@@ -126,8 +126,6 @@ init_new_context(struct task_struct *tsk, struct mm_struct *mm)
for_each_possible_cpu(i)
cpu_context(i, mm) = 0;
- atomic_set(&mm->context.fp_mode_switching, 0);
-
mm->context.bd_emupage_allocmap = NULL;
spin_lock_init(&mm->context.bd_emupage_lock);
init_waitqueue_head(&mm->context.bd_emupage_queue);
diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
index 45d0b6b037ee..680a91ba2030 100644
--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -29,6 +29,7 @@
#include <linux/kallsyms.h>
#include <linux/random.h>
#include <linux/prctl.h>
+#include <linux/cpu.h>
#include <asm/asm.h>
#include <asm/bootinfo.h>
@@ -691,19 +692,25 @@ int mips_get_process_fp_mode(struct task_struct *task)
return value;
}
-static void prepare_for_fp_mode_switch(void *info)
+static long prepare_for_fp_mode_switch(void *unused)
{
- struct mm_struct *mm = info;
-
- if (current->mm == mm)
- lose_fpu(1);
+ /*
+ * This is icky, but we use this to simply ensure that all CPUs have
+ * context switched, regardless of whether they were previously running
+ * kernel or user code. This ensures that no CPU currently has its FPU
+ * enabled, or is about to attempt to enable it through any path other
+ * than enable_restore_fp_context() which will wait appropriately for
+ * fp_mode_switching to be zero.
+ */
+ return 0;
}
int mips_set_process_fp_mode(struct task_struct *task, unsigned int value)
{
const unsigned int known_bits = PR_FP_MODE_FR | PR_FP_MODE_FRE;
struct task_struct *t;
- int max_users;
+ struct cpumask process_cpus;
+ int cpu;
/* Check the value is valid */
if (value & ~known_bits)
@@ -720,35 +727,7 @@ int mips_set_process_fp_mode(struct task_struct *task, unsigned int value)
if (!(value & PR_FP_MODE_FR) && raw_cpu_has_fpu && cpu_has_mips_r6)
return -EOPNOTSUPP;
- /* Proceed with the mode switch */
- preempt_disable();
-
- /* Save FP & vector context, then disable FPU & MSA */
- if (task->signal == current->signal)
- lose_fpu(1);
-
- /* Prevent any threads from obtaining live FP context */
- atomic_set(&task->mm->context.fp_mode_switching, 1);
- smp_mb__after_atomic();
-
- /*
- * If there are multiple online CPUs then force any which are running
- * threads in this process to lose their FPU context, which they can't
- * regain until fp_mode_switching is cleared later.
- */
- if (num_online_cpus() > 1) {
- /* No need to send an IPI for the local CPU */
- max_users = (task->mm == current->mm) ? 1 : 0;
-
- if (atomic_read(¤t->mm->mm_users) > max_users)
- smp_call_function(prepare_for_fp_mode_switch,
- (void *)current->mm, 1);
- }
-
- /*
- * There are now no threads of the process with live FP context, so it
- * is safe to proceed with the FP mode switch.
- */
+ /* Indicate the new FP mode in each thread */
for_each_thread(task, t) {
/* Update desired FP register width */
if (value & PR_FP_MODE_FR) {
@@ -765,9 +744,34 @@ int mips_set_process_fp_mode(struct task_struct *task, unsigned int value)
clear_tsk_thread_flag(t, TIF_HYBRID_FPREGS);
}
- /* Allow threads to use FP again */
- atomic_set(&task->mm->context.fp_mode_switching, 0);
- preempt_enable();
+ /*
+ * We need to ensure that all threads in the process have switched mode
+ * before returning, in order to allow userland to not worry about
+ * races. We can do this by forcing all CPUs that any thread in the
+ * process may be running on to schedule something else - in this case
+ * prepare_for_fp_mode_switch().
+ *
+ * We begin by generating a mask of all CPUs that any thread in the
+ * process may be running on.
+ */
+ cpumask_clear(&process_cpus);
+ for_each_thread(task, t)
+ cpumask_set_cpu(task_cpu(t), &process_cpus);
+
+ /*
+ * Now we schedule prepare_for_fp_mode_switch() on each of those CPUs.
+ *
+ * The CPUs may have rescheduled already since we switched mode or
+ * generated the cpumask, but that doesn't matter. If the task in this
+ * process is scheduled out then our scheduling
+ * prepare_for_fp_mode_switch() will simply be redundant. If it's
+ * scheduled in then it will already have picked up the new FP mode
+ * whilst doing so.
+ */
+ get_online_cpus();
+ for_each_cpu_and(cpu, &process_cpus, cpu_online_mask)
+ work_on_cpu(cpu, prepare_for_fp_mode_switch, NULL);
+ put_online_cpus();
return 0;
}
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 5d19ed07e99d..b0a684e7b8fa 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -1237,13 +1237,6 @@ static int enable_restore_fp_context(int msa)
{
int err, was_fpu_owner, prior_msa;
- /*
- * If an FP mode switch is currently underway, wait for it to
- * complete before proceeding.
- */
- wait_on_atomic_t(¤t->mm->context.fp_mode_switching,
- atomic_t_wait, TASK_KILLABLE);
-
if (!used_math()) {
/* First time FP context user. */
preempt_disable();
--
2.15.1
This is the start of the stable review cycle for the 4.13.15 release.
There are 28 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Tue Nov 21 14:42:57 UTC 2017.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.13.15-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.13.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.13.15-rc1
Hans de Goede <hdegoede(a)redhat.com>
staging: rtl8188eu: Revert 4 commits breaking ARP
Hans de Goede <hdegoede(a)redhat.com>
staging: vboxvideo: Fix reporting invalid suggested-offset-properties
Johan Hovold <johan(a)kernel.org>
staging: greybus: spilib: fix use-after-free after deregistration
Gilad Ben-Yossef <gilad(a)benyossef.com>
staging: ccree: fix 64 bit scatter/gather DMA ops
Huacai Chen <chenhc(a)lemote.com>
staging: sm750fb: Fix parameter mistake in poke32
Aditya Shankar <aditya.shankar(a)microchip.com>
staging: wilc1000: Fix bssid buffer offset in Txq
Jason Gerecke <killertofu(a)gmail.com>
HID: wacom: generic: Recognize WACOM_HID_WD_PEN as a type of pen collection
Sébastien Szymanski <sebastien.szymanski(a)armadeus.com>
HID: cp2112: add HIDRAW dependency
Hans de Goede <hdegoede(a)redhat.com>
platform/x86: peaq_wmi: Fix missing terminating entry for peaq_dmi_table
Hans de Goede <hdegoede(a)redhat.com>
platform/x86: peaq-wmi: Add DMI check before binding to the WMI interface
Yazen Ghannam <yazen.ghannam(a)amd.com>
x86/MCE/AMD: Always give panic severity for UC errors in kernel context
Andy Lutomirski <luto(a)kernel.org>
selftests/x86/protection_keys: Fix syscall NR redefinition warnings
Johan Hovold <johan(a)kernel.org>
USB: serial: garmin_gps: fix memory leak on probe errors
Johan Hovold <johan(a)kernel.org>
USB: serial: garmin_gps: fix I/O after failed probe and remove
Douglas Fischer <douglas.fischer(a)outlook.com>
USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update
Lu Baolu <baolu.lu(a)linux.intel.com>
USB: serial: Change DbC debug device binding ID
Johan Hovold <johan(a)kernel.org>
USB: serial: metro-usb: stop I/O after failed open
Andrew Gabbasov <andrew_gabbasov(a)mentor.com>
usb: gadget: f_fs: Fix use-after-free in ffs_free_inst
Bernhard Rosenkraenzer <bernhard.rosenkranzer(a)linaro.org>
USB: Add delay-init quirk for Corsair K70 LUX keyboards
Alan Stern <stern(a)rowland.harvard.edu>
USB: usbfs: compute urb->actual_length for isochronous
Lu Baolu <baolu.lu(a)linux.intel.com>
USB: early: Use new USB product ID and strings for DbC device
raveendra padasalagi <raveendra.padasalagi(a)broadcom.com>
crypto: brcm - Explicity ACK mailbox message
Eric Biggers <ebiggers(a)google.com>
crypto: dh - Don't permit 'key' or 'g' size longer than 'p'
Eric Biggers <ebiggers(a)google.com>
crypto: dh - Don't permit 'p' to be 0
Eric Biggers <ebiggers(a)google.com>
crypto: dh - Fix double free of ctx->p
Leif Liddy <leif.linux(a)gmail.com>
Bluetooth: btusb: fix QCA Rome suspend/resume
Andrey Konovalov <andreyknvl(a)google.com>
media: dib0700: fix invalid dvb_detach argument
Arvind Yadav <arvind.yadav.cs(a)gmail.com>
media: imon: Fix null-ptr-deref in imon_probe
-------------
Diffstat:
Makefile | 4 +-
arch/x86/kernel/cpu/mcheck/mce-severity.c | 7 +-
crypto/dh.c | 33 ++++-----
crypto/dh_helper.c | 16 ++++
drivers/bluetooth/btusb.c | 6 ++
drivers/crypto/bcm/cipher.c | 101 ++++++++++++--------------
drivers/hid/Kconfig | 2 +-
drivers/hid/wacom_wac.h | 1 +
drivers/media/rc/imon.c | 5 ++
drivers/media/usb/dvb-usb/dib0700_devices.c | 24 +++---
drivers/platform/x86/peaq-wmi.c | 19 +++++
drivers/staging/ccree/cc_lli_defs.h | 2 +-
drivers/staging/greybus/spilib.c | 8 +-
drivers/staging/rtl8188eu/core/rtw_recv.c | 83 ++++++++++++---------
drivers/staging/rtl8188eu/os_dep/mon.c | 34 ++-------
drivers/staging/sm750fb/ddk750_chip.h | 2 +-
drivers/staging/vboxvideo/vbox_drv.h | 8 +-
drivers/staging/vboxvideo/vbox_irq.c | 4 +-
drivers/staging/vboxvideo/vbox_mode.c | 26 +++++--
drivers/staging/wilc1000/wilc_wlan.c | 2 +-
drivers/usb/core/devio.c | 14 ++++
drivers/usb/core/quirks.c | 3 +
drivers/usb/early/xhci-dbc.h | 6 +-
drivers/usb/gadget/function/f_fs.c | 1 +
drivers/usb/serial/garmin_gps.c | 22 +++++-
drivers/usb/serial/metro-usb.c | 11 ++-
drivers/usb/serial/qcserial.c | 1 +
drivers/usb/serial/usb_debug.c | 4 +-
tools/testing/selftests/x86/protection_keys.c | 24 ++++--
29 files changed, 280 insertions(+), 193 deletions(-)
Following commit 9427ecbed46cc ("gpio: Rework of_gpiochip_set_names()
to use device property accessors"), "gpio-line-names" DT property is
not retrieved anymore when chip->parent is not set by the driver.
This is due to OF based property reads having been replaced by device
based property reads.
This patch fixes that by making use of
fwnode_property_read_string_array() instead of
device_property_read_string_array() and handing over either
of_fwnode_handle(chip->of_node) or dev_fwnode(chip->parent)
to that function.
Fixes: 9427ecbed46cc ("gpio: Rework of_gpiochip_set_names() to use device property accessors")
Cc: stable(a)vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr>
---
drivers/gpio/gpiolib-acpi.c | 2 +-
drivers/gpio/gpiolib-devprop.c | 17 +++++++----------
drivers/gpio/gpiolib-of.c | 3 ++-
drivers/gpio/gpiolib.h | 3 ++-
4 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index eb4528c87c0b..d6f3d9ee1350 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -1074,7 +1074,7 @@ void acpi_gpiochip_add(struct gpio_chip *chip)
}
if (!chip->names)
- devprop_gpiochip_set_names(chip);
+ devprop_gpiochip_set_names(chip, dev_fwnode(chip->parent));
acpi_gpiochip_request_regions(acpi_gpio);
acpi_gpiochip_scan_gpios(acpi_gpio);
diff --git a/drivers/gpio/gpiolib-devprop.c b/drivers/gpio/gpiolib-devprop.c
index 27f383bda7d9..f748aa3e77f7 100644
--- a/drivers/gpio/gpiolib-devprop.c
+++ b/drivers/gpio/gpiolib-devprop.c
@@ -19,30 +19,27 @@
/**
* devprop_gpiochip_set_names - Set GPIO line names using device properties
* @chip: GPIO chip whose lines should be named, if possible
+ * @fwnode: Property Node containing the gpio-line-names property
*
* Looks for device property "gpio-line-names" and if it exists assigns
* GPIO line names for the chip. The memory allocated for the assigned
* names belong to the underlying firmware node and should not be released
* by the caller.
*/
-void devprop_gpiochip_set_names(struct gpio_chip *chip)
+void devprop_gpiochip_set_names(struct gpio_chip *chip,
+ const struct fwnode_handle *fwnode)
{
struct gpio_device *gdev = chip->gpiodev;
const char **names;
int ret, i;
- if (!chip->parent) {
- dev_warn(&gdev->dev, "GPIO chip parent is NULL\n");
- return;
- }
-
- ret = device_property_read_string_array(chip->parent, "gpio-line-names",
+ ret = fwnode_property_read_string_array(fwnode, "gpio-line-names",
NULL, 0);
if (ret < 0)
return;
if (ret != gdev->ngpio) {
- dev_warn(chip->parent,
+ dev_warn(&gdev->dev,
"names %d do not match number of GPIOs %d\n", ret,
gdev->ngpio);
return;
@@ -52,10 +49,10 @@ void devprop_gpiochip_set_names(struct gpio_chip *chip)
if (!names)
return;
- ret = device_property_read_string_array(chip->parent, "gpio-line-names",
+ ret = fwnode_property_read_string_array(fwnode, "gpio-line-names",
names, gdev->ngpio);
if (ret < 0) {
- dev_warn(chip->parent, "failed to read GPIO line names\n");
+ dev_warn(&gdev->dev, "failed to read GPIO line names\n");
kfree(names);
return;
}
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index e0d59e61b52f..72a0695d2ac3 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -493,7 +493,8 @@ int of_gpiochip_add(struct gpio_chip *chip)
/* If the chip defines names itself, these take precedence */
if (!chip->names)
- devprop_gpiochip_set_names(chip);
+ devprop_gpiochip_set_names(chip,
+ of_fwnode_handle(chip->of_node));
of_node_get(chip->of_node);
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index af48322839c3..6c44d1652139 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -228,7 +228,8 @@ static inline int gpio_chip_hwgpio(const struct gpio_desc *desc)
return desc - &desc->gdev->descs[0];
}
-void devprop_gpiochip_set_names(struct gpio_chip *chip);
+void devprop_gpiochip_set_names(struct gpio_chip *chip,
+ const struct fwnode_handle *fwnode);
/* With descriptor prefix */
--
2.13.3
Quoting Maxime Ripard (2017-12-19 00:32:28)
> On Mon, Dec 18, 2017 at 01:07:09PM -0800, Stephen Boyd wrote:
> > On 12/18, Chen-Yu Tsai wrote:
> > > Our MMC host driver now issues a reset, instead of just deasserting
> > > the reset control, since commit c34eda69ad4c ("mmc: sunxi: Reset the
> > > device at probe time"). The sun9i-mmc clock driver does not support
> > > this, and will fail, which results in MMC not probing.
> > >
> > > This patch implements the reset callback by asserting the reset control,
> > > then deasserting it after a small delay.
> > >
> > > Fixes: 7a6fca879f59 ("clk: sunxi: Add driver for A80 MMC config clocks/resets")
> > > Cc: <stable(a)vger.kernel.org> # 4.14.x
> > > Signed-off-by: Chen-Yu Tsai <wens(a)csie.org>
> > > ---
> >
> > Did you want us to pick this up into clk-fixes? It seems to be
> > causing MMC to not work for some time? That sounds annoying
> > enough.
>
> That would be great, thanks!
Applied to clk-fixes.
Regards,
Mike
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
USB 3.1 devices are not detected as 3.1 capable since 4.15-rc3 due to a
off by one in commit 81cf4a45360f ("USB: core: Add type-specific length
check of BOS descriptors")
It uses USB_DT_USB_SSP_CAP_SIZE() to get SSP capability size which takes
the zero based SSAC as argument, not the actual count of sublink speed
attributes.
USB3 spec 9.6.2.5 says "The number of Sublink Speed Attributes = SSAC + 1."
The type-specific length check patch was added to stable and needs to be
fixed there as well
Fixes: 81cf4a45360f ("USB: core: Add type-specific length check of BOS descriptors")
Cc: linux-stable <stable(a)vger.kernel.org>
CC: Masakazu Mokuno <masakazu.mokuno(a)gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
---
drivers/usb/core/config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 78e92d2..c821b4b 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -1007,7 +1007,7 @@ int usb_get_bos_descriptor(struct usb_device *dev)
case USB_SSP_CAP_TYPE:
ssp_cap = (struct usb_ssp_cap_descriptor *)buffer;
ssac = (le32_to_cpu(ssp_cap->bmAttributes) &
- USB_SSP_SUBLINK_SPEED_ATTRIBS) + 1;
+ USB_SSP_SUBLINK_SPEED_ATTRIBS);
if (length >= USB_DT_USB_SSP_CAP_SIZE(ssac))
dev->bos->ssp_cap = ssp_cap;
break;
--
2.7.4
From: Yelena Krivosheev <yelena(a)marvell.com>
There are few reasons in mvneta_rx_swbm() function when received packet
is dropped. mvneta_rx_error() should be called only if error bit [16]
is set in rx descriptor.
[gregory.clement(a)free-electrons.com: add fixes tag]
Cc: stable(a)vger.kernel.org
Fixes: dc35a10f68d3 ("net: mvneta: bm: add support for hardware buffer management")
Signed-off-by: Yelena Krivosheev <yelena(a)marvell.com>
Tested-by: Dmitri Epshtein <dima(a)marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement(a)free-electrons.com>
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 1e0835655c93..a539263cd79c 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1962,9 +1962,9 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
if (!mvneta_rxq_desc_is_first_last(rx_status) ||
(rx_status & MVNETA_RXD_ERR_SUMMARY)) {
+ mvneta_rx_error(pp, rx_desc);
err_drop_frame:
dev->stats.rx_errors++;
- mvneta_rx_error(pp, rx_desc);
/* leave the descriptor untouched */
continue;
}
--
2.15.1
This fixes a hang issue seen when changing the MTU size from 1500 MTU
to 9000 MTU on both 5717 and 5719 chips. In discussion with Broadcom,
they've indicated that these chipsets have the same phy as the 57766
chipset, so the same workarounds apply. This has been tested by IBM
on both Power 8 and Power 9 systems as well as by Broadcom on x86
hardware and has been confirmed to resolve the hang issue.
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com>
---
drivers/net/ethernet/broadcom/tg3.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index de51c21..d09c5a9 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -14225,7 +14225,9 @@ static int tg3_change_mtu(struct net_device *dev, int new_mtu)
/* Reset PHY, otherwise the read DMA engine will be in a mode that
* breaks all requests to 256 bytes.
*/
- if (tg3_asic_rev(tp) == ASIC_REV_57766)
+ if (tg3_asic_rev(tp) == ASIC_REV_57766 ||
+ tg3_asic_rev(tp) == ASIC_REV_5717 ||
+ tg3_asic_rev(tp) == ASIC_REV_5719)
reset_phy = true;
err = tg3_restart_hw(tp, reset_phy);
--
1.8.3.1
This is a note to let you know that I've just added the patch titled
USB: chipidea: msm: fix ulpi-node lookup
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 964728f9f407eca0b417fdf8e784b7a76979490c Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Mon, 13 Nov 2017 11:12:58 +0100
Subject: USB: chipidea: msm: fix ulpi-node lookup
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
Note that the original premature free of the parent node has already
been fixed separately, but that fix was apparently never backported to
stable.
Fixes: 47654a162081 ("usb: chipidea: msm: Restore wrapper settings after reset")
Fixes: b74c43156c0c ("usb: chipidea: msm: ci_hdrc_msm_probe() missing of_node_get()")
Cc: stable <stable(a)vger.kernel.org> # 4.10: b74c43156c0c
Cc: Stephen Boyd <stephen.boyd(a)linaro.org>
Cc: Frank Rowand <frank.rowand(a)sony.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Peter Chen <peter.chen(a)nxp.com>
---
drivers/usb/chipidea/ci_hdrc_msm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c b/drivers/usb/chipidea/ci_hdrc_msm.c
index 3593ce0ec641..880009987460 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -247,7 +247,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
if (ret)
goto err_mux;
- ulpi_node = of_find_node_by_name(of_node_get(pdev->dev.of_node), "ulpi");
+ ulpi_node = of_get_child_by_name(pdev->dev.of_node, "ulpi");
if (ulpi_node) {
phy_node = of_get_next_available_child(ulpi_node, NULL);
ci->hsic = of_device_is_compatible(phy_node, "qcom,usb-hsic-phy");
--
2.15.1
This is a note to let you know that I've just added the patch titled
staging: android: ion: Fix dma direction for
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From d6b246bb7a29703f53aa4c050b8b3205d749caee Mon Sep 17 00:00:00 2001
From: Sushmita Susheelendra <ssusheel(a)codeaurora.org>
Date: Fri, 15 Dec 2017 13:59:13 -0700
Subject: staging: android: ion: Fix dma direction for
dma_sync_sg_for_cpu/device
Use the direction argument passed into begin_cpu_access
and end_cpu_access when calling the dma_sync_sg_for_cpu/device.
The actual cache primitive called depends on the direction
passed in.
Signed-off-by: Sushmita Susheelendra <ssusheel(a)codeaurora.org>
Cc: stable <stable(a)vger.kernel.org>
Acked-by: Laura Abbott <labbott(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ion/ion.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index a7d9b0e98572..f480885e346b 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -346,7 +346,7 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
dma_sync_sg_for_cpu(a->dev, a->table->sgl, a->table->nents,
- DMA_BIDIRECTIONAL);
+ direction);
}
mutex_unlock(&buffer->lock);
@@ -368,7 +368,7 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
dma_sync_sg_for_device(a->dev, a->table->sgl, a->table->nents,
- DMA_BIDIRECTIONAL);
+ direction);
}
mutex_unlock(&buffer->lock);
--
2.15.1
This is the start of the stable review cycle for the 3.18.89 release.
There are 69 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Dec 20 15:26:44 UTC 2017.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.89-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 3.18.89-rc1
Bin Liu <b-liu(a)ti.com>
usb: musb: da8xx: fix babble condition handling
Miaoqing Pan <miaoqing(a)codeaurora.org>
ath9k: fix tx99 potential info leak
Alexander Duyck <alexander.h.duyck(a)intel.com>
macvlan: Only deliver one copy of the frame to the macvlan interface
Jan Kara <jack(a)suse.cz>
udf: Avoid overflow when session starts at large offset
Dan Carpenter <dan.carpenter(a)oracle.com>
scsi: bfa: integer overflow in debugfs
Kurt Garloff <garloff(a)suse.de>
scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry
NeilBrown <neilb(a)suse.com>
raid5: Set R5_Expanded on parity devices as well as data.
Linus Walleij <linus.walleij(a)linaro.org>
pinctrl: adi2: Fix Kconfig build problem
nixiaoming <nixiaoming(a)huawei.com>
tty fix oops when rmmod 8250
Alex Williamson <alex.williamson(a)redhat.com>
PCI: Detach driver before procfs & sysfs teardown on device remove
Brian Foster <bfoster(a)redhat.com>
xfs: fix log block underflow during recovery cycle verification
tang.junhui <tang.junhui(a)zte.com.cn>
bcache: fix wrong cache_misses statistics
Liang Chen <liangchen.linux(a)gmail.com>
bcache: explicitly destroy mutex while exiting
Bob Peterson <rpeterso(a)redhat.com>
GFS2: Take inode off order_write list when setting jdata flag
Daniel Lezcano <daniel.lezcano(a)linaro.org>
thermal/drivers/step_wise: Fix temperature regulation misbehavior
Gao Feng <gfree.wind(a)vip.163.com>
ppp: Destroy the mutex when cleanup
Michał Mirosław <mirq-linux(a)rere.qmqm.pl>
clk: tegra: Fix cclk_lp divisor register
Jan Kara <jack(a)suse.cz>
mm: Handle 0 flags in _calc_vm_trans() macro
Suzuki K Poulose <suzuki.poulose(a)arm.com>
arm-ccn: perf: Prevent module unload while PMU is in use
Jiang Yi <jiangyilism(a)gmail.com>
target/file: Do not return error for UNMAP if length is zero
tangwenji <tang.wenji(a)zte.com.cn>
target:fix condition return in core_pr_dump_initiator_port()
tangwenji <tang.wenji(a)zte.com.cn>
iscsi-target: fix memory leak in lio_target_tiqn_addtpg()
Bart Van Assche <bart.vanassche(a)wdc.com>
target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd()
Markus Elfring <elfring(a)users.sourceforge.net>
platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill()
Christophe Leroy <christophe.leroy(a)c-s.fr>
powerpc/ipic: Fix status get and status clear
William A. Kennington III <wak(a)google.com>
powerpc/opal: Fix EBUSY bug in acquiring tokens
Shriya <shriyak(a)linux.vnet.ibm.com>
powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo
Qiang <zhengqiang10(a)huawei.com>
PCI/PME: Handle invalid data when reading Root Status
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
video: fbdev: au1200fb: Return an error code if a memory allocation fails
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
video: fbdev: au1200fb: Release some resources if a memory allocation fails
Ladislav Michl <ladis(a)linux-mips.org>
video: udlfb: Fix read EDID timeout
Geert Uytterhoeven <geert(a)linux-m68k.org>
fbdev: controlfb: Add missing modes to fix out of bounds access
Mike Christie <mchristi(a)redhat.com>
target: Use system workqueue for ALUA transitions
Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org>
btrfs: add missing memset while reading compressed inline extents
Olga Kornievskaia <kolga(a)netapp.com>
NFSv4.1 respect server's max size in CREATE_SESSION
Daniel Borkmann <daniel(a)iogearbox.net>
perf symbols: Fix symbols__fixup_end heuristic for corner cases
David Howells <dhowells(a)redhat.com>
afs: Fix afs_kill_pages()
David Howells <dhowells(a)redhat.com>
afs: Fix page leak in afs_write_begin()
Marc Dionne <marc.dionne(a)auristor.com>
afs: Populate and use client modification time
David Howells <dhowells(a)redhat.com>
afs: Fix the maths in afs_fs_store_data()
David Howells <dhowells(a)redhat.com>
afs: Flush outstanding writes when an fd is closed
Marc Dionne <marc.dionne(a)auristor.com>
afs: Adjust mode bits processing
Marc Dionne <marc.dionne(a)auristor.com>
afs: Populate group ID from vnode status
David Howells <dhowells(a)redhat.com>
afs: Fix missing put_page()
Alex Deucher <alexander.deucher(a)amd.com>
drm/radeon: reinstate oland workaround for sclk
Steven Rostedt (VMware) <rostedt(a)goodmis.org>
sched/deadline: Use deadline instead of period when calculating overflow
Alex Deucher <alexander.deucher(a)amd.com>
drm/radeon/si: add dpm quirk for Oland
Stafford Horne <shorne(a)gmail.com>
openrisc: fix issue handling 8 byte get_user calls
Vlad Yasevich <vyasevich(a)gmail.com>
net: Resend IGMP memberships upon peer notification.
Matthias Kaehlcke <mka(a)chromium.org>
dmaengine: Fix array index out of bounds warning in __get_unmap_pool()
Johan Hovold <johan(a)kernel.org>
net: wimax/i2400m: fix NULL-deref at probe
Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list
NeilBrown <neilb(a)suse.com>
NFSD: fix nfsd_reset_versions for NFSv4.
NeilBrown <neilb(a)suse.com>
NFSD: fix nfsd_minorversion(.., NFSD_AVAIL)
Doug Berger <opendmb(a)gmail.com>
net: bcmgenet: Power up the internal PHY before probing the MII
Doug Berger <opendmb(a)gmail.com>
net: bcmgenet: correct MIB access of UniMAC RUNT counters
Doug Berger <opendmb(a)gmail.com>
net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values
Javier Martinez Canillas <javier(a)osg.samsung.com>
usb: phy: isp1301: Add OF device ID table
Ilan peer <ilan.peer(a)intel.com>
mac80211: Fix addition of mesh configuration element
David Howells <dhowells(a)redhat.com>
KEYS: Don't permit request_key() to construct a new keyring
David Jeffery <djeffery(a)redhat.com>
Don't leak a key reference if request_key() tries to use a revoked keyring
Chandan Rajendra <chandan(a)linux.vnet.ibm.com>
ext4: fix crash when a directory's i_size is too small
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: Don't add a virt_dev to the devs array before it's fully allocated
Shuah Khan <shuahkh(a)osg.samsung.com>
usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer
Alan Stern <stern(a)rowland.harvard.edu>
USB: core: prevent malicious bNumInterfaces overflow
David Kozub <zub(a)linux.fjfi.cvut.cz>
USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID
NeilBrown <neilb(a)suse.com>
autofs: fix careless error in recent commit
Eric Biggers <ebiggers(a)google.com>
crypto: salsa20 - fix blkcipher_walk API usage
Eric Biggers <ebiggers(a)google.com>
crypto: hmac - require that the underlying hash algorithm is unkeyed
-------------
Diffstat:
Makefile | 4 +-
arch/blackfin/Kconfig | 7 ++-
arch/blackfin/Kconfig.debug | 1 +
arch/openrisc/include/asm/uaccess.h | 2 +-
arch/powerpc/platforms/powernv/opal-async.c | 6 +-
arch/powerpc/platforms/powernv/setup.c | 2 +-
arch/powerpc/sysdev/ipic.c | 4 +-
arch/x86/crypto/salsa20_glue.c | 7 ---
crypto/hmac.c | 6 +-
crypto/salsa20_generic.c | 7 ---
crypto/shash.c | 5 +-
drivers/bus/arm-ccn.c | 1 +
drivers/clk/tegra/clk-tegra30.c | 2 +-
drivers/dma/dmaengine.c | 2 +
drivers/gpu/drm/radeon/si_dpm.c | 10 ++++
drivers/input/serio/i8042-x86ia64io.h | 7 +++
drivers/md/bcache/request.c | 6 +-
drivers/md/bcache/super.c | 6 +-
drivers/md/raid5.c | 5 +-
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 79 ++++++++++++++++++++++----
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 10 +++-
drivers/net/macvlan.c | 2 +-
drivers/net/ppp/ppp_generic.c | 1 +
drivers/net/wimax/i2400m/usb.c | 3 +
drivers/net/wireless/ath/ath9k/tx99.c | 5 ++
drivers/pci/pcie/pme.c | 5 +-
drivers/pci/remove.c | 2 +-
drivers/pinctrl/Kconfig | 3 +-
drivers/platform/x86/sony-laptop.c | 14 +++--
drivers/scsi/bfa/bfad_debugfs.c | 5 +-
drivers/scsi/scsi_devinfo.c | 2 +-
drivers/target/iscsi/iscsi_target.c | 3 +-
drivers/target/iscsi/iscsi_target_configfs.c | 3 +-
drivers/target/target_core_alua.c | 8 +--
drivers/target/target_core_file.c | 4 ++
drivers/target/target_core_pr.c | 4 +-
drivers/thermal/step_wise.c | 11 ++--
drivers/usb/core/config.c | 4 +-
drivers/usb/host/xhci-mem.c | 15 +++--
drivers/usb/musb/da8xx.c | 10 +++-
drivers/usb/phy/phy-isp1301.c | 7 +++
drivers/usb/storage/unusual_devs.h | 7 +++
drivers/usb/storage/unusual_uas.h | 7 +++
drivers/usb/usbip/stub_tx.c | 7 +++
drivers/video/fbdev/au1200fb.c | 7 ++-
drivers/video/fbdev/controlfb.h | 2 +
drivers/video/fbdev/udlfb.c | 10 ++--
fs/afs/file.c | 1 +
fs/afs/fsclient.c | 20 +++----
fs/afs/inode.c | 4 +-
fs/afs/internal.h | 1 +
fs/afs/security.c | 7 ++-
fs/afs/write.c | 32 +++++++++--
fs/autofs4/waitq.c | 1 -
fs/btrfs/inode.c | 14 +++++
fs/ext4/namei.c | 4 ++
fs/gfs2/file.c | 4 +-
fs/nfs/nfs4client.c | 4 +-
fs/nfsd/nfssvc.c | 30 +++++-----
fs/proc/proc_tty.c | 3 +-
fs/udf/super.c | 2 +-
fs/xfs/xfs_log_recover.c | 2 +-
include/crypto/internal/hash.h | 8 +++
include/linux/mman.h | 3 +-
kernel/sched/deadline.c | 8 +--
net/core/dev.c | 1 +
net/mac80211/mesh.c | 2 -
security/keys/request_key.c | 4 ++
tools/perf/util/symbol.c | 2 +-
69 files changed, 352 insertions(+), 135 deletions(-)
This is a note to let you know that I've just added the patch titled
usb: Add device quirk for Logitech HD Pro Webcam C925e
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 7f038d256c723dd390d2fca942919573995f4cfd Mon Sep 17 00:00:00 2001
From: Dmitry Fleytman Dmitry Fleytman <dmitry.fleytman(a)gmail.com>
Date: Tue, 19 Dec 2017 06:02:04 +0200
Subject: usb: Add device quirk for Logitech HD Pro Webcam C925e
Commit e0429362ab15
("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
introduced quirk to workaround an issue with some Logitech webcams.
There is one more model that has the same issue - C925e, so applying
the same quirk as well.
See aforementioned commit message for detailed explanation of the problem.
Signed-off-by: Dmitry Fleytman <dmitry.fleytman(a)gmail.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 95812656d9b9..4024926c1d68 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -52,10 +52,11 @@ static const struct usb_device_id usb_quirk_list[] = {
/* Microsoft LifeCam-VX700 v2.0 */
{ USB_DEVICE(0x045e, 0x0770), .driver_info = USB_QUIRK_RESET_RESUME },
- /* Logitech HD Pro Webcams C920, C920-C and C930e */
+ /* Logitech HD Pro Webcams C920, C920-C, C925e and C930e */
{ USB_DEVICE(0x046d, 0x082d), .driver_info = USB_QUIRK_DELAY_INIT },
{ USB_DEVICE(0x046d, 0x0841), .driver_info = USB_QUIRK_DELAY_INIT },
{ USB_DEVICE(0x046d, 0x0843), .driver_info = USB_QUIRK_DELAY_INIT },
+ { USB_DEVICE(0x046d, 0x085b), .driver_info = USB_QUIRK_DELAY_INIT },
/* Logitech ConferenceCam CC3000e */
{ USB_DEVICE(0x046d, 0x0847), .driver_info = USB_QUIRK_DELAY_INIT },
--
2.15.1
This is a note to let you know that I've just added the patch titled
usbip: fix usbip bind writing random string after command in
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 544c4605acc5ae4afe7dd5914147947db182f2fb Mon Sep 17 00:00:00 2001
From: Juan Zea <juan.zea(a)qindel.com>
Date: Fri, 15 Dec 2017 10:21:20 +0100
Subject: usbip: fix usbip bind writing random string after command in
match_busid
usbip bind writes commands followed by random string when writing to
match_busid attribute in sysfs, caused by using full variable size
instead of string length.
Signed-off-by: Juan Zea <juan.zea(a)qindel.com>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/usb/usbip/src/utils.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tools/usb/usbip/src/utils.c b/tools/usb/usbip/src/utils.c
index 2b3d6d235015..3d7b42e77299 100644
--- a/tools/usb/usbip/src/utils.c
+++ b/tools/usb/usbip/src/utils.c
@@ -30,6 +30,7 @@ int modify_match_busid(char *busid, int add)
char command[SYSFS_BUS_ID_SIZE + 4];
char match_busid_attr_path[SYSFS_PATH_MAX];
int rc;
+ int cmd_size;
snprintf(match_busid_attr_path, sizeof(match_busid_attr_path),
"%s/%s/%s/%s/%s/%s", SYSFS_MNT_PATH, SYSFS_BUS_NAME,
@@ -37,12 +38,14 @@ int modify_match_busid(char *busid, int add)
attr_name);
if (add)
- snprintf(command, SYSFS_BUS_ID_SIZE + 4, "add %s", busid);
+ cmd_size = snprintf(command, SYSFS_BUS_ID_SIZE + 4, "add %s",
+ busid);
else
- snprintf(command, SYSFS_BUS_ID_SIZE + 4, "del %s", busid);
+ cmd_size = snprintf(command, SYSFS_BUS_ID_SIZE + 4, "del %s",
+ busid);
rc = write_sysfs_attribute(match_busid_attr_path, command,
- sizeof(command));
+ cmd_size);
if (rc < 0) {
dbg("failed to write match_busid: %s", strerror(errno));
return -1;
--
2.15.1
This is a note to let you know that I've just added the patch titled
usbip: prevent leaking socket pointer address in messages
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 90120d15f4c397272aaf41077960a157fc4212bf Mon Sep 17 00:00:00 2001
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Fri, 15 Dec 2017 10:50:09 -0700
Subject: usbip: prevent leaking socket pointer address in messages
usbip driver is leaking socket pointer address in messages. Remove
the messages that aren't useful and print sockfd in the ones that
are useful for debugging.
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/stub_dev.c | 3 +--
drivers/usb/usbip/usbip_common.c | 16 +++++-----------
drivers/usb/usbip/vhci_hcd.c | 2 +-
3 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c
index a3df8ee82faf..e31a6f204397 100644
--- a/drivers/usb/usbip/stub_dev.c
+++ b/drivers/usb/usbip/stub_dev.c
@@ -149,8 +149,7 @@ static void stub_shutdown_connection(struct usbip_device *ud)
* step 1?
*/
if (ud->tcp_socket) {
- dev_dbg(&sdev->udev->dev, "shutdown tcp_socket %p\n",
- ud->tcp_socket);
+ dev_dbg(&sdev->udev->dev, "shutdown sockfd %d\n", ud->sockfd);
kernel_sock_shutdown(ud->tcp_socket, SHUT_RDWR);
}
diff --git a/drivers/usb/usbip/usbip_common.c b/drivers/usb/usbip/usbip_common.c
index f7978933b402..7b219d9109b4 100644
--- a/drivers/usb/usbip/usbip_common.c
+++ b/drivers/usb/usbip/usbip_common.c
@@ -317,26 +317,20 @@ int usbip_recv(struct socket *sock, void *buf, int size)
struct msghdr msg = {.msg_flags = MSG_NOSIGNAL};
int total = 0;
+ if (!sock || !buf || !size)
+ return -EINVAL;
+
iov_iter_kvec(&msg.msg_iter, READ|ITER_KVEC, &iov, 1, size);
usbip_dbg_xmit("enter\n");
- if (!sock || !buf || !size) {
- pr_err("invalid arg, sock %p buff %p size %d\n", sock, buf,
- size);
- return -EINVAL;
- }
-
do {
- int sz = msg_data_left(&msg);
+ msg_data_left(&msg);
sock->sk->sk_allocation = GFP_NOIO;
result = sock_recvmsg(sock, &msg, MSG_WAITALL);
- if (result <= 0) {
- pr_debug("receive sock %p buf %p size %u ret %d total %d\n",
- sock, buf + total, sz, result, total);
+ if (result <= 0)
goto err;
- }
total += result;
} while (msg_data_left(&msg));
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 9efab3dc3734..c3e1008aa491 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -965,7 +965,7 @@ static void vhci_shutdown_connection(struct usbip_device *ud)
/* need this? see stub_dev.c */
if (ud->tcp_socket) {
- pr_debug("shutdown tcp_socket %p\n", ud->tcp_socket);
+ pr_debug("shutdown tcp_socket %d\n", ud->sockfd);
kernel_sock_shutdown(ud->tcp_socket, SHUT_RDWR);
}
--
2.15.1
This is a note to let you know that I've just added the patch titled
usbip: stub: stop printing kernel pointer addresses in messages
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 248a22044366f588d46754c54dfe29ffe4f8b4df Mon Sep 17 00:00:00 2001
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Mon, 18 Dec 2017 17:23:37 -0700
Subject: usbip: stub: stop printing kernel pointer addresses in messages
Remove and/or change debug, info. and error messages to not print
kernel pointer addresses.
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/stub_main.c | 5 +++--
drivers/usb/usbip/stub_rx.c | 7 ++-----
drivers/usb/usbip/stub_tx.c | 6 +++---
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
index 4f48b306713f..c31c8402a0c5 100644
--- a/drivers/usb/usbip/stub_main.c
+++ b/drivers/usb/usbip/stub_main.c
@@ -237,11 +237,12 @@ void stub_device_cleanup_urbs(struct stub_device *sdev)
struct stub_priv *priv;
struct urb *urb;
- dev_dbg(&sdev->udev->dev, "free sdev %p\n", sdev);
+ dev_dbg(&sdev->udev->dev, "Stub device cleaning up urbs\n");
while ((priv = stub_priv_pop(sdev))) {
urb = priv->urb;
- dev_dbg(&sdev->udev->dev, "free urb %p\n", urb);
+ dev_dbg(&sdev->udev->dev, "free urb seqnum %lu\n",
+ priv->seqnum);
usb_kill_urb(urb);
kmem_cache_free(stub_priv_cache, priv);
diff --git a/drivers/usb/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c
index 493ac2928391..2f29be474098 100644
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -211,9 +211,6 @@ static int stub_recv_cmd_unlink(struct stub_device *sdev,
if (priv->seqnum != pdu->u.cmd_unlink.seqnum)
continue;
- dev_info(&priv->urb->dev->dev, "unlink urb %p\n",
- priv->urb);
-
/*
* This matched urb is not completed yet (i.e., be in
* flight in usb hcd hardware/driver). Now we are
@@ -252,8 +249,8 @@ static int stub_recv_cmd_unlink(struct stub_device *sdev,
ret = usb_unlink_urb(priv->urb);
if (ret != -EINPROGRESS)
dev_err(&priv->urb->dev->dev,
- "failed to unlink a urb %p, ret %d\n",
- priv->urb, ret);
+ "failed to unlink a urb # %lu, ret %d\n",
+ priv->seqnum, ret);
return 0;
}
diff --git a/drivers/usb/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c
index 53172b1f6257..f0ec41a50cbc 100644
--- a/drivers/usb/usbip/stub_tx.c
+++ b/drivers/usb/usbip/stub_tx.c
@@ -88,7 +88,7 @@ void stub_complete(struct urb *urb)
/* link a urb to the queue of tx. */
spin_lock_irqsave(&sdev->priv_lock, flags);
if (sdev->ud.tcp_socket == NULL) {
- usbip_dbg_stub_tx("ignore urb for closed connection %p", urb);
+ usbip_dbg_stub_tx("ignore urb for closed connection\n");
/* It will be freed in stub_device_cleanup_urbs(). */
} else if (priv->unlinking) {
stub_enqueue_ret_unlink(sdev, priv->seqnum, urb->status);
@@ -190,8 +190,8 @@ static int stub_send_ret_submit(struct stub_device *sdev)
/* 1. setup usbip_header */
setup_ret_submit_pdu(&pdu_header, urb);
- usbip_dbg_stub_tx("setup txdata seqnum: %d urb: %p\n",
- pdu_header.base.seqnum, urb);
+ usbip_dbg_stub_tx("setup txdata seqnum: %d\n",
+ pdu_header.base.seqnum);
usbip_header_correct_endian(&pdu_header, 1);
iov[iovnum].iov_base = &pdu_header;
--
2.15.1
This is a note to let you know that I've just added the patch titled
USB: Fix off by one in type-specific length check of BOS SSP
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 07b9f12864d16c3a861aef4817eb1efccbc5d0e6 Mon Sep 17 00:00:00 2001
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Date: Tue, 19 Dec 2017 11:14:42 +0200
Subject: USB: Fix off by one in type-specific length check of BOS SSP
capability
USB 3.1 devices are not detected as 3.1 capable since 4.15-rc3 due to a
off by one in commit 81cf4a45360f ("USB: core: Add type-specific length
check of BOS descriptors")
It uses USB_DT_USB_SSP_CAP_SIZE() to get SSP capability size which takes
the zero based SSAC as argument, not the actual count of sublink speed
attributes.
USB3 spec 9.6.2.5 says "The number of Sublink Speed Attributes = SSAC + 1."
The type-specific length check patch was added to stable and needs to be
fixed there as well
Fixes: 81cf4a45360f ("USB: core: Add type-specific length check of BOS descriptors")
Cc: linux-stable <stable(a)vger.kernel.org>
CC: Masakazu Mokuno <masakazu.mokuno(a)gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 78e92d29f8d9..c821b4b9647e 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -1007,7 +1007,7 @@ int usb_get_bos_descriptor(struct usb_device *dev)
case USB_SSP_CAP_TYPE:
ssp_cap = (struct usb_ssp_cap_descriptor *)buffer;
ssac = (le32_to_cpu(ssp_cap->bmAttributes) &
- USB_SSP_SUBLINK_SPEED_ATTRIBS) + 1;
+ USB_SSP_SUBLINK_SPEED_ATTRIBS);
if (length >= USB_DT_USB_SSP_CAP_SIZE(ssac))
dev->bos->ssp_cap = ssp_cap;
break;
--
2.15.1
This is a note to let you know that I've just added the patch titled
phy: tegra: fix device-tree node lookups
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 046046737bd35bed047460f080ea47e186be731e Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Wed, 15 Nov 2017 10:43:16 +0100
Subject: phy: tegra: fix device-tree node lookups
Fix child-node lookups during probe, which ended up searching the whole
device tree depth-first starting at the parents rather than just
matching on their children.
To make things worse, some parent nodes could end up being being
prematurely freed (by tegra_xusb_pad_register()) as
of_find_node_by_name() drops a reference to its first argument.
Fixes: 53d2a715c240 ("phy: Add Tegra XUSB pad controller support")
Cc: stable <stable(a)vger.kernel.org> # 4.7
Cc: Thierry Reding <treding(a)nvidia.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
---
drivers/phy/tegra/xusb.c | 58 ++++++++++++++++++++++++------------------------
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c
index 4307bf0013e1..63e916d4d069 100644
--- a/drivers/phy/tegra/xusb.c
+++ b/drivers/phy/tegra/xusb.c
@@ -75,14 +75,14 @@ MODULE_DEVICE_TABLE(of, tegra_xusb_padctl_of_match);
static struct device_node *
tegra_xusb_find_pad_node(struct tegra_xusb_padctl *padctl, const char *name)
{
- /*
- * of_find_node_by_name() drops a reference, so make sure to grab one.
- */
- struct device_node *np = of_node_get(padctl->dev->of_node);
+ struct device_node *pads, *np;
+
+ pads = of_get_child_by_name(padctl->dev->of_node, "pads");
+ if (!pads)
+ return NULL;
- np = of_find_node_by_name(np, "pads");
- if (np)
- np = of_find_node_by_name(np, name);
+ np = of_get_child_by_name(pads, name);
+ of_node_put(pads);
return np;
}
@@ -90,16 +90,16 @@ tegra_xusb_find_pad_node(struct tegra_xusb_padctl *padctl, const char *name)
static struct device_node *
tegra_xusb_pad_find_phy_node(struct tegra_xusb_pad *pad, unsigned int index)
{
- /*
- * of_find_node_by_name() drops a reference, so make sure to grab one.
- */
- struct device_node *np = of_node_get(pad->dev.of_node);
+ struct device_node *np, *lanes;
- np = of_find_node_by_name(np, "lanes");
- if (!np)
+ lanes = of_get_child_by_name(pad->dev.of_node, "lanes");
+ if (!lanes)
return NULL;
- return of_find_node_by_name(np, pad->soc->lanes[index].name);
+ np = of_get_child_by_name(lanes, pad->soc->lanes[index].name);
+ of_node_put(lanes);
+
+ return np;
}
static int
@@ -195,7 +195,7 @@ int tegra_xusb_pad_register(struct tegra_xusb_pad *pad,
unsigned int i;
int err;
- children = of_find_node_by_name(pad->dev.of_node, "lanes");
+ children = of_get_child_by_name(pad->dev.of_node, "lanes");
if (!children)
return -ENODEV;
@@ -444,21 +444,21 @@ static struct device_node *
tegra_xusb_find_port_node(struct tegra_xusb_padctl *padctl, const char *type,
unsigned int index)
{
- /*
- * of_find_node_by_name() drops a reference, so make sure to grab one.
- */
- struct device_node *np = of_node_get(padctl->dev->of_node);
+ struct device_node *ports, *np;
+ char *name;
- np = of_find_node_by_name(np, "ports");
- if (np) {
- char *name;
+ ports = of_get_child_by_name(padctl->dev->of_node, "ports");
+ if (!ports)
+ return NULL;
- name = kasprintf(GFP_KERNEL, "%s-%u", type, index);
- if (!name)
- return ERR_PTR(-ENOMEM);
- np = of_find_node_by_name(np, name);
- kfree(name);
+ name = kasprintf(GFP_KERNEL, "%s-%u", type, index);
+ if (!name) {
+ of_node_put(ports);
+ return ERR_PTR(-ENOMEM);
}
+ np = of_get_child_by_name(ports, name);
+ kfree(name);
+ of_node_put(ports);
return np;
}
@@ -847,7 +847,7 @@ static void tegra_xusb_remove_ports(struct tegra_xusb_padctl *padctl)
static int tegra_xusb_padctl_probe(struct platform_device *pdev)
{
- struct device_node *np = of_node_get(pdev->dev.of_node);
+ struct device_node *np = pdev->dev.of_node;
const struct tegra_xusb_padctl_soc *soc;
struct tegra_xusb_padctl *padctl;
const struct of_device_id *match;
@@ -855,7 +855,7 @@ static int tegra_xusb_padctl_probe(struct platform_device *pdev)
int err;
/* for backwards compatibility with old device trees */
- np = of_find_node_by_name(np, "pads");
+ np = of_get_child_by_name(np, "pads");
if (!np) {
dev_warn(&pdev->dev, "deprecated DT, using legacy driver\n");
return tegra_xusb_padctl_legacy_probe(pdev);
--
2.15.1
Fix the default for fscache_maybe_release_page() for when the cookie isn't
valid or the page isn't cached. It mustn't return false as that indicates
the page cannot yet be freed.
The problem with the default is that if, say, there's no cache, but a
network filesystem's pages are using up almost all the available memory, a
system can OOM because the filesystem ->releasepage() op will not allow
them to be released as fscache_maybe_release_page() incorrectly prevents
it.
This can be tested by writing a sequence of 512MiB files to an AFS mount.
It does not affect NFS or CIFS because both of those wrap the call in a
check of PG_fscache and it shouldn't bother Ceph as that only has
PG_private set whilst writeback is in progress. This might be an issue for
9P, however.
Note that the pages aren't entirely stuck. Removing a file or unmounting
will clear things because that uses ->invalidatepage() instead.
Fixes: 201a15428bd5 ("FS-Cache: Handle pages pending storage that get evicted under OOM conditions")
Reported-by: Marc Dionne <marc.dionne(a)auristor.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Reviewed-by: Jeff Layton <jlayton(a)redhat.com>
Acked-by: Al Viro <viro(a)zeniv.linux.org.uk>
cc: stable(a)vger.kernel.org # 2.6.32+
---
include/linux/fscache.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fscache.h b/include/linux/fscache.h
index f4ff47d4a893..fe0c349684fa 100644
--- a/include/linux/fscache.h
+++ b/include/linux/fscache.h
@@ -755,7 +755,7 @@ bool fscache_maybe_release_page(struct fscache_cookie *cookie,
{
if (fscache_cookie_valid(cookie) && PageFsCache(page))
return __fscache_maybe_release_page(cookie, page, gfp);
- return false;
+ return true;
}
/**
Fix the default for fscache_maybe_release_page() for when the cookie isn't
valid or the page isn't cached. It mustn't return false as that indicates
the page cannot yet be freed.
The problem with the default is that if, say, there's no cache, but a
network filesystem's pages are using up almost all the available memory, a
system can OOM because the filesystem ->releasepage() op will not allow
them to be released as fscache_maybe_release_page() incorrectly prevents
it.
This can be tested by writing a sequence of 512MiB files to an AFS mount.
It does not affect NFS or CIFS because both of those wrap the call in a
check of PG_fscache and it shouldn't bother Ceph as that only has
PG_private set whilst writeback is in progress. This might be an issue for
9P, however.
Note that the pages aren't entirely stuck. Removing a file or unmounting
will clear things because that uses ->invalidatepage() instead.
Fixes: 201a15428bd5 ("FS-Cache: Handle pages pending storage that get evicted under OOM conditions")
Reported-by: Marc Dionne <marc.dionne(a)auristor.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Reviewed-by: Jeff Layton <jlayton(a)redhat.com>
Acked-by: Al Viro <viro(a)zeniv.linux.org.uk>
cc: stable(a)vger.kernel.org # 2.6.32+
---
include/linux/fscache.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fscache.h b/include/linux/fscache.h
index f4ff47d4a893..fe0c349684fa 100644
--- a/include/linux/fscache.h
+++ b/include/linux/fscache.h
@@ -755,7 +755,7 @@ bool fscache_maybe_release_page(struct fscache_cookie *cookie,
{
if (fscache_cookie_valid(cookie) && PageFsCache(page))
return __fscache_maybe_release_page(cookie, page, gfp);
- return false;
+ return true;
}
/**
From: Paul Burton <paul.burton(a)imgtec.com>
The default CM target field in the GCR_BASE register is encoded with 0
meaning memory & 1 being reserved. However the definitions we use for
those bits effectively get these two values backwards - likely because
they were copied from the definitions for the CM regions where the
target is encoded differently. This results in use setting up GCR_BASE
with the reserved target value by default, rather than targeting memory
as intended. Although we currently seem to get away with this it's not a
great idea to rely upon.
Fix this by changing our macros to match the documentated target values.
The incorrect encoding became used as of commit 9f98f3dd0c51 ("MIPS: Add
generic CM probe & access code") in the Linux v3.15 cycle, and was
likely carried forwards from older but unused code introduced by commit
39b8d5254246 ("[MIPS] Add support for MIPS CMP platform.") in the
v2.6.26 cycle.
Signed-off-by: Paul Burton <paul.burton(a)imgtec.com>
Reported-by: Matt Redfearn <matt.redfearn(a)imgtec.com>
Cc: Matt Redfearn <matt.redfearn(a)imgtec.com>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: linux-mips(a)linux-mips.org
Cc: <stable(a)vger.kernel.org> # v3.15+
---
arch/mips/include/asm/mips-cm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/include/asm/mips-cm.h b/arch/mips/include/asm/mips-cm.h
index f6231b9..c6aaabd 100644
--- a/arch/mips/include/asm/mips-cm.h
+++ b/arch/mips/include/asm/mips-cm.h
@@ -142,8 +142,8 @@ static inline bool mips_cm_has_l2sync(void)
GCR_ACCESSOR_RW(64, 0x008, base)
#define CM_GCR_BASE_GCRBASE GENMASK_ULL(47, 15)
#define CM_GCR_BASE_CMDEFTGT GENMASK(1, 0)
-#define CM_GCR_BASE_CMDEFTGT_DISABLED 0
-#define CM_GCR_BASE_CMDEFTGT_MEM 1
+#define CM_GCR_BASE_CMDEFTGT_MEM 0
+#define CM_GCR_BASE_CMDEFTGT_RESERVED 1
#define CM_GCR_BASE_CMDEFTGT_IOCU0 2
#define CM_GCR_BASE_CMDEFTGT_IOCU1 3
--
1.9.1
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
On Mon, Dec 11, 2017 at 10:58:10PM +0100, Christian Hesse wrote:
> Greg KH <gregkh(a)linuxfoundation.org> on Tue, 2017/12/05 08:35:
> > On Tue, Dec 05, 2017 at 08:23:27AM +0100, Christian Hesse wrote:
> > > Greg KH <gregkh(a)linuxfoundation.org> on Mon, 2017/12/04 19:37:
> > > > On Mon, Dec 04, 2017 at 04:47:00PM +0100, Christian Hesse wrote:
> > > > > Amit Pundir <amit.pundir(a)linaro.org> on Mon, 2017/11/27 18:23:
> > > > > > Hi Greg,
> > > > > >
> > > > > > Found few e100e upstream fixes from Benjamin Poirier in lede
> > > > > > source tree, https://git.lede-project.org/?p=source.git, and
> > > > > > these fixes seem reasonable enough for 4.14.y too.
> > > > > >
> > > > > > Also submitting an e1000e buffer overrun fix by Sasha Neftin.
> > > > > >
> > > > > > Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.
> > > > > >
> > > > > > Regards,
> > > > > > Amit Pundir
> > > > > >
> > > > > >
> > > > > > Benjamin Poirier (4):
> > > > > > e1000e: Fix error path in link detection
> > > > > > e1000e: Fix return value test
> > > > > > e1000e: Separate signaling for link check/link up
> > > > > > e1000e: Avoid receiver overrun interrupt bursts
> > > > > >
> > > > > > Sasha Neftin (1):
> > > > > > e1000e: fix buffer overrun while the I219 is processing DMA
> > > > > > transactions
> > > > >
> > > > > Hello everybody,
> > > > >
> > > > > looks like one of these breaks connectivity on my Thinkpad X250.
> > > > > Just downgraded to linux 4.14.2 to verify.
> > > >
> > > > Can you try the -rc release I just did? It has a fix for this series in
> > > > it.
> > >
> > > It connects with the notebook's built in ethernet port (did not check with
> > > 4.14.3) but still fails to see a link when placed in docking station.
> >
> > Do you have the same issues with 4.15-rc2?
>
> Just a short heads-up and final result for this thread...
> The issue is fixed with Benjamin's patch:
>
> https://patchwork.kernel.org/patch/10104349/
Any word on getting this patch into Linus's tree anytime soon?
thanks,
greg k-h
Am Mittwoch, 11. Oktober 2017, 15:54:10 CET schrieb Arnd Bergmann:
> The map_word_() functions, dating back to linux-2.6.8, try to perform
> bitwise operations on a 'map_word' structure. This may have worked
> with compilers that were current then (gcc-3.4 or earlier), but end
> up being rather inefficient on any version I could try now (gcc-4.4 or
> higher). Specifically we hit a problem analyzed in gcc PR81715 where we
> fail to reuse the stack space for local variables.
>
> This can be seen immediately in the stack consumption for
> cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN)
> can be up to 2200 bytes. Changing the inline functions into macros brings
> this down to 1280 bytes. Without KASAN, the same problem exists, but
> the stack consumption is lower to start with, my patch shrinks it from
> 920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around
> 1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word
> structures for each call to one of these helpers.
>
> With the latest gcc-8 snapshot, the problem is fixed in upstream gcc,
> but nobody uses that yet, so we should still work around it in mainline
> kernels and probably backport the workaround to stable kernels as well.
> We had a couple of other functions that suffered from the same gcc bug,
> and all of those had a simpler workaround involving dummy variables
> in the inline function. Unfortunately that did not work here, the
> macro hack was the best I could come up with.
>
> It would also be helpful to have someone to a little performance testing
> on the patch, to see how much it helps in terms of CPU utilitzation.
>
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
> Cc: stable(a)vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Acked-by: Richard Weinberger <richard(a)nod.at>
Marek, I know you are not super happy with this patch but IMHO this is the
solution with the least hassle.
While functions offer better type checking I think this functions are trivial
enough to exist as macros too.
Also forcing users to upgrade/fix their compilers is only possible in a
perfect world.
Thanks,
//richard
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu(a)ti.com>
Date: Tue, 5 Dec 2017 08:45:30 -0600
Subject: [PATCH] usb: musb: da8xx: fix babble condition handling
When babble condition happens, the musb controller might automatically
turns off VBUS. On DA8xx platform, the controller generates drvvbus
interrupt for turning off VBUS along with the babble interrupt.
In this case, we should handle the babble interrupt first and recover
from the babble condition.
This change ignores the drvvbus interrupt if babble interrupt is also
generated at the same time, so the babble recovery routine works
properly.
Cc: stable(a)vger.kernel.org # v3.16+
Signed-off-by: Bin Liu <b-liu(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 0397606a211b..6c036de63272 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -284,7 +284,15 @@ static irqreturn_t da8xx_musb_interrupt(int irq, void *hci)
musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
portstate(musb->port1_status |= USB_PORT_STAT_POWER);
del_timer(&musb->dev_timer);
- } else {
+ } else if (!(musb->int_usb & MUSB_INTR_BABBLE)) {
+ /*
+ * When babble condition happens, drvvbus interrupt
+ * is also generated. Ignore this drvvbus interrupt
+ * and let babble interrupt handler recovers the
+ * controller; otherwise, the host-mode flag is lost
+ * due to the MUSB_DEV_MODE() call below and babble
+ * recovery logic will not be called.
+ */
musb->is_active = 0;
MUSB_DEV_MODE(musb);
otg->default_a = 0;
This is a note to let you know that I've just added the patch titled
usb: musb: da8xx: fix babble condition handling
to the 4.9-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:
usb-musb-da8xx-fix-babble-condition-handling.patch
and it can be found in the queue-4.9 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 bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu(a)ti.com>
Date: Tue, 5 Dec 2017 08:45:30 -0600
Subject: usb: musb: da8xx: fix babble condition handling
From: Bin Liu <b-liu(a)ti.com>
commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream.
When babble condition happens, the musb controller might automatically
turns off VBUS. On DA8xx platform, the controller generates drvvbus
interrupt for turning off VBUS along with the babble interrupt.
In this case, we should handle the babble interrupt first and recover
from the babble condition.
This change ignores the drvvbus interrupt if babble interrupt is also
generated at the same time, so the babble recovery routine works
properly.
Signed-off-by: Bin Liu <b-liu(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/musb/da8xx.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -302,7 +302,15 @@ static irqreturn_t da8xx_musb_interrupt(
musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
portstate(musb->port1_status |= USB_PORT_STAT_POWER);
del_timer(&otg_workaround);
- } else {
+ } else if (!(musb->int_usb & MUSB_INTR_BABBLE)){
+ /*
+ * When babble condition happens, drvvbus interrupt
+ * is also generated. Ignore this drvvbus interrupt
+ * and let babble interrupt handler recovers the
+ * controller; otherwise, the host-mode flag is lost
+ * due to the MUSB_DEV_MODE() call below and babble
+ * recovery logic will not called.
+ */
musb->is_active = 0;
MUSB_DEV_MODE(musb);
otg->default_a = 0;
Patches currently in stable-queue which might be from b-liu(a)ti.com are
queue-4.9/usb-musb-da8xx-fix-babble-condition-handling.patch
This is a note to let you know that I've just added the patch titled
usb: musb: da8xx: fix babble condition handling
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:
usb-musb-da8xx-fix-babble-condition-handling.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 bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu(a)ti.com>
Date: Tue, 5 Dec 2017 08:45:30 -0600
Subject: usb: musb: da8xx: fix babble condition handling
From: Bin Liu <b-liu(a)ti.com>
commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream.
When babble condition happens, the musb controller might automatically
turns off VBUS. On DA8xx platform, the controller generates drvvbus
interrupt for turning off VBUS along with the babble interrupt.
In this case, we should handle the babble interrupt first and recover
from the babble condition.
This change ignores the drvvbus interrupt if babble interrupt is also
generated at the same time, so the babble recovery routine works
properly.
Signed-off-by: Bin Liu <b-liu(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/musb/da8xx.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -350,7 +350,15 @@ static irqreturn_t da8xx_musb_interrupt(
musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
portstate(musb->port1_status |= USB_PORT_STAT_POWER);
del_timer(&otg_workaround);
- } else {
+ } else if (!(musb->int_usb & MUSB_INTR_BABBLE)){
+ /*
+ * When babble condition happens, drvvbus interrupt
+ * is also generated. Ignore this drvvbus interrupt
+ * and let babble interrupt handler recovers the
+ * controller; otherwise, the host-mode flag is lost
+ * due to the MUSB_DEV_MODE() call below and babble
+ * recovery logic will not called.
+ */
musb->is_active = 0;
MUSB_DEV_MODE(musb);
otg->default_a = 0;
Patches currently in stable-queue which might be from b-liu(a)ti.com are
queue-4.4/usb-musb-da8xx-fix-babble-condition-handling.patch
This is a note to let you know that I've just added the patch titled
usb: musb: da8xx: fix babble condition handling
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-musb-da8xx-fix-babble-condition-handling.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu(a)ti.com>
Date: Tue, 5 Dec 2017 08:45:30 -0600
Subject: usb: musb: da8xx: fix babble condition handling
From: Bin Liu <b-liu(a)ti.com>
commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream.
When babble condition happens, the musb controller might automatically
turns off VBUS. On DA8xx platform, the controller generates drvvbus
interrupt for turning off VBUS along with the babble interrupt.
In this case, we should handle the babble interrupt first and recover
from the babble condition.
This change ignores the drvvbus interrupt if babble interrupt is also
generated at the same time, so the babble recovery routine works
properly.
Signed-off-by: Bin Liu <b-liu(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/musb/da8xx.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -305,7 +305,15 @@ static irqreturn_t da8xx_musb_interrupt(
musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
portstate(musb->port1_status |= USB_PORT_STAT_POWER);
del_timer(&otg_workaround);
- } else {
+ } else if (!(musb->int_usb & MUSB_INTR_BABBLE)){
+ /*
+ * When babble condition happens, drvvbus interrupt
+ * is also generated. Ignore this drvvbus interrupt
+ * and let babble interrupt handler recovers the
+ * controller; otherwise, the host-mode flag is lost
+ * due to the MUSB_DEV_MODE() call below and babble
+ * recovery logic will not called.
+ */
musb->is_active = 0;
MUSB_DEV_MODE(musb);
otg->default_a = 0;
Patches currently in stable-queue which might be from b-liu(a)ti.com are
queue-4.14/usb-musb-da8xx-fix-babble-condition-handling.patch
This is a note to let you know that I've just added the patch titled
usb: musb: da8xx: fix babble condition handling
to the 3.18-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:
usb-musb-da8xx-fix-babble-condition-handling.patch
and it can be found in the queue-3.18 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 bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu(a)ti.com>
Date: Tue, 5 Dec 2017 08:45:30 -0600
Subject: usb: musb: da8xx: fix babble condition handling
From: Bin Liu <b-liu(a)ti.com>
commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream.
When babble condition happens, the musb controller might automatically
turns off VBUS. On DA8xx platform, the controller generates drvvbus
interrupt for turning off VBUS along with the babble interrupt.
In this case, we should handle the babble interrupt first and recover
from the babble condition.
This change ignores the drvvbus interrupt if babble interrupt is also
generated at the same time, so the babble recovery routine works
properly.
Signed-off-by: Bin Liu <b-liu(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/musb/da8xx.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -350,7 +350,15 @@ static irqreturn_t da8xx_musb_interrupt(
musb->xceiv->state = OTG_STATE_A_WAIT_VRISE;
portstate(musb->port1_status |= USB_PORT_STAT_POWER);
del_timer(&otg_workaround);
- } else {
+ } else if (!(musb->int_usb & MUSB_INTR_BABBLE)){
+ /*
+ * When babble condition happens, drvvbus interrupt
+ * is also generated. Ignore this drvvbus interrupt
+ * and let babble interrupt handler recovers the
+ * controller; otherwise, the host-mode flag is lost
+ * due to the MUSB_DEV_MODE() call below and babble
+ * recovery logic will not called.
+ */
musb->is_active = 0;
MUSB_DEV_MODE(musb);
otg->default_a = 0;
Patches currently in stable-queue which might be from b-liu(a)ti.com are
queue-3.18/usb-musb-da8xx-fix-babble-condition-handling.patch
This is a note to let you know that I've just added the patch titled
binder: fix proc->files use-after-free
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 7f3dc0088b98533f17128058fac73cd8b2752ef1 Mon Sep 17 00:00:00 2001
From: Todd Kjos <tkjos(a)android.com>
Date: Mon, 27 Nov 2017 09:32:33 -0800
Subject: binder: fix proc->files use-after-free
proc->files cleanup is initiated by binder_vma_close. Therefore
a reference on the binder_proc is not enough to prevent the
files_struct from being released while the binder_proc still has
a reference. This can lead to an attempt to dereference the
stale pointer obtained from proc->files prior to proc->files
cleanup. This has been seen once in task_get_unused_fd_flags()
when __alloc_fd() is called with a stale "files".
The fix is to protect proc->files with a mutex to prevent cleanup
while in use.
Signed-off-by: Todd Kjos <tkjos(a)google.com>
Cc: stable <stable(a)vger.kernel.org> # 4.14
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/android/binder.c | 44 +++++++++++++++++++++++++++++++-------------
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index bccec9de0533..a7ecfde66b7b 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -482,7 +482,8 @@ enum binder_deferred_state {
* @tsk task_struct for group_leader of process
* (invariant after initialized)
* @files files_struct for process
- * (invariant after initialized)
+ * (protected by @files_lock)
+ * @files_lock mutex to protect @files
* @deferred_work_node: element for binder_deferred_list
* (protected by binder_deferred_lock)
* @deferred_work: bitmap of deferred work to perform
@@ -530,6 +531,7 @@ struct binder_proc {
int pid;
struct task_struct *tsk;
struct files_struct *files;
+ struct mutex files_lock;
struct hlist_node deferred_work_node;
int deferred_work;
bool is_dead;
@@ -877,20 +879,26 @@ static void binder_inc_node_tmpref_ilocked(struct binder_node *node);
static int task_get_unused_fd_flags(struct binder_proc *proc, int flags)
{
- struct files_struct *files = proc->files;
unsigned long rlim_cur;
unsigned long irqs;
+ int ret;
- if (files == NULL)
- return -ESRCH;
-
- if (!lock_task_sighand(proc->tsk, &irqs))
- return -EMFILE;
-
+ mutex_lock(&proc->files_lock);
+ if (proc->files == NULL) {
+ ret = -ESRCH;
+ goto err;
+ }
+ if (!lock_task_sighand(proc->tsk, &irqs)) {
+ ret = -EMFILE;
+ goto err;
+ }
rlim_cur = task_rlimit(proc->tsk, RLIMIT_NOFILE);
unlock_task_sighand(proc->tsk, &irqs);
- return __alloc_fd(files, 0, rlim_cur, flags);
+ ret = __alloc_fd(proc->files, 0, rlim_cur, flags);
+err:
+ mutex_unlock(&proc->files_lock);
+ return ret;
}
/*
@@ -899,8 +907,10 @@ static int task_get_unused_fd_flags(struct binder_proc *proc, int flags)
static void task_fd_install(
struct binder_proc *proc, unsigned int fd, struct file *file)
{
+ mutex_lock(&proc->files_lock);
if (proc->files)
__fd_install(proc->files, fd, file);
+ mutex_unlock(&proc->files_lock);
}
/*
@@ -910,9 +920,11 @@ static long task_close_fd(struct binder_proc *proc, unsigned int fd)
{
int retval;
- if (proc->files == NULL)
- return -ESRCH;
-
+ mutex_lock(&proc->files_lock);
+ if (proc->files == NULL) {
+ retval = -ESRCH;
+ goto err;
+ }
retval = __close_fd(proc->files, fd);
/* can't restart close syscall because file table entry was cleared */
if (unlikely(retval == -ERESTARTSYS ||
@@ -920,7 +932,8 @@ static long task_close_fd(struct binder_proc *proc, unsigned int fd)
retval == -ERESTARTNOHAND ||
retval == -ERESTART_RESTARTBLOCK))
retval = -EINTR;
-
+err:
+ mutex_unlock(&proc->files_lock);
return retval;
}
@@ -4627,7 +4640,9 @@ static int binder_mmap(struct file *filp, struct vm_area_struct *vma)
ret = binder_alloc_mmap_handler(&proc->alloc, vma);
if (ret)
return ret;
+ mutex_lock(&proc->files_lock);
proc->files = get_files_struct(current);
+ mutex_unlock(&proc->files_lock);
return 0;
err_bad_arg:
@@ -4651,6 +4666,7 @@ static int binder_open(struct inode *nodp, struct file *filp)
spin_lock_init(&proc->outer_lock);
get_task_struct(current->group_leader);
proc->tsk = current->group_leader;
+ mutex_init(&proc->files_lock);
INIT_LIST_HEAD(&proc->todo);
proc->default_priority = task_nice(current);
binder_dev = container_of(filp->private_data, struct binder_device,
@@ -4903,9 +4919,11 @@ static void binder_deferred_func(struct work_struct *work)
files = NULL;
if (defer & BINDER_DEFERRED_PUT_FILES) {
+ mutex_lock(&proc->files_lock);
files = proc->files;
if (files)
proc->files = NULL;
+ mutex_unlock(&proc->files_lock);
}
if (defer & BINDER_DEFERRED_FLUSH)
--
2.15.1
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu(a)ti.com>
Date: Tue, 5 Dec 2017 08:45:30 -0600
Subject: [PATCH] usb: musb: da8xx: fix babble condition handling
When babble condition happens, the musb controller might automatically
turns off VBUS. On DA8xx platform, the controller generates drvvbus
interrupt for turning off VBUS along with the babble interrupt.
In this case, we should handle the babble interrupt first and recover
from the babble condition.
This change ignores the drvvbus interrupt if babble interrupt is also
generated at the same time, so the babble recovery routine works
properly.
Cc: stable(a)vger.kernel.org # v3.16+
Signed-off-by: Bin Liu <b-liu(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 0397606a211b..6c036de63272 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -284,7 +284,15 @@ static irqreturn_t da8xx_musb_interrupt(int irq, void *hci)
musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
portstate(musb->port1_status |= USB_PORT_STAT_POWER);
del_timer(&musb->dev_timer);
- } else {
+ } else if (!(musb->int_usb & MUSB_INTR_BABBLE)) {
+ /*
+ * When babble condition happens, drvvbus interrupt
+ * is also generated. Ignore this drvvbus interrupt
+ * and let babble interrupt handler recovers the
+ * controller; otherwise, the host-mode flag is lost
+ * due to the MUSB_DEV_MODE() call below and babble
+ * recovery logic will not be called.
+ */
musb->is_active = 0;
MUSB_DEV_MODE(musb);
otg->default_a = 0;
This is a note to let you know that I've just added the patch titled
xfs: fix log block underflow during recovery cycle verification
to the 3.18-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:
xfs-fix-log-block-underflow-during-recovery-cycle-verification.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Brian Foster <bfoster(a)redhat.com>
Date: Thu, 26 Oct 2017 09:31:16 -0700
Subject: xfs: fix log block underflow during recovery cycle verification
From: Brian Foster <bfoster(a)redhat.com>
[ Upstream commit 9f2a4505800607e537e9dd9dea4f55c4b0c30c7a ]
It is possible for mkfs to format very small filesystems with too
small of an internal log with respect to the various minimum size
and block count requirements. If this occurs when the log happens to
be smaller than the scan window used for cycle verification and the
scan wraps the end of the log, the start_blk calculation in
xlog_find_head() underflows and leads to an attempt to scan an
invalid range of log blocks. This results in log recovery failure
and a failed mount.
Since there may be filesystems out in the wild with this kind of
geometry, we cannot simply refuse to mount. Instead, cap the scan
window for cycle verification to the size of the physical log. This
ensures that the cycle verification proceeds as expected when the
scan wraps the end of the log.
Reported-by: Zorro Lang <zlang(a)redhat.com>
Signed-off-by: Brian Foster <bfoster(a)redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/xfs/xfs_log_recover.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/xfs/xfs_log_recover.c
+++ b/fs/xfs/xfs_log_recover.c
@@ -740,7 +740,7 @@ xlog_find_head(
* in the in-core log. The following number can be made tighter if
* we actually look at the block size of the filesystem.
*/
- num_scan_bblks = XLOG_TOTAL_REC_SHIFT(log);
+ num_scan_bblks = min_t(int, log_bbnum, XLOG_TOTAL_REC_SHIFT(log));
if (head_blk >= num_scan_bblks) {
/*
* We are guaranteed that the entire check can be performed
Patches currently in stable-queue which might be from bfoster(a)redhat.com are
queue-3.18/xfs-fix-log-block-underflow-during-recovery-cycle-verification.patch
This is a note to let you know that I've just added the patch titled
video: udlfb: Fix read EDID timeout
to the 3.18-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:
video-udlfb-fix-read-edid-timeout.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Ladislav Michl <ladis(a)linux-mips.org>
Date: Thu, 9 Nov 2017 18:09:30 +0100
Subject: video: udlfb: Fix read EDID timeout
From: Ladislav Michl <ladis(a)linux-mips.org>
[ Upstream commit c98769475575c8a585f5b3952f4b5f90266f699b ]
While usb_control_msg function expects timeout in miliseconds, a value
of HZ is used. Replace it with USB_CTRL_GET_TIMEOUT and also fix error
message which looks like:
udlfb: Read EDID byte 78 failed err ffffff92
as error is either negative errno or number of bytes transferred use %d
format specifier.
Returned EDID is in second byte, so return error when less than two bytes
are received.
Fixes: 18dffdf8913a ("staging: udlfb: enhance EDID and mode handling support")
Signed-off-by: Ladislav Michl <ladis(a)linux-mips.org>
Cc: Bernie Thompson <bernie(a)plugable.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/udlfb.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -769,11 +769,11 @@ static int dlfb_get_edid(struct dlfb_dat
for (i = 0; i < len; i++) {
ret = usb_control_msg(dev->udev,
- usb_rcvctrlpipe(dev->udev, 0), (0x02),
- (0x80 | (0x02 << 5)), i << 8, 0xA1, rbuf, 2,
- HZ);
- if (ret < 1) {
- pr_err("Read EDID byte %d failed err %x\n", i, ret);
+ usb_rcvctrlpipe(dev->udev, 0), 0x02,
+ (0x80 | (0x02 << 5)), i << 8, 0xA1,
+ rbuf, 2, USB_CTRL_GET_TIMEOUT);
+ if (ret < 2) {
+ pr_err("Read EDID byte %d failed: %d\n", i, ret);
i--;
break;
}
Patches currently in stable-queue which might be from ladis(a)linux-mips.org are
queue-3.18/video-udlfb-fix-read-edid-timeout.patch
This is a note to let you know that I've just added the patch titled
video: fbdev: au1200fb: Return an error code if a memory allocation fails
to the 3.18-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:
video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Thu, 9 Nov 2017 18:09:28 +0100
Subject: video: fbdev: au1200fb: Return an error code if a memory allocation fails
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 8cae353e6b01ac3f18097f631cdbceb5ff28c7f3 ]
'ret' is known to be 0 at this point.
In case of memory allocation error in 'framebuffer_alloc()', return
-ENOMEM instead.
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Cc: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/au1200fb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/video/fbdev/au1200fb.c
+++ b/drivers/video/fbdev/au1200fb.c
@@ -1680,8 +1680,10 @@ static int au1200fb_drv_probe(struct pla
fbi = framebuffer_alloc(sizeof(struct au1200fb_device),
&dev->dev);
- if (!fbi)
+ if (!fbi) {
+ ret = -ENOMEM;
goto failed;
+ }
_au1200fb_infos[plane] = fbi;
fbdev = fbi->par;
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-3.18/video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch
queue-3.18/video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch
This is a note to let you know that I've just added the patch titled
video: fbdev: au1200fb: Release some resources if a memory allocation fails
to the 3.18-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:
video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Thu, 9 Nov 2017 18:09:28 +0100
Subject: video: fbdev: au1200fb: Release some resources if a memory allocation fails
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 451f130602619a17c8883dd0b71b11624faffd51 ]
We should go through the error handling code instead of returning -ENOMEM
directly.
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Cc: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/au1200fb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/video/fbdev/au1200fb.c
+++ b/drivers/video/fbdev/au1200fb.c
@@ -1699,7 +1699,8 @@ static int au1200fb_drv_probe(struct pla
if (!fbdev->fb_mem) {
print_err("fail to allocate frambuffer (size: %dK))",
fbdev->fb_len / 1024);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto failed;
}
/*
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-3.18/video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch
queue-3.18/video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch
This is a note to let you know that I've just added the patch titled
usb: phy: isp1301: Add OF device ID table
to the 3.18-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:
usb-phy-isp1301-add-of-device-id-table.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Javier Martinez Canillas <javier(a)osg.samsung.com>
Date: Wed, 22 Feb 2017 15:23:22 -0300
Subject: usb: phy: isp1301: Add OF device ID table
From: Javier Martinez Canillas <javier(a)osg.samsung.com>
[ Upstream commit fd567653bdb908009b650f079bfd4b63169e2ac4 ]
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: Javier Martinez Canillas <javier(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/phy/phy-isp1301.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/usb/phy/phy-isp1301.c
+++ b/drivers/usb/phy/phy-isp1301.c
@@ -32,6 +32,12 @@ static const struct i2c_device_id isp130
{ }
};
+static const struct of_device_id isp1301_of_match[] = {
+ {.compatible = "nxp,isp1301" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, isp1301_of_match);
+
static struct i2c_client *isp1301_i2c_client;
static int __isp1301_write(struct isp1301 *isp, u8 reg, u8 value, u8 clear)
@@ -129,6 +135,7 @@ static int isp1301_remove(struct i2c_cli
static struct i2c_driver isp1301_driver = {
.driver = {
.name = DRV_NAME,
+ .of_match_table = of_match_ptr(isp1301_of_match),
},
.probe = isp1301_probe,
.remove = isp1301_remove,
Patches currently in stable-queue which might be from javier(a)osg.samsung.com are
queue-3.18/usb-phy-isp1301-add-of-device-id-table.patch
This is a note to let you know that I've just added the patch titled
udf: Avoid overflow when session starts at large offset
to the 3.18-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:
udf-avoid-overflow-when-session-starts-at-large-offset.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Jan Kara <jack(a)suse.cz>
Date: Mon, 16 Oct 2017 11:38:11 +0200
Subject: udf: Avoid overflow when session starts at large offset
From: Jan Kara <jack(a)suse.cz>
[ Upstream commit abdc0eb06964fe1d2fea6dd1391b734d0590365d ]
When session starts beyond offset 2^31 the arithmetics in
udf_check_vsd() would overflow. Make sure the computation is done in
large enough type.
Reported-by: Cezary Sliwa <sliwa(a)ifpan.edu.pl>
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/udf/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -706,7 +706,7 @@ static loff_t udf_check_vsd(struct super
else
sectorsize = sb->s_blocksize;
- sector += (sbi->s_session << sb->s_blocksize_bits);
+ sector += (((loff_t)sbi->s_session) << sb->s_blocksize_bits);
udf_debug("Starting at sector %u (%ld byte sectors)\n",
(unsigned int)(sector >> sb->s_blocksize_bits),
Patches currently in stable-queue which might be from jack(a)suse.cz are
queue-3.18/mm-handle-0-flags-in-_calc_vm_trans-macro.patch
queue-3.18/udf-avoid-overflow-when-session-starts-at-large-offset.patch
This is a note to let you know that I've just added the patch titled
thermal/drivers/step_wise: Fix temperature regulation misbehavior
to the 3.18-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:
thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Date: Thu, 19 Oct 2017 19:05:58 +0200
Subject: thermal/drivers/step_wise: Fix temperature regulation misbehavior
From: Daniel Lezcano <daniel.lezcano(a)linaro.org>
[ Upstream commit 07209fcf33542c1ff1e29df2dbdf8f29cdaacb10 ]
There is a particular situation when the cooling device is cpufreq and the heat
dissipation is not efficient enough where the temperature increases little by
little until reaching the critical threshold and leading to a SoC reset.
The behavior is reproducible on a hikey6220 with bad heat dissipation (eg.
stacked with other boards).
Running a simple C program doing while(1); for each CPU of the SoC makes the
temperature to reach the passive regulation trip point and ends up to the
maximum allowed temperature followed by a reset.
This issue has been also reported by running the libhugetlbfs test suite.
What is observed is a ping pong between two cpu frequencies, 1.2GHz and 900MHz
while the temperature continues to grow.
It appears the step wise governor calls get_target_state() the first time with
the throttle set to true and the trend to 'raising'. The code selects logically
the next state, so the cpu frequency decreases from 1.2GHz to 900MHz, so far so
good. The temperature decreases immediately but still stays greater than the
trip point, then get_target_state() is called again, this time with the
throttle set to true *and* the trend to 'dropping'. From there the algorithm
assumes we have to step down the state and the cpu frequency jumps back to
1.2GHz. But the temperature is still higher than the trip point, so
get_target_state() is called with throttle=1 and trend='raising' again, we jump
to 900MHz, then get_target_state() is called with throttle=1 and
trend='dropping', we jump to 1.2GHz, etc ... but the temperature does not
stabilizes and continues to increase.
[ 237.922654] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
[ 237.922678] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
[ 237.922690] thermal cooling_device0: cur_state=0
[ 237.922701] thermal cooling_device0: old_target=0, target=1
[ 238.026656] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
[ 238.026680] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1
[ 238.026694] thermal cooling_device0: cur_state=1
[ 238.026707] thermal cooling_device0: old_target=1, target=0
[ 238.134647] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
[ 238.134667] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
[ 238.134679] thermal cooling_device0: cur_state=0
[ 238.134690] thermal cooling_device0: old_target=0, target=1
In this situation the temperature continues to increase while the trend is
oscillating between 'dropping' and 'raising'. We need to keep the current state
untouched if the throttle is set, so the temperature can decrease or a higher
state could be selected, thus preventing this oscillation.
Keeping the next_target untouched when 'throttle' is true at 'dropping' time
fixes the issue.
The following traces show the governor does not change the next state if
trend==2 (dropping) and throttle==1.
[ 2306.127987] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
[ 2306.128009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
[ 2306.128021] thermal cooling_device0: cur_state=0
[ 2306.128031] thermal cooling_device0: old_target=0, target=1
[ 2306.231991] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
[ 2306.232016] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1
[ 2306.232030] thermal cooling_device0: cur_state=1
[ 2306.232042] thermal cooling_device0: old_target=1, target=1
[ 2306.335982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1
[ 2306.336006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=1
[ 2306.336021] thermal cooling_device0: cur_state=1
[ 2306.336034] thermal cooling_device0: old_target=1, target=1
[ 2306.439984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
[ 2306.440008] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0
[ 2306.440022] thermal cooling_device0: cur_state=1
[ 2306.440034] thermal cooling_device0: old_target=1, target=0
[ ... ]
After a while, if the temperature continues to increase, the next state becomes
2 which is 720MHz on the hikey. That results in the temperature stabilizing
around the trip point.
[ 2455.831982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
[ 2455.832006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=0
[ 2455.832019] thermal cooling_device0: cur_state=1
[ 2455.832032] thermal cooling_device0: old_target=1, target=1
[ 2455.935985] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1
[ 2455.936013] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0
[ 2455.936027] thermal cooling_device0: cur_state=1
[ 2455.936040] thermal cooling_device0: old_target=1, target=1
[ 2456.043984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1
[ 2456.044009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0
[ 2456.044023] thermal cooling_device0: cur_state=1
[ 2456.044036] thermal cooling_device0: old_target=1, target=1
[ 2456.148001] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
[ 2456.148028] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
[ 2456.148042] thermal cooling_device0: cur_state=1
[ 2456.148055] thermal cooling_device0: old_target=1, target=2
[ 2456.252009] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
[ 2456.252041] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0
[ 2456.252058] thermal cooling_device0: cur_state=2
[ 2456.252075] thermal cooling_device0: old_target=2, target=1
IOW, this change is needed to keep the state for a cooling device if the
temperature trend is oscillating while the temperature increases slightly.
Without this change, the situation above leads to a catastrophic crash by a
hardware reset on hikey. This issue has been reported to happen on an OMAP
dra7xx also.
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Cc: Keerthy <j-keerthy(a)ti.com>
Cc: John Stultz <john.stultz(a)linaro.org>
Cc: Leo Yan <leo.yan(a)linaro.org>
Tested-by: Keerthy <j-keerthy(a)ti.com>
Reviewed-by: Keerthy <j-keerthy(a)ti.com>
Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/thermal/step_wise.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -31,8 +31,7 @@
* If the temperature is higher than a trip point,
* a. if the trend is THERMAL_TREND_RAISING, use higher cooling
* state for this trip point
- * b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
- * state for this trip point
+ * b. if the trend is THERMAL_TREND_DROPPING, do nothing
* c. if the trend is THERMAL_TREND_RAISE_FULL, use upper limit
* for this trip point
* d. if the trend is THERMAL_TREND_DROP_FULL, use lower limit
@@ -94,9 +93,11 @@ static unsigned long get_target_state(st
if (!throttle)
next_target = THERMAL_NO_TARGET;
} else {
- next_target = cur_state - 1;
- if (next_target > instance->upper)
- next_target = instance->upper;
+ if (!throttle) {
+ next_target = cur_state - 1;
+ if (next_target > instance->upper)
+ next_target = instance->upper;
+ }
}
break;
case THERMAL_TREND_DROP_FULL:
Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are
queue-3.18/thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.patch
This is a note to let you know that I've just added the patch titled
target: Use system workqueue for ALUA transitions
to the 3.18-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:
target-use-system-workqueue-for-alua-transitions.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Mike Christie <mchristi(a)redhat.com>
Date: Wed, 1 Mar 2017 23:13:26 -0600
Subject: target: Use system workqueue for ALUA transitions
From: Mike Christie <mchristi(a)redhat.com>
[ Upstream commit 207ee84133c00a8a2a5bdec94df4a5b37d78881c ]
If tcmu-runner is processing a STPG and needs to change the kernel's
ALUA state then we cannot use the same work queue for task management
requests and ALUA transitions, because we could deadlock. The problem
occurs when a STPG times out before tcmu-runner is able to
call into target_tg_pt_gp_alua_access_state_store->
core_alua_do_port_transition -> core_alua_do_transition_tg_pt ->
queue_work. In this case, the tmr is on the work queue waiting for
the STPG to complete, but the STPG transition is now queued behind
the waiting tmr.
Note:
This bug will also be fixed by this patch:
http://www.spinics.net/lists/target-devel/msg14560.html
which switches the tmr code to use the system workqueues.
For both, I am not sure if we need a dedicated workqueue since
it is not a performance path and I do not think we need WQ_MEM_RECLAIM
to make forward progress to free up memory like the block layer does.
Signed-off-by: Mike Christie <mchristi(a)redhat.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/target_core_alua.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/target/target_core_alua.c
+++ b/drivers/target/target_core_alua.c
@@ -1126,13 +1126,11 @@ static int core_alua_do_transition_tg_pt
unsigned long transition_tmo;
transition_tmo = tg_pt_gp->tg_pt_gp_implicit_trans_secs * HZ;
- queue_delayed_work(tg_pt_gp->tg_pt_gp_dev->tmr_wq,
- &tg_pt_gp->tg_pt_gp_transition_work,
- transition_tmo);
+ schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work,
+ transition_tmo);
} else {
tg_pt_gp->tg_pt_gp_transition_complete = &wait;
- queue_delayed_work(tg_pt_gp->tg_pt_gp_dev->tmr_wq,
- &tg_pt_gp->tg_pt_gp_transition_work, 0);
+ schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work, 0);
wait_for_completion(&wait);
tg_pt_gp->tg_pt_gp_transition_complete = NULL;
}
Patches currently in stable-queue which might be from mchristi(a)redhat.com are
queue-3.18/target-use-system-workqueue-for-alua-transitions.patch
queue-3.18/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch
This is a note to let you know that I've just added the patch titled
target:fix condition return in core_pr_dump_initiator_port()
to the 3.18-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:
target-fix-condition-return-in-core_pr_dump_initiator_port.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: tangwenji <tang.wenji(a)zte.com.cn>
Date: Thu, 24 Aug 2017 19:59:37 +0800
Subject: target:fix condition return in core_pr_dump_initiator_port()
From: tangwenji <tang.wenji(a)zte.com.cn>
[ Upstream commit 24528f089d0a444070aa4f715ace537e8d6bf168 ]
When is pr_reg->isid_present_at_reg is false,this function should return.
This fixes a regression originally introduced by:
commit d2843c173ee53cf4c12e7dfedc069a5bc76f0ac5
Author: Andy Grover <agrover(a)redhat.com>
Date: Thu May 16 10:40:55 2013 -0700
target: Alter core_pr_dump_initiator_port for ease of use
Signed-off-by: tangwenji <tang.wenji(a)zte.com.cn>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/target_core_pr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/target/target_core_pr.c
+++ b/drivers/target/target_core_pr.c
@@ -58,8 +58,10 @@ void core_pr_dump_initiator_port(
char *buf,
u32 size)
{
- if (!pr_reg->isid_present_at_reg)
+ if (!pr_reg->isid_present_at_reg) {
buf[0] = '\0';
+ return;
+ }
snprintf(buf, size, ",i,0x%s", pr_reg->pr_reg_isid);
}
Patches currently in stable-queue which might be from tang.wenji(a)zte.com.cn are
queue-3.18/target-fix-condition-return-in-core_pr_dump_initiator_port.patch
queue-3.18/iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch
This is a note to let you know that I've just added the patch titled
target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd()
to the 3.18-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:
target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Tue, 31 Oct 2017 11:03:17 -0700
Subject: target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd()
From: Bart Van Assche <bart.vanassche(a)wdc.com>
[ Upstream commit cfe2b621bb18d86e93271febf8c6e37622da2d14 ]
Avoid that cmd->se_cmd.se_tfo is read after a command has already been
freed.
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Mike Christie <mchristi(a)redhat.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/iscsi/iscsi_target.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -674,6 +674,7 @@ static int iscsit_add_reject_from_cmd(
unsigned char *buf)
{
struct iscsi_conn *conn;
+ const bool do_put = cmd->se_cmd.se_tfo != NULL;
if (!cmd->conn) {
pr_err("cmd->conn is NULL for ITT: 0x%08x\n",
@@ -704,7 +705,7 @@ static int iscsit_add_reject_from_cmd(
* Perform the kref_put now if se_cmd has already been setup by
* scsit_setup_scsi_cmd()
*/
- if (cmd->se_cmd.se_tfo != NULL) {
+ if (do_put) {
pr_debug("iscsi reject: calling target_put_sess_cmd >>>>>>\n");
target_put_sess_cmd(&cmd->se_cmd);
}
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-3.18/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch
This is a note to let you know that I've just added the patch titled
target/file: Do not return error for UNMAP if length is zero
to the 3.18-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:
target-file-do-not-return-error-for-unmap-if-length-is-zero.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Jiang Yi <jiangyilism(a)gmail.com>
Date: Fri, 11 Aug 2017 11:29:44 +0800
Subject: target/file: Do not return error for UNMAP if length is zero
From: Jiang Yi <jiangyilism(a)gmail.com>
[ Upstream commit 594e25e73440863981032d76c9b1e33409ceff6e ]
The function fd_execute_unmap() in target_core_file.c calles
ret = file->f_op->fallocate(file, mode, pos, len);
Some filesystems implement fallocate() to return error if
length is zero (e.g. btrfs) but according to SCSI Block
Commands spec UNMAP should return success for zero length.
Signed-off-by: Jiang Yi <jiangyilism(a)gmail.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/target_core_file.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -592,6 +592,10 @@ fd_do_unmap(struct se_cmd *cmd, void *pr
struct inode *inode = file->f_mapping->host;
int ret;
+ if (!nolb) {
+ return 0;
+ }
+
if (cmd->se_dev->dev_attrib.pi_prot_type) {
ret = fd_do_prot_unmap(cmd, lba, nolb);
if (ret)
Patches currently in stable-queue which might be from jiangyilism(a)gmail.com are
queue-3.18/target-file-do-not-return-error-for-unmap-if-length-is-zero.patch
This is a note to let you know that I've just added the patch titled
scsi: bfa: integer overflow in debugfs
to the 3.18-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:
scsi-bfa-integer-overflow-in-debugfs.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Wed, 4 Oct 2017 10:50:37 +0300
Subject: scsi: bfa: integer overflow in debugfs
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 3e351275655d3c84dc28abf170def9786db5176d ]
We could allocate less memory than intended because we do:
bfad->regdata = kzalloc(len << 2, GFP_KERNEL);
The shift can overflow leading to a crash. This is debugfs code so the
impact is very small. I fixed the network version of this in March with
commit 13e2d5187f6b ("bna: integer overflow bug in debugfs").
Fixes: ab2a9ba189e8 ("[SCSI] bfa: add debugfs support")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/bfa/bfad_debugfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/scsi/bfa/bfad_debugfs.c
+++ b/drivers/scsi/bfa/bfad_debugfs.c
@@ -254,7 +254,8 @@ bfad_debugfs_write_regrd(struct file *fi
struct bfad_s *bfad = port->bfad;
struct bfa_s *bfa = &bfad->bfa;
struct bfa_ioc_s *ioc = &bfa->ioc;
- int addr, len, rc, i;
+ int addr, rc, i;
+ u32 len;
u32 *regbuf;
void __iomem *rb, *reg_addr;
unsigned long flags;
@@ -274,7 +275,7 @@ bfad_debugfs_write_regrd(struct file *fi
}
rc = sscanf(kern_buf, "%x:%x", &addr, &len);
- if (rc < 2) {
+ if (rc < 2 || len > (UINT_MAX >> 2)) {
printk(KERN_INFO
"bfad[%d]: %s failed to read user buf\n",
bfad->inst_no, __func__);
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-3.18/scsi-bfa-integer-overflow-in-debugfs.patch
queue-3.18/fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch
This is a note to let you know that I've just added the patch titled
scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry
to the 3.18-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:
scsi-scsi_devinfo-add-reportlun2-to-emc-symmetrix-blacklist-entry.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Kurt Garloff <garloff(a)suse.de>
Date: Tue, 17 Oct 2017 09:10:45 +0200
Subject: scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry
From: Kurt Garloff <garloff(a)suse.de>
[ Upstream commit 909cf3e16a5274fe2127cf3cea5c8dba77b2c412 ]
All EMC SYMMETRIX support REPORT_LUNS, even if configured to report
SCSI-2 for whatever reason.
Signed-off-by: Kurt Garloff <garloff(a)suse.de>
Signed-off-by: Hannes Reinecke <hare(a)suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/scsi_devinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -160,7 +160,7 @@ static struct {
{"DGC", "RAID", NULL, BLIST_SPARSELUN}, /* Dell PV 650F, storage on LUN 0 */
{"DGC", "DISK", NULL, BLIST_SPARSELUN}, /* Dell PV 650F, no storage on LUN 0 */
{"EMC", "Invista", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
- {"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_FORCELUN},
+ {"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_REPORTLUN2},
{"EMULEX", "MD21/S2 ESDI", NULL, BLIST_SINGLELUN},
{"easyRAID", "16P", NULL, BLIST_NOREPORTLUN},
{"easyRAID", "X6P", NULL, BLIST_NOREPORTLUN},
Patches currently in stable-queue which might be from garloff(a)suse.de are
queue-3.18/scsi-scsi_devinfo-add-reportlun2-to-emc-symmetrix-blacklist-entry.patch
This is a note to let you know that I've just added the patch titled
sched/deadline: Use deadline instead of period when calculating overflow
to the 3.18-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:
sched-deadline-use-deadline-instead-of-period-when-calculating-overflow.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
Date: Thu, 2 Mar 2017 15:10:59 +0100
Subject: sched/deadline: Use deadline instead of period when calculating overflow
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
[ Upstream commit 2317d5f1c34913bac5971d93d69fb6c31bb74670 ]
I was testing Daniel's changes with his test case, and tweaked it a
little. Instead of having the runtime equal to the deadline, I
increased the deadline ten fold.
Daniel's test case had:
attr.sched_runtime = 2 * 1000 * 1000; /* 2 ms */
attr.sched_deadline = 2 * 1000 * 1000; /* 2 ms */
attr.sched_period = 2 * 1000 * 1000 * 1000; /* 2 s */
To make it more interesting, I changed it to:
attr.sched_runtime = 2 * 1000 * 1000; /* 2 ms */
attr.sched_deadline = 20 * 1000 * 1000; /* 20 ms */
attr.sched_period = 2 * 1000 * 1000 * 1000; /* 2 s */
The results were rather surprising. The behavior that Daniel's patch
was fixing came back. The task started using much more than .1% of the
CPU. More like 20%.
Looking into this I found that it was due to the dl_entity_overflow()
constantly returning true. That's because it uses the relative period
against relative runtime vs the absolute deadline against absolute
runtime.
runtime / (deadline - t) > dl_runtime / dl_period
There's even a comment mentioning this, and saying that when relative
deadline equals relative period, that the equation is the same as using
deadline instead of period. That comment is backwards! What we really
want is:
runtime / (deadline - t) > dl_runtime / dl_deadline
We care about if the runtime can make its deadline, not its period. And
then we can say "when the deadline equals the period, the equation is
the same as using dl_period instead of dl_deadline".
After correcting this, now when the task gets enqueued, it can throttle
correctly, and Daniel's fix to the throttling of sleeping deadline
tasks works even when the runtime and deadline are not the same.
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Reviewed-by: Daniel Bristot de Oliveira <bristot(a)redhat.com>
Cc: Juri Lelli <juri.lelli(a)arm.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Luca Abeni <luca.abeni(a)santannapisa.it>
Cc: Mike Galbraith <efault(a)gmx.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Romulo Silva de Oliveira <romulo.deoliveira(a)ufsc.br>
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Tommaso Cucinotta <tommaso.cucinotta(a)sssup.it>
Link: http://lkml.kernel.org/r/02135a27f1ae3fe5fd032568a5a2f370e190e8d7.148839293…
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/sched/deadline.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -368,13 +368,13 @@ static void replenish_dl_entity(struct s
*
* This function returns true if:
*
- * runtime / (deadline - t) > dl_runtime / dl_period ,
+ * runtime / (deadline - t) > dl_runtime / dl_deadline ,
*
* IOW we can't recycle current parameters.
*
- * Notice that the bandwidth check is done against the period. For
+ * Notice that the bandwidth check is done against the deadline. For
* task with deadline equal to period this is the same of using
- * dl_deadline instead of dl_period in the equation above.
+ * dl_period instead of dl_deadline in the equation above.
*/
static bool dl_entity_overflow(struct sched_dl_entity *dl_se,
struct sched_dl_entity *pi_se, u64 t)
@@ -399,7 +399,7 @@ static bool dl_entity_overflow(struct sc
* of anything below microseconds resolution is actually fiction
* (but still we want to give the user that illusion >;).
*/
- left = (pi_se->dl_period >> DL_SCALE) * (dl_se->runtime >> DL_SCALE);
+ left = (pi_se->dl_deadline >> DL_SCALE) * (dl_se->runtime >> DL_SCALE);
right = ((dl_se->deadline - t) >> DL_SCALE) *
(pi_se->dl_runtime >> DL_SCALE);
Patches currently in stable-queue which might be from rostedt(a)goodmis.org are
queue-3.18/sched-deadline-use-deadline-instead-of-period-when-calculating-overflow.patch
This is a note to let you know that I've just added the patch titled
raid5: Set R5_Expanded on parity devices as well as data.
to the 3.18-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:
raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: NeilBrown <neilb(a)suse.com>
Date: Tue, 17 Oct 2017 16:18:36 +1100
Subject: raid5: Set R5_Expanded on parity devices as well as data.
From: NeilBrown <neilb(a)suse.com>
[ Upstream commit 235b6003fb28f0dd8e7ed8fbdb088bb548291766 ]
When reshaping a fully degraded raid5/raid6 to a larger
nubmer of devices, the new device(s) are not in-sync
and so that can make the newly grown stripe appear to be
"failed".
To avoid this, we set the R5_Expanded flag to say "Even though
this device is not fully in-sync, this block is safe so
don't treat the device as failed for this stripe".
This flag is set for data devices, not not for parity devices.
Consequently, if you have a RAID6 with two devices that are partly
recovered and a spare, and start a reshape to include the spare,
then when the reshape gets past the point where the recovery was
up to, it will think the stripes are failed and will get into
an infinite loop, failing to make progress.
So when contructing parity on an EXPAND_READY stripe,
set R5_Expanded.
Reported-by: Curt <lightspd(a)gmail.com>
Signed-off-by: NeilBrown <neilb(a)suse.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/raid5.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -1454,8 +1454,11 @@ static void ops_complete_reconstruct(voi
struct r5dev *dev = &sh->dev[i];
if (dev->written || i == pd_idx || i == qd_idx) {
- if (!discard && !test_bit(R5_SkipCopy, &dev->flags))
+ if (!discard && !test_bit(R5_SkipCopy, &dev->flags)) {
set_bit(R5_UPTODATE, &dev->flags);
+ if (test_bit(STRIPE_EXPAND_READY, &sh->state))
+ set_bit(R5_Expanded, &dev->flags);
+ }
if (fua)
set_bit(R5_WantFUA, &dev->flags);
if (sync)
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-3.18/autofs-fix-careless-error-in-recent-commit.patch
queue-3.18/raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch
queue-3.18/nfsd-fix-nfsd_reset_versions-for-nfsv4.patch
queue-3.18/nfsd-fix-nfsd_minorversion-..-nfsd_avail.patch
This is a note to let you know that I've just added the patch titled
ppp: Destroy the mutex when cleanup
to the 3.18-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:
ppp-destroy-the-mutex-when-cleanup.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Gao Feng <gfree.wind(a)vip.163.com>
Date: Tue, 31 Oct 2017 18:25:37 +0800
Subject: ppp: Destroy the mutex when cleanup
From: Gao Feng <gfree.wind(a)vip.163.com>
[ Upstream commit f02b2320b27c16b644691267ee3b5c110846f49e ]
The mutex_destroy only makes sense when enable DEBUG_MUTEX. For the
good readbility, it's better to invoke it in exit func when the init
func invokes mutex_init.
Signed-off-by: Gao Feng <gfree.wind(a)vip.163.com>
Acked-by: Guillaume Nault <g.nault(a)alphalink.fr>
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/ppp/ppp_generic.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -916,6 +916,7 @@ static __net_exit void ppp_exit_net(stru
{
struct ppp_net *pn = net_generic(net, ppp_net_id);
+ mutex_destroy(&pn->all_ppp_mutex);
idr_destroy(&pn->units_idr);
}
Patches currently in stable-queue which might be from gfree.wind(a)vip.163.com are
queue-3.18/ppp-destroy-the-mutex-when-cleanup.patch
This is a note to let you know that I've just added the patch titled
powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo
to the 3.18-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-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Shriya <shriyak(a)linux.vnet.ibm.com>
Date: Fri, 13 Oct 2017 10:06:41 +0530
Subject: powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo
From: Shriya <shriyak(a)linux.vnet.ibm.com>
[ Upstream commit cd77b5ce208c153260ed7882d8910f2395bfaabd ]
The call to /proc/cpuinfo in turn calls cpufreq_quick_get() which
returns the last frequency requested by the kernel, but may not
reflect the actual frequency the processor is running at. This patch
makes a call to cpufreq_get() instead which returns the current
frequency reported by the hardware.
Fixes: fb5153d05a7d ("powerpc: powernv: Implement ppc_md.get_proc_freq()")
Signed-off-by: Shriya <shriyak(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/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -319,7 +319,7 @@ static unsigned long pnv_get_proc_freq(u
{
unsigned long ret_freq;
- ret_freq = cpufreq_quick_get(cpu) * 1000ul;
+ ret_freq = cpufreq_get(cpu) * 1000ul;
/*
* If the backend cpufreq driver does not exist,
Patches currently in stable-queue which might be from shriyak(a)linux.vnet.ibm.com are
queue-3.18/powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch
This is a note to let you know that I've just added the patch titled
powerpc/opal: Fix EBUSY bug in acquiring tokens
to the 3.18-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-opal-fix-ebusy-bug-in-acquiring-tokens.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: "William A. Kennington III" <wak(a)google.com>
Date: Fri, 22 Sep 2017 16:58:00 -0700
Subject: powerpc/opal: Fix EBUSY bug in acquiring tokens
From: "William A. Kennington III" <wak(a)google.com>
[ Upstream commit 71e24d7731a2903b1ae2bba2b2971c654d9c2aa6 ]
The current code checks the completion map to look for the first token
that is complete. In some cases, a completion can come in but the
token can still be on lease to the caller processing the completion.
If this completed but unreleased token is the first token found in the
bitmap by another tasks trying to acquire a token, then the
__test_and_set_bit call will fail since the token will still be on
lease. The acquisition will then fail with an EBUSY.
This patch reorganizes the acquisition code to look at the
opal_async_token_map for an unleased token. If the token has no lease
it must have no outstanding completions so we should never see an
EBUSY, unless we have leased out too many tokens. Since
opal_async_get_token_inrerruptible is protected by a semaphore, we
will practically never see EBUSY anymore.
Fixes: 8d7248232208 ("powerpc/powernv: Infrastructure to support OPAL async completion")
Signed-off-by: William A. Kennington III <wak(a)google.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/opal-async.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/powerpc/platforms/powernv/opal-async.c
+++ b/arch/powerpc/platforms/powernv/opal-async.c
@@ -39,18 +39,18 @@ int __opal_async_get_token(void)
int token;
spin_lock_irqsave(&opal_async_comp_lock, flags);
- token = find_first_bit(opal_async_complete_map, opal_max_async_tokens);
+ token = find_first_zero_bit(opal_async_token_map, opal_max_async_tokens);
if (token >= opal_max_async_tokens) {
token = -EBUSY;
goto out;
}
- if (__test_and_set_bit(token, opal_async_token_map)) {
+ if (!__test_and_clear_bit(token, opal_async_complete_map)) {
token = -EBUSY;
goto out;
}
- __clear_bit(token, opal_async_complete_map);
+ __set_bit(token, opal_async_token_map);
out:
spin_unlock_irqrestore(&opal_async_comp_lock, flags);
Patches currently in stable-queue which might be from wak(a)google.com are
queue-3.18/powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch
This is a note to let you know that I've just added the patch titled
platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill()
to the 3.18-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:
platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Markus Elfring <elfring(a)users.sourceforge.net>
Date: Wed, 1 Nov 2017 18:42:45 +0100
Subject: platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill()
From: Markus Elfring <elfring(a)users.sourceforge.net>
[ Upstream commit f6c8a317ab208aee223776327c06f23342492d54 ]
Source code review for a specific software refactoring showed the need
for another correction because the error code "-1" was returned so far
if a call of the function "sony_call_snc_handle" failed here.
Thus assign the return value from these two function calls also to
the variable "err" and provide it in case of a failure.
Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw")
Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com>
Link: https://lkml.org/lkml/2017/10/31/463
Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg(a)mail.gmail.com>
Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net>
Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/platform/x86/sony-laptop.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1654,17 +1654,19 @@ static int sony_nc_setup_rfkill(struct a
if (!rfk)
return -ENOMEM;
- if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result) < 0) {
+ err = sony_call_snc_handle(sony_rfkill_handle, 0x200, &result);
+ if (err < 0) {
rfkill_destroy(rfk);
- return -1;
+ return err;
}
hwblock = !(result & 0x1);
- if (sony_call_snc_handle(sony_rfkill_handle,
- sony_rfkill_address[nc_type],
- &result) < 0) {
+ err = sony_call_snc_handle(sony_rfkill_handle,
+ sony_rfkill_address[nc_type],
+ &result);
+ if (err < 0) {
rfkill_destroy(rfk);
- return -1;
+ return err;
}
swblock = !(result & 0x2);
Patches currently in stable-queue which might be from elfring(a)users.sourceforge.net are
queue-3.18/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch
This is a note to let you know that I've just added the patch titled
pinctrl: adi2: Fix Kconfig build problem
to the 3.18-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:
pinctrl-adi2-fix-kconfig-build-problem.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Wed, 11 Oct 2017 11:57:15 +0200
Subject: pinctrl: adi2: Fix Kconfig build problem
From: Linus Walleij <linus.walleij(a)linaro.org>
[ Upstream commit 1c363531dd814dc4fe10865722bf6b0f72ce4673 ]
The build robot is complaining on Blackfin:
drivers/pinctrl/pinctrl-adi2.c: In function 'port_setup':
>> drivers/pinctrl/pinctrl-adi2.c:221:21: error: dereferencing
pointer to incomplete type 'struct gpio_port_t'
writew(readw(®s->port_fer) & ~BIT(offset),
^~
drivers/pinctrl/pinctrl-adi2.c: In function 'adi_gpio_ack_irq':
>> drivers/pinctrl/pinctrl-adi2.c:266:18: error: dereferencing
pointer to incomplete type 'struct bfin_pint_regs'
if (readl(®s->invert_set) & pintbit)
^~
It seems the driver need to include <asm/gpio.h> and <asm/irq.h>
to compile.
The Blackfin architecture was re-defining the Kconfig
PINCTRL symbol which is not OK, so replaced this with
PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2
just like most arches do.
Further, the old GPIO driver symbol GPIO_ADI was possible to
select at the same time as selecting PINCTRL. This was not
working because the arch-local <asm/gpio.h> header contains
an explicit #ifndef PINCTRL clause making compilation break
if you combine them. The same is true for DEBUG_MMRS.
Make sure the ADI2 pinctrl driver is not selected at the same
time as the old GPIO implementation. (This should be converted
to use gpiolib or pincontrol and move to drivers/...) Also make
sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at
the same time as the new PINCTRL implementation, and only make
PINCTRL_ADI2 selectable for the Blackfin families that actually
have it.
This way it is still possible to add e.g. I2C-based pin
control expanders on the Blackfin.
Cc: Steven Miao <realmz6(a)gmail.com>
Cc: Huanhuan Feng <huanhuan.feng(a)analog.com>
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>
---
arch/blackfin/Kconfig | 7 +++++--
arch/blackfin/Kconfig.debug | 1 +
drivers/pinctrl/Kconfig | 3 ++-
3 files changed, 8 insertions(+), 3 deletions(-)
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -318,11 +318,14 @@ config BF53x
config GPIO_ADI
def_bool y
+ depends on !PINCTRL
depends on (BF51x || BF52x || BF53x || BF538 || BF539 || BF561)
-config PINCTRL
+config PINCTRL_BLACKFIN_ADI2
def_bool y
- depends on BF54x || BF60x
+ depends on (BF54x || BF60x)
+ select PINCTRL
+ select PINCTRL_ADI2
config MEM_MT48LC64M4A2FB_7E
bool
--- a/arch/blackfin/Kconfig.debug
+++ b/arch/blackfin/Kconfig.debug
@@ -17,6 +17,7 @@ config DEBUG_VERBOSE
config DEBUG_MMRS
tristate "Generate Blackfin MMR tree"
+ depends on !PINCTRL
select DEBUG_FS
help
Create a tree of Blackfin MMRs via the debugfs tree. If
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -28,7 +28,8 @@ config DEBUG_PINCTRL
config PINCTRL_ADI2
bool "ADI pin controller driver"
- depends on BLACKFIN
+ depends on (BF54x || BF60x)
+ depends on !GPIO_ADI
select PINMUX
select IRQ_DOMAIN
help
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-3.18/pinctrl-adi2-fix-kconfig-build-problem.patch
This is a note to let you know that I've just added the patch titled
powerpc/ipic: Fix status get and status clear
to the 3.18-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-ipic-fix-status-get-and-status-clear.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Christophe Leroy <christophe.leroy(a)c-s.fr>
Date: Wed, 18 Oct 2017 11:16:47 +0200
Subject: powerpc/ipic: Fix status get and status clear
From: Christophe Leroy <christophe.leroy(a)c-s.fr>
[ Upstream commit 6b148a7ce72a7f87c81cbcde48af014abc0516a9 ]
IPIC Status is provided by register IPIC_SERSR and not by IPIC_SERMR
which is the mask register.
Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr>
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/sysdev/ipic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -844,12 +844,12 @@ void ipic_disable_mcp(enum ipic_mcp_irq
u32 ipic_get_mcp_status(void)
{
- return ipic_read(primary_ipic->regs, IPIC_SERMR);
+ return ipic_read(primary_ipic->regs, IPIC_SERSR);
}
void ipic_clear_mcp_status(u32 mask)
{
- ipic_write(primary_ipic->regs, IPIC_SERMR, mask);
+ ipic_write(primary_ipic->regs, IPIC_SERSR, mask);
}
/* Return an interrupt vector or NO_IRQ if no interrupt is pending. */
Patches currently in stable-queue which might be from christophe.leroy(a)c-s.fr are
queue-3.18/powerpc-ipic-fix-status-get-and-status-clear.patch
This is a note to let you know that I've just added the patch titled
perf symbols: Fix symbols__fixup_end heuristic for corner cases
to the 3.18-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:
perf-symbols-fix-symbols__fixup_end-heuristic-for-corner-cases.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Daniel Borkmann <daniel(a)iogearbox.net>
Date: Wed, 15 Mar 2017 22:53:37 +0100
Subject: perf symbols: Fix symbols__fixup_end heuristic for corner cases
From: Daniel Borkmann <daniel(a)iogearbox.net>
[ Upstream commit e7ede72a6d40cb3a30c087142d79381ca8a31dab ]
The current symbols__fixup_end() heuristic for the last entry in the rb
tree is suboptimal as it leads to not being able to recognize the symbol
in the call graph in a couple of corner cases, for example:
i) If the symbol has a start address (f.e. exposed via kallsyms)
that is at a page boundary, then the roundup(curr->start, 4096)
for the last entry will result in curr->start == curr->end with
a symbol length of zero.
ii) If the symbol has a start address that is shortly before a page
boundary, then also here, curr->end - curr->start will just be
very few bytes, where it's unrealistic that we could perform a
match against.
Instead, change the heuristic to roundup(curr->start, 4096) + 4096, so
that we can catch such corner cases and have a better chance to find
that specific symbol. It's still just best effort as the real end of the
symbol is unknown to us (and could even be at a larger offset than the
current range), but better than the current situation.
Alexei reported that he recently run into case i) with a JITed eBPF
program (these are all page aligned) as the last symbol which wasn't
properly shown in the call graph (while other eBPF program symbols in
the rb tree were displayed correctly). Since this is a generic issue,
lets try to improve the heuristic a bit.
Reported-and-Tested-by: Alexei Starovoitov <ast(a)kernel.org>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
Fixes: 2e538c4a1847 ("perf tools: Improve kernel/modules symbol lookup")
Link: http://lkml.kernel.org/r/bb5c80d27743be6f12afc68405f1956a330e1bc9.148961436…
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/util/symbol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -191,7 +191,7 @@ void symbols__fixup_end(struct rb_root *
/* Last entry */
if (curr->end == curr->start)
- curr->end = roundup(curr->start, 4096);
+ curr->end = roundup(curr->start, 4096) + 4096;
}
void __map_groups__fixup_end(struct map_groups *mg, enum map_type type)
Patches currently in stable-queue which might be from daniel(a)iogearbox.net are
queue-3.18/perf-symbols-fix-symbols__fixup_end-heuristic-for-corner-cases.patch
This is a note to let you know that I've just added the patch titled
PCI/PME: Handle invalid data when reading Root Status
to the 3.18-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-pme-handle-invalid-data-when-reading-root-status.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Qiang <zhengqiang10(a)huawei.com>
Date: Thu, 28 Sep 2017 11:54:34 +0800
Subject: PCI/PME: Handle invalid data when reading Root Status
From: Qiang <zhengqiang10(a)huawei.com>
[ Upstream commit 3ad3f8ce50914288731a3018b27ee44ab803e170 ]
PCIe PME and native hotplug share the same interrupt number, so hotplug
interrupts are also processed by PME. In some cases, e.g., a Link Down
interrupt, a device may be present but unreachable, so when we try to
read its Root Status register, the read fails and we get all ones data
(0xffffffff).
Previously, we interpreted that data as PCI_EXP_RTSTA_PME being set, i.e.,
"some device has asserted PME," so we scheduled pcie_pme_work_fn(). This
caused an infinite loop because pcie_pme_work_fn() tried to handle PME
requests until PCI_EXP_RTSTA_PME is cleared, but with the link down,
PCI_EXP_RTSTA_PME can't be cleared.
Check for the invalid 0xffffffff data everywhere we read the Root Status
register.
1469d17dd341 ("PCI: pciehp: Handle invalid data when reading from
non-existent devices") added similar checks in the hotplug driver.
Signed-off-by: Qiang Zheng <zhengqiang10(a)huawei.com>
[bhelgaas: changelog, also check in pcie_pme_work_fn(), use "~0" to follow
other similar checks]
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/pme.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/pci/pcie/pme.c
+++ b/drivers/pci/pcie/pme.c
@@ -233,6 +233,9 @@ static void pcie_pme_work_fn(struct work
break;
pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta);
+ if (rtsta == (u32) ~0)
+ break;
+
if (rtsta & PCI_EXP_RTSTA_PME) {
/*
* Clear PME status of the port. If there are other
@@ -280,7 +283,7 @@ static irqreturn_t pcie_pme_irq(int irq,
spin_lock_irqsave(&data->lock, flags);
pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta);
- if (!(rtsta & PCI_EXP_RTSTA_PME)) {
+ if (rtsta == (u32) ~0 || !(rtsta & PCI_EXP_RTSTA_PME)) {
spin_unlock_irqrestore(&data->lock, flags);
return IRQ_NONE;
}
Patches currently in stable-queue which might be from zhengqiang10(a)huawei.com are
queue-3.18/pci-pme-handle-invalid-data-when-reading-root-status.patch
This is a note to let you know that I've just added the patch titled
PCI: Detach driver before procfs & sysfs teardown on device remove
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-detach-driver-before-procfs-sysfs-teardown-on-device-remove.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Alex Williamson <alex.williamson(a)redhat.com>
Date: Wed, 11 Oct 2017 15:35:56 -0600
Subject: PCI: Detach driver before procfs & sysfs teardown on device remove
From: Alex Williamson <alex.williamson(a)redhat.com>
[ Upstream commit 16b6c8bb687cc3bec914de09061fcb8411951fda ]
When removing a device, for example a VF being removed due to SR-IOV
teardown, a "soft" hot-unplug via 'echo 1 > remove' in sysfs, or an actual
hot-unplug, we first remove the procfs and sysfs attributes for the device
before attempting to release the device from any driver bound to it.
Unbinding the driver from the device can take time. The device might need
to write out data or it might be actively in use. If it's in use by
userspace through a vfio driver, the unbind might block until the user
releases the device. This leads to a potentially non-trivial amount of
time where the device exists, but we've torn down the interfaces that
userspace uses to examine devices, for instance lspci might generate this
sort of error:
pcilib: Cannot open /sys/bus/pci/devices/0000:01:0a.3/config
lspci: Unable to read the standard configuration space header of device 0000:01:0a.3
We don't seem to have any dependence on this teardown ordering in the
kernel, so let's unbind the driver first, which is also more symmetric with
the instantiation of the device in pci_bus_add_device().
Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/remove.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -20,9 +20,9 @@ static void pci_stop_dev(struct pci_dev
pci_pme_active(dev, false);
if (dev->is_added) {
+ device_release_driver(&dev->dev);
pci_proc_detach_device(dev);
pci_remove_sysfs_dev_files(dev);
- device_release_driver(&dev->dev);
dev->is_added = 0;
}
Patches currently in stable-queue which might be from alex.williamson(a)redhat.com are
queue-3.18/pci-detach-driver-before-procfs-sysfs-teardown-on-device-remove.patch