From: Dmitry Eremin <Dmitry.Eremin(a)intel.com>
The logic of the original commit 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for ko2iblnd")
was assumed conditional free of struct kib_conn if the second argument free_conn
in function kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn) is true.
But this hunk of code was dropped from original commit. As result the logic
works wrong and current code use struct kib_conn after free.
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
> 3317 kiblnd_destroy_conn(conn, !peer);
> ^^^^ Freed always (but should be conditionally)
> 3318
> 3319 spin_lock_irqsave(lock, flags);
> 3320 if (!peer)
> 3321 continue;
> 3322
> 3323 conn->ibc_peer = peer;
> ^^^^^^^^^^^^^^ Use after free
> 3324 if (peer->ibp_reconnected < KIB_RECONN_HIGH_RACE)
> 3325 list_add_tail(&conn->ibc_list,
> ^^^^^^^^^^^^^^ Use after free
> 3326 &kiblnd_data.kib_reconn_list);
> 3327 else
> 3328 list_add_tail(&conn->ibc_list,
> ^^^^^^^^^^^^^^ Use after free
> 3329 &kiblnd_data.kib_reconn_wait);
After attached patch this code will use struct kib_conn only when it was not freed.
Cc: <stable(a)vger.kernel.org> # v4.6
Fixes: 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for ko2iblnd")
Signed-off-by: Dmitry Eremin <Dmitry.Eremin(a)intel.com>
Signed-off-by: Dmitry Eremin <dmitry.eremin(a)intel.com>
---
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index 2ebc484385b3..a15a625ee9b6 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -890,7 +890,8 @@ void kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn)
atomic_dec(&net->ibn_nconns);
}
- kfree(conn);
+ if (free_conn)
+ kfree(conn);
}
int kiblnd_close_peer_conns_locked(struct kib_peer *peer, int why)
--
1.8.3.1
--------------------------------------------------------------------
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation
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.
This is a note to let you know that I've just added the patch titled
timers: Plug locking race vs. timer migration
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:
timers-plug-locking-race-vs.-timer-migration.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 b831275a3553c32091222ac619cfddd73a5553fb Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <tglx(a)linutronix.de>
Date: Mon, 24 Oct 2016 11:41:56 +0200
Subject: timers: Plug locking race vs. timer migration
From: Thomas Gleixner <tglx(a)linutronix.de>
commit b831275a3553c32091222ac619cfddd73a5553fb upstream.
Linus noticed that lock_timer_base() lacks a READ_ONCE() for accessing the
timer flags. As a consequence the compiler is allowed to reload the flags
between the initial check for TIMER_MIGRATION and the following timer base
computation and the spin lock of the base.
While this has not been observed (yet), we need to make sure that it never
happens.
Fixes: 0eeda71bc30d ("timer: Replace timer base by a cpu index")
Reported-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1610241711220.4983@nanos
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Signed-off-by: Mike Galbraith <mgalbraith(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/timer.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -764,8 +764,15 @@ static struct tvec_base *lock_timer_base
__acquires(timer->base->lock)
{
for (;;) {
- u32 tf = timer->flags;
struct tvec_base *base;
+ u32 tf;
+
+ /*
+ * We need to use READ_ONCE() here, otherwise the compiler
+ * might re-read @tf between the check for TIMER_MIGRATING
+ * and spin_lock().
+ */
+ tf = READ_ONCE(timer->flags);
if (!(tf & TIMER_MIGRATING)) {
base = per_cpu_ptr(&tvec_bases, tf & TIMER_CPUMASK);
Patches currently in stable-queue which might be from tglx(a)linutronix.de are
queue-4.4/prevent-timer-value-0-for-mwaitx.patch
queue-4.4/x86-asm-32-make-sync_core-handle-missing-cpuid-on-all-32-bit-kernels.patch
queue-4.4/timers-plug-locking-race-vs.-timer-migration.patch
queue-4.4/x86-cpu-intel-introduce-macros-for-intel-family-numbers.patch
queue-4.4/x86-retpoline-fill-rsb-on-context-switch-for-affected-cpus.patch
queue-4.4/time-avoid-undefined-behaviour-in-ktime_add_safe.patch
queue-4.4/sched-deadline-use-the-revised-wakeup-rule-for-suspending-constrained-dl-tasks.patch
This is a note to let you know that I've just added the patch titled
time: Avoid undefined behaviour in ktime_add_safe()
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:
time-avoid-undefined-behaviour-in-ktime_add_safe.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 979515c5645830465739254abc1b1648ada41518 Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum(a)oracle.com>
Date: Sat, 13 Aug 2016 01:37:04 +0200
Subject: time: Avoid undefined behaviour in ktime_add_safe()
From: Vegard Nossum <vegard.nossum(a)oracle.com>
commit 979515c5645830465739254abc1b1648ada41518 upstream.
I ran into this:
================================================================================
UBSAN: Undefined behaviour in kernel/time/hrtimer.c:310:16
signed integer overflow:
9223372036854775807 + 50000 cannot be represented in type 'long long int'
CPU: 2 PID: 4798 Comm: trinity-c2 Not tainted 4.8.0-rc1+ #91
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
0000000000000000 ffff88010ce6fb88 ffffffff82344740 0000000041b58ab3
ffffffff84f97a20 ffffffff82344694 ffff88010ce6fbb0 ffff88010ce6fb60
000000000000c350 ffff88010ce6f968 dffffc0000000000 ffffffff857bc320
Call Trace:
[<ffffffff82344740>] dump_stack+0xac/0xfc
[<ffffffff82344694>] ? _atomic_dec_and_lock+0xc4/0xc4
[<ffffffff8242df78>] ubsan_epilogue+0xd/0x8a
[<ffffffff8242e6b4>] handle_overflow+0x202/0x23d
[<ffffffff8242e4b2>] ? val_to_string.constprop.6+0x11e/0x11e
[<ffffffff8236df71>] ? timerqueue_add+0x151/0x410
[<ffffffff81485c48>] ? hrtimer_start_range_ns+0x3b8/0x1380
[<ffffffff81795631>] ? memset+0x31/0x40
[<ffffffff8242e6fd>] __ubsan_handle_add_overflow+0xe/0x10
[<ffffffff81488ac9>] hrtimer_nanosleep+0x5d9/0x790
[<ffffffff814884f0>] ? hrtimer_init_sleeper+0x80/0x80
[<ffffffff813a9ffb>] ? __might_sleep+0x5b/0x260
[<ffffffff8148be10>] common_nsleep+0x20/0x30
[<ffffffff814906c7>] SyS_clock_nanosleep+0x197/0x210
[<ffffffff81490530>] ? SyS_clock_getres+0x150/0x150
[<ffffffff823c7113>] ? __this_cpu_preempt_check+0x13/0x20
[<ffffffff8162ef60>] ? __context_tracking_exit.part.3+0x30/0x1b0
[<ffffffff81490530>] ? SyS_clock_getres+0x150/0x150
[<ffffffff81007bd3>] do_syscall_64+0x1b3/0x4b0
[<ffffffff845f85aa>] entry_SYSCALL64_slow_path+0x25/0x25
================================================================================
Add a new ktime_add_unsafe() helper which doesn't check for overflow, but
doesn't throw a UBSAN warning when it does overflow either.
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Ingo Molnar <mingo(a)kernel.org>
Cc: Richard Cochran <richardcochran(a)gmail.com>
Cc: Prarit Bhargava <prarit(a)redhat.com>
Signed-off-by: Vegard Nossum <vegard.nossum(a)oracle.com>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Jiri Slaby <jslaby(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/ktime.h | 7 +++++++
kernel/time/hrtimer.c | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
--- a/include/linux/ktime.h
+++ b/include/linux/ktime.h
@@ -64,6 +64,13 @@ static inline ktime_t ktime_set(const s6
({ (ktime_t){ .tv64 = (lhs).tv64 + (rhs).tv64 }; })
/*
+ * Same as ktime_add(), but avoids undefined behaviour on overflow; however,
+ * this means that you must check the result for overflow yourself.
+ */
+#define ktime_add_unsafe(lhs, rhs) \
+ ({ (ktime_t){ .tv64 = (u64) (lhs).tv64 + (rhs).tv64 }; })
+
+/*
* Add a ktime_t variable and a scalar nanosecond value.
* res = kt + nsval:
*/
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -312,7 +312,7 @@ EXPORT_SYMBOL_GPL(__ktime_divns);
*/
ktime_t ktime_add_safe(const ktime_t lhs, const ktime_t rhs)
{
- ktime_t res = ktime_add(lhs, rhs);
+ ktime_t res = ktime_add_unsafe(lhs, rhs);
/*
* We use KTIME_SEC_MAX here, the maximum timeout which we can
Patches currently in stable-queue which might be from vegard.nossum(a)oracle.com are
queue-4.4/time-avoid-undefined-behaviour-in-ktime_add_safe.patch
This is a note to let you know that I've just added the patch titled
Prevent timer value 0 for MWAITX
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:
prevent-timer-value-0-for-mwaitx.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 88d879d29f9cc0de2d930b584285638cdada6625 Mon Sep 17 00:00:00 2001
From: Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
Date: Tue, 25 Apr 2017 16:44:03 -0500
Subject: Prevent timer value 0 for MWAITX
From: Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
commit 88d879d29f9cc0de2d930b584285638cdada6625 upstream.
Newer hardware has uncovered a bug in the software implementation of
using MWAITX for the delay function. A value of 0 for the timer is meant
to indicate that a timeout will not be used to exit MWAITX. On newer
hardware this can result in MWAITX never returning, resulting in NMI
soft lockup messages being printed. On older hardware, some of the other
conditions under which MWAITX can exit masked this issue. The AMD APM
does not currently document this and will be updated.
Please refer to http://marc.info/?l=kvm&m=148950623231140 for
information regarding NMI soft lockup messages on an AMD Ryzen 1800X.
This has been root-caused as a 0 passed to MWAITX causing it to wait
indefinitely.
This change has the added benefit of avoiding the unnecessary setup of
MONITORX/MWAITX when the delay value is zero.
Signed-off-by: Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
Link: http://lkml.kernel.org/r/1493156643-29366-1-git-send-email-Janakarajan.Nata…
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Davidlohr Bueso <dbueso(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/lib/delay.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/arch/x86/lib/delay.c
+++ b/arch/x86/lib/delay.c
@@ -93,6 +93,13 @@ static void delay_mwaitx(unsigned long _
{
u64 start, end, delay, loops = __loops;
+ /*
+ * Timer value of 0 causes MWAITX to wait indefinitely, unless there
+ * is a store on the memory monitored by MONITORX.
+ */
+ if (loops == 0)
+ return;
+
start = rdtsc_ordered();
for (;;) {
Patches currently in stable-queue which might be from Janakarajan.Natarajan(a)amd.com are
queue-4.4/prevent-timer-value-0-for-mwaitx.patch
This is a note to let you know that I've just added the patch titled
PM / sleep: declare __tracedata symbols as char[] rather than char
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:
pm-sleep-declare-__tracedata-symbols-as-char-rather-than-char.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 f97238373b8662a6d580e204df2e7bcbfa43e27a Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers3(a)gmail.com>
Date: Sun, 24 Jan 2016 20:08:52 -0600
Subject: PM / sleep: declare __tracedata symbols as char[] rather than char
From: Eric Biggers <ebiggers3(a)gmail.com>
commit f97238373b8662a6d580e204df2e7bcbfa43e27a upstream.
Accessing more than one byte from a symbol declared simply 'char' is undefined
behavior, as reported by UBSAN:
UBSAN: Undefined behaviour in drivers/base/power/trace.c:178:18
load of address ffffffff8203fc78 with insufficient space
for an object of type 'char'
Avoid this by declaring the symbols as arrays.
Signed-off-by: Eric Biggers <ebiggers3(a)gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Jiri Slaby <jslaby(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/power/trace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/base/power/trace.c
+++ b/drivers/base/power/trace.c
@@ -166,14 +166,14 @@ void generate_pm_trace(const void *trace
}
EXPORT_SYMBOL(generate_pm_trace);
-extern char __tracedata_start, __tracedata_end;
+extern char __tracedata_start[], __tracedata_end[];
static int show_file_hash(unsigned int value)
{
int match;
char *tracedata;
match = 0;
- for (tracedata = &__tracedata_start ; tracedata < &__tracedata_end ;
+ for (tracedata = __tracedata_start ; tracedata < __tracedata_end ;
tracedata += 2 + sizeof(unsigned long)) {
unsigned short lineno = *(unsigned short *)tracedata;
const char *file = *(const char **)(tracedata + 2);
Patches currently in stable-queue which might be from ebiggers3(a)gmail.com are
queue-4.4/pm-sleep-declare-__tracedata-symbols-as-char-rather-than-char.patch
This is a note to let you know that I've just added the patch titled
PCI: layerscape: Fix MSG TLP drop setting
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-layerscape-fix-msg-tlp-drop-setting.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 1195c103f6c98d9ff381cac3a8760d4f8a133627 Mon Sep 17 00:00:00 2001
From: Minghuan Lian <Minghuan.Lian(a)nxp.com>
Date: Mon, 29 Feb 2016 17:24:15 -0600
Subject: PCI: layerscape: Fix MSG TLP drop setting
From: Minghuan Lian <Minghuan.Lian(a)nxp.com>
commit 1195c103f6c98d9ff381cac3a8760d4f8a133627 upstream.
Some kinds of Layerscape PCIe controllers will forward the received message
TLPs to system application address space, which could corrupt system memory
or lead to a system hang. Enable MSG_DROP to fix this issue.
Signed-off-by: Minghuan Lian <Minghuan.Lian(a)nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Signed-off-by: Matthias Brugger <mbrugger(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pci-layerscape.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
--- a/drivers/pci/host/pci-layerscape.c
+++ b/drivers/pci/host/pci-layerscape.c
@@ -77,6 +77,16 @@ static void ls_pcie_fix_class(struct ls_
iowrite16(PCI_CLASS_BRIDGE_PCI, pcie->dbi + PCI_CLASS_DEVICE);
}
+/* Drop MSG TLP except for Vendor MSG */
+static void ls_pcie_drop_msg_tlp(struct ls_pcie *pcie)
+{
+ u32 val;
+
+ val = ioread32(pcie->dbi + PCIE_STRFMR1);
+ val &= 0xDFFFFFFF;
+ iowrite32(val, pcie->dbi + PCIE_STRFMR1);
+}
+
static int ls1021_pcie_link_up(struct pcie_port *pp)
{
u32 state;
@@ -97,7 +107,7 @@ static int ls1021_pcie_link_up(struct pc
static void ls1021_pcie_host_init(struct pcie_port *pp)
{
struct ls_pcie *pcie = to_ls_pcie(pp);
- u32 val, index[2];
+ u32 index[2];
pcie->scfg = syscon_regmap_lookup_by_phandle(pp->dev->of_node,
"fsl,pcie-scfg");
@@ -116,13 +126,7 @@ static void ls1021_pcie_host_init(struct
dw_pcie_setup_rc(pp);
- /*
- * LS1021A Workaround for internal TKT228622
- * to fix the INTx hang issue
- */
- val = ioread32(pcie->dbi + PCIE_STRFMR1);
- val &= 0xffff;
- iowrite32(val, pcie->dbi + PCIE_STRFMR1);
+ ls_pcie_drop_msg_tlp(pcie);
}
static int ls_pcie_link_up(struct pcie_port *pp)
@@ -147,6 +151,7 @@ static void ls_pcie_host_init(struct pci
iowrite32(1, pcie->dbi + PCIE_DBI_RO_WR_EN);
ls_pcie_fix_class(pcie);
ls_pcie_clear_multifunction(pcie);
+ ls_pcie_drop_msg_tlp(pcie);
iowrite32(0, pcie->dbi + PCIE_DBI_RO_WR_EN);
}
Patches currently in stable-queue which might be from Minghuan.Lian(a)nxp.com are
queue-4.4/pci-layerscape-fix-msg-tlp-drop-setting.patch
This is a note to let you know that I've just added the patch titled
PCI: layerscape: Add "fsl,ls2085a-pcie" compatible ID
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-layerscape-add-fsl-ls2085a-pcie-compatible-id.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 dbae40b76abef2f8a7e7bf1701f77df9e73def48 Mon Sep 17 00:00:00 2001
From: Yang Shi <yang.shi(a)linaro.org>
Date: Wed, 27 Jan 2016 09:32:05 -0800
Subject: PCI: layerscape: Add "fsl,ls2085a-pcie" compatible ID
From: Yang Shi <yang.shi(a)linaro.org>
commit dbae40b76abef2f8a7e7bf1701f77df9e73def48 upstream.
The Layerscape PCI host driver must recognize ls2085a compatible when using
firmware with ls2085a compatible property, otherwise the PCI bus won't be
detected even though ls2085a compatible is included by the dts.
Signed-off-by: Yang Shi <yang.shi(a)linaro.org>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Signed-off-by: Matthias Brugger <mbrugger(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pci-layerscape.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/pci/host/pci-layerscape.c
+++ b/drivers/pci/host/pci-layerscape.c
@@ -203,6 +203,7 @@ static const struct of_device_id ls_pcie
{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
+ { .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
{ },
};
MODULE_DEVICE_TABLE(of, ls_pcie_of_match);
Patches currently in stable-queue which might be from yang.shi(a)linaro.org are
queue-4.4/pci-layerscape-add-fsl-ls2085a-pcie-compatible-id.patch
This is a note to let you know that I've just added the patch titled
mmc: sdhci-of-esdhc: add/remove some quirks according to vendor version
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:
mmc-sdhci-of-esdhc-add-remove-some-quirks-according-to-vendor-version.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 1ef5e49e46b919052474d9b54a15debc79ff0133 Mon Sep 17 00:00:00 2001
From: yangbo lu <yangbo.lu(a)freescale.com>
Date: Wed, 25 Nov 2015 10:05:37 +0800
Subject: mmc: sdhci-of-esdhc: add/remove some quirks according to vendor version
From: yangbo lu <yangbo.lu(a)freescale.com>
commit 1ef5e49e46b919052474d9b54a15debc79ff0133 upstream.
A previous patch had removed esdhc_of_platform_init() by mistake.
static void esdhc_of_platform_init(struct sdhci_host *host)
{
u32 vvn;
vvn = in_be32(host->ioaddr + SDHCI_SLOT_INT_STATUS);
vvn = (vvn & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
if (vvn == VENDOR_V_22)
host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
if (vvn > VENDOR_V_22)
host->quirks &= ~SDHCI_QUIRK_NO_BUSY_IRQ;
}
This patch is used to fix it by add/remove some quirks according to
verdor version in probe.
Signed-off-by: Yangbo Lu <yangbo.lu(a)freescale.com>
Fixes: f4932cfd22f1 ("mmc: sdhci-of-esdhc: support both BE and LE host controller")
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Signed-off-by: Matthias Brugger <mbrugger(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/sdhci-of-esdhc.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -584,6 +584,8 @@ static int sdhci_esdhc_probe(struct plat
{
struct sdhci_host *host;
struct device_node *np;
+ struct sdhci_pltfm_host *pltfm_host;
+ struct sdhci_esdhc *esdhc;
int ret;
np = pdev->dev.of_node;
@@ -600,6 +602,14 @@ static int sdhci_esdhc_probe(struct plat
sdhci_get_of_property(pdev);
+ pltfm_host = sdhci_priv(host);
+ esdhc = pltfm_host->priv;
+ if (esdhc->vendor_ver == VENDOR_V_22)
+ host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
+
+ if (esdhc->vendor_ver > VENDOR_V_22)
+ host->quirks &= ~SDHCI_QUIRK_NO_BUSY_IRQ;
+
if (of_device_is_compatible(np, "fsl,p5040-esdhc") ||
of_device_is_compatible(np, "fsl,p5020-esdhc") ||
of_device_is_compatible(np, "fsl,p4080-esdhc") ||
Patches currently in stable-queue which might be from yangbo.lu(a)freescale.com are
queue-4.4/mmc-sdhci-of-esdhc-add-remove-some-quirks-according-to-vendor-version.patch
This is a note to let you know that I've just added the patch titled
fs/select: add vmalloc fallback for select(2)
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:
fs-select-add-vmalloc-fallback-for-select-2.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 2d19309cf86883f634a4f8ec55a54bda87db19bf Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka(a)suse.cz>
Date: Tue, 11 Oct 2016 13:51:14 -0700
Subject: fs/select: add vmalloc fallback for select(2)
From: Vlastimil Babka <vbabka(a)suse.cz>
commit 2d19309cf86883f634a4f8ec55a54bda87db19bf upstream.
The select(2) syscall performs a kmalloc(size, GFP_KERNEL) where size grows
with the number of fds passed. We had a customer report page allocation
failures of order-4 for this allocation. This is a costly order, so it might
easily fail, as the VM expects such allocation to have a lower-order fallback.
Such trivial fallback is vmalloc(), as the memory doesn't have to be physically
contiguous and the allocation is temporary for the duration of the syscall
only. There were some concerns, whether this would have negative impact on the
system by exposing vmalloc() to userspace. Although an excessive use of vmalloc
can cause some system wide performance issues - TLB flushes etc. - a large
order allocation is not for free either and an excessive reclaim/compaction can
have a similar effect. Also note that the size is effectively limited by
RLIMIT_NOFILE which defaults to 1024 on the systems I checked. That means the
bitmaps will fit well within single page and thus the vmalloc() fallback could
be only excercised for processes where root allows a higher limit.
Note that the poll(2) syscall seems to use a linked list of order-0 pages, so
it doesn't need this kind of fallback.
[eric.dumazet(a)gmail.com: fix failure path logic]
[akpm(a)linux-foundation.org: use proper type for size]
Link: http://lkml.kernel.org/r/20160927084536.5923-1-vbabka@suse.cz
Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: Eric Dumazet <eric.dumazet(a)gmail.com>
Cc: David Laight <David.Laight(a)ACULAB.COM>
Cc: Hillf Danton <hillf.zj(a)alibaba-inc.com>
Cc: Nicholas Piggin <npiggin(a)gmail.com>
Cc: Jason Baron <jbaron(a)akamai.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/select.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/fs/select.c
+++ b/fs/select.c
@@ -29,6 +29,7 @@
#include <linux/sched/rt.h>
#include <linux/freezer.h>
#include <net/busy_poll.h>
+#include <linux/vmalloc.h>
#include <asm/uaccess.h>
@@ -550,7 +551,7 @@ int core_sys_select(int n, fd_set __user
fd_set_bits fds;
void *bits;
int ret, max_fds;
- unsigned int size;
+ size_t size, alloc_size;
struct fdtable *fdt;
/* Allocate small arguments on the stack to save memory and be faster */
long stack_fds[SELECT_STACK_ALLOC/sizeof(long)];
@@ -577,7 +578,14 @@ int core_sys_select(int n, fd_set __user
if (size > sizeof(stack_fds) / 6) {
/* Not enough space in on-stack array; must use kmalloc */
ret = -ENOMEM;
- bits = kmalloc(6 * size, GFP_KERNEL);
+ if (size > (SIZE_MAX / 6))
+ goto out_nofds;
+
+ alloc_size = 6 * size;
+ bits = kmalloc(alloc_size, GFP_KERNEL|__GFP_NOWARN);
+ if (!bits && alloc_size > PAGE_SIZE)
+ bits = vmalloc(alloc_size);
+
if (!bits)
goto out_nofds;
}
@@ -614,7 +622,7 @@ int core_sys_select(int n, fd_set __user
out:
if (bits != stack_fds)
- kfree(bits);
+ kvfree(bits);
out_nofds:
return ret;
}
Patches currently in stable-queue which might be from vbabka(a)suse.cz are
queue-4.4/fs-select-add-vmalloc-fallback-for-select-2.patch
This is a note to let you know that I've just added the patch titled
drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled
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:
drivers-base-cacheinfo-fix-x86-with-config_of-enabled.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 fac51482577d5e05bbb0efa8d602a3c2111098bf Mon Sep 17 00:00:00 2001
From: Sudeep Holla <sudeep.holla(a)arm.com>
Date: Fri, 28 Oct 2016 09:45:28 +0100
Subject: drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled
From: Sudeep Holla <sudeep.holla(a)arm.com>
commit fac51482577d5e05bbb0efa8d602a3c2111098bf upstream.
With CONFIG_OF enabled on x86, we get the following error on boot:
"
Failed to find cpu0 device node
Unable to detect cache hierarchy from DT for CPU 0
"
and the cacheinfo fails to get populated in the corresponding sysfs
entries. This is because cache_setup_of_node looks for of_node for
setting up the shared cpu_map without checking that it's already
populated in the architecture specific callback.
In order to indicate that the shared cpu_map is already populated, this
patch introduces a boolean `cpu_map_populated` in struct cpu_cacheinfo
that can be used by the generic code to skip cache_shared_cpu_map_setup.
This patch also sets that boolean for x86.
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com>
Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/intel_cacheinfo.c | 2 ++
drivers/base/cacheinfo.c | 3 +++
include/linux/cacheinfo.h | 1 +
3 files changed, 6 insertions(+)
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -934,6 +934,8 @@ static int __populate_cache_leaves(unsig
ci_leaf_init(this_leaf++, &id4_regs);
__cache_cpumap_setup(cpu, idx, &id4_regs);
}
+ this_cpu_ci->cpu_map_populated = true;
+
return 0;
}
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -106,6 +106,9 @@ static int cache_shared_cpu_map_setup(un
unsigned int index;
int ret;
+ if (this_cpu_ci->cpu_map_populated)
+ return 0;
+
ret = cache_setup_of_node(cpu);
if (ret)
return ret;
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@ -71,6 +71,7 @@ struct cpu_cacheinfo {
struct cacheinfo *info_list;
unsigned int num_levels;
unsigned int num_leaves;
+ bool cpu_map_populated;
};
/*
Patches currently in stable-queue which might be from sudeep.holla(a)arm.com are
queue-4.4/drivers-base-cacheinfo-fix-x86-with-config_of-enabled.patch
queue-4.4/drivers-base-cacheinfo-fix-boot-error-message-when-acpi-is-enabled.patch