This is a note to let you know that I've just added the patch titled
ARM: 8720/1: ensure dump_instr() checks addr_limit
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:
arm-8720-1-ensure-dump_instr-checks-addr_limit.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 b9dd05c7002ee0ca8b676428b2268c26399b5e31 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland(a)arm.com>
Date: Thu, 2 Nov 2017 18:44:28 +0100
Subject: ARM: 8720/1: ensure dump_instr() checks addr_limit
From: Mark Rutland <mark.rutland(a)arm.com>
commit b9dd05c7002ee0ca8b676428b2268c26399b5e31 upstream.
When CONFIG_DEBUG_USER is enabled, it's possible for a user to
deliberately trigger dump_instr() with a chosen kernel address.
Let's avoid problems resulting from this by using get_user() rather than
__get_user(), ensuring that we don't erroneously access kernel memory.
So that we can use the same code to dump user instructions and kernel
instructions, the common dumping code is factored out to __dump_instr(),
with the fs manipulated appropriately in dump_instr() around calls to
this.
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/kernel/traps.c | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -132,30 +132,26 @@ static void dump_mem(const char *lvl, co
set_fs(fs);
}
-static void dump_instr(const char *lvl, struct pt_regs *regs)
+static void __dump_instr(const char *lvl, struct pt_regs *regs)
{
unsigned long addr = instruction_pointer(regs);
const int thumb = thumb_mode(regs);
const int width = thumb ? 4 : 8;
- mm_segment_t fs;
char str[sizeof("00000000 ") * 5 + 2 + 1], *p = str;
int i;
/*
- * We need to switch to kernel mode so that we can use __get_user
- * to safely read from kernel space. Note that we now dump the
- * code first, just in case the backtrace kills us.
+ * Note that we now dump the code first, just in case the backtrace
+ * kills us.
*/
- fs = get_fs();
- set_fs(KERNEL_DS);
for (i = -4; i < 1 + !!thumb; i++) {
unsigned int val, bad;
if (thumb)
- bad = __get_user(val, &((u16 *)addr)[i]);
+ bad = get_user(val, &((u16 *)addr)[i]);
else
- bad = __get_user(val, &((u32 *)addr)[i]);
+ bad = get_user(val, &((u32 *)addr)[i]);
if (!bad)
p += sprintf(p, i == 0 ? "(%0*x) " : "%0*x ",
@@ -166,8 +162,20 @@ static void dump_instr(const char *lvl,
}
}
printk("%sCode: %s\n", lvl, str);
+}
- set_fs(fs);
+static void dump_instr(const char *lvl, struct pt_regs *regs)
+{
+ mm_segment_t fs;
+
+ if (!user_mode(regs)) {
+ fs = get_fs();
+ set_fs(KERNEL_DS);
+ __dump_instr(lvl, regs);
+ set_fs(fs);
+ } else {
+ __dump_instr(lvl, regs);
+ }
}
#ifdef CONFIG_ARM_UNWIND
Patches currently in stable-queue which might be from mark.rutland(a)arm.com are
queue-3.18/arm-8720-1-ensure-dump_instr-checks-addr_limit.patch
This is a note to let you know that I've just added the patch titled
ALSA: seq: Fix OSS sysex delivery in OSS emulation
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:
alsa-seq-fix-oss-sysex-delivery-in-oss-emulation.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 132d358b183ac6ad8b3fea32ad5e0663456d18d1 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Tue, 7 Nov 2017 16:05:24 +0100
Subject: ALSA: seq: Fix OSS sysex delivery in OSS emulation
From: Takashi Iwai <tiwai(a)suse.de>
commit 132d358b183ac6ad8b3fea32ad5e0663456d18d1 upstream.
The SYSEX event delivery in OSS sequencer emulation assumed that the
event is encoded in the variable-length data with the straight
buffering. This was the normal behavior in the past, but during the
development, the chained buffers were introduced for carrying more
data, while the OSS code was left intact. As a result, when a SYSEX
event with the chained buffer data is passed to OSS sequencer port,
it may end up with the wrong memory access, as if it were having a too
large buffer.
This patch addresses the bug, by applying the buffer data expansion by
the generic snd_seq_dump_var_event() helper function.
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Reported-by: Mark Salyzyn <salyzyn(a)android.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/seq/oss/seq_oss_midi.c | 4 +---
sound/core/seq/oss/seq_oss_readq.c | 29 +++++++++++++++++++++++++++++
sound/core/seq/oss/seq_oss_readq.h | 2 ++
3 files changed, 32 insertions(+), 3 deletions(-)
--- a/sound/core/seq/oss/seq_oss_midi.c
+++ b/sound/core/seq/oss/seq_oss_midi.c
@@ -615,9 +615,7 @@ send_midi_event(struct seq_oss_devinfo *
if (!dp->timer->running)
len = snd_seq_oss_timer_start(dp->timer);
if (ev->type == SNDRV_SEQ_EVENT_SYSEX) {
- if ((ev->flags & SNDRV_SEQ_EVENT_LENGTH_MASK) == SNDRV_SEQ_EVENT_LENGTH_VARIABLE)
- snd_seq_oss_readq_puts(dp->readq, mdev->seq_device,
- ev->data.ext.ptr, ev->data.ext.len);
+ snd_seq_oss_readq_sysex(dp->readq, mdev->seq_device, ev);
} else {
len = snd_midi_event_decode(mdev->coder, msg, sizeof(msg), ev);
if (len > 0)
--- a/sound/core/seq/oss/seq_oss_readq.c
+++ b/sound/core/seq/oss/seq_oss_readq.c
@@ -120,6 +120,35 @@ snd_seq_oss_readq_puts(struct seq_oss_re
}
/*
+ * put MIDI sysex bytes; the event buffer may be chained, thus it has
+ * to be expanded via snd_seq_dump_var_event().
+ */
+struct readq_sysex_ctx {
+ struct seq_oss_readq *readq;
+ int dev;
+};
+
+static int readq_dump_sysex(void *ptr, void *buf, int count)
+{
+ struct readq_sysex_ctx *ctx = ptr;
+
+ return snd_seq_oss_readq_puts(ctx->readq, ctx->dev, buf, count);
+}
+
+int snd_seq_oss_readq_sysex(struct seq_oss_readq *q, int dev,
+ struct snd_seq_event *ev)
+{
+ struct readq_sysex_ctx ctx = {
+ .readq = q,
+ .dev = dev
+ };
+
+ if ((ev->flags & SNDRV_SEQ_EVENT_LENGTH_MASK) != SNDRV_SEQ_EVENT_LENGTH_VARIABLE)
+ return 0;
+ return snd_seq_dump_var_event(ev, readq_dump_sysex, &ctx);
+}
+
+/*
* copy an event to input queue:
* return zero if enqueued
*/
--- a/sound/core/seq/oss/seq_oss_readq.h
+++ b/sound/core/seq/oss/seq_oss_readq.h
@@ -44,6 +44,8 @@ void snd_seq_oss_readq_delete(struct seq
void snd_seq_oss_readq_clear(struct seq_oss_readq *readq);
unsigned int snd_seq_oss_readq_poll(struct seq_oss_readq *readq, struct file *file, poll_table *wait);
int snd_seq_oss_readq_puts(struct seq_oss_readq *readq, int dev, unsigned char *data, int len);
+int snd_seq_oss_readq_sysex(struct seq_oss_readq *q, int dev,
+ struct snd_seq_event *ev);
int snd_seq_oss_readq_put_event(struct seq_oss_readq *readq, union evrec *ev);
int snd_seq_oss_readq_put_timestamp(struct seq_oss_readq *readq, unsigned long curt, int seq_mode);
int snd_seq_oss_readq_pick(struct seq_oss_readq *q, union evrec *rec);
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-3.18/alsa-seq-avoid-invalid-lockdep-class-warning.patch
queue-3.18/alsa-seq-fix-oss-sysex-delivery-in-oss-emulation.patch
This is a note to let you know that I've just added the patch titled
ALSA: seq: Avoid invalid lockdep class warning
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:
alsa-seq-avoid-invalid-lockdep-class-warning.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 3510c7aa069aa83a2de6dab2b41401a198317bdc Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Mon, 6 Nov 2017 20:16:50 +0100
Subject: ALSA: seq: Avoid invalid lockdep class warning
From: Takashi Iwai <tiwai(a)suse.de>
commit 3510c7aa069aa83a2de6dab2b41401a198317bdc upstream.
The recent fix for adding rwsem nesting annotation was using the given
"hop" argument as the lock subclass key. Although the idea itself
works, it may trigger a kernel warning like:
BUG: looking up invalid subclass: 8
....
since the lockdep has a smaller number of subclasses (8) than we
currently allow for the hops there (10).
The current definition is merely a sanity check for avoiding the too
deep delivery paths, and the 8 hops are already enough. So, as a
quick fix, just follow the max hops as same as the max lockdep
subclasses.
Fixes: 1f20f9ff57ca ("ALSA: seq: Fix nested rwsem annotation for lockdep splat")
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/sound/seq_kernel.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/include/sound/seq_kernel.h
+++ b/include/sound/seq_kernel.h
@@ -55,7 +55,8 @@ typedef union snd_seq_timestamp snd_seq_
#define SNDRV_SEQ_DEFAULT_CLIENT_EVENTS 200
/* max delivery path length */
-#define SNDRV_SEQ_MAX_HOPS 10
+/* NOTE: this shouldn't be greater than MAX_LOCKDEP_SUBCLASSES */
+#define SNDRV_SEQ_MAX_HOPS 8
/* max size of event size */
#define SNDRV_SEQ_MAX_EVENT_LEN 0x3fffffff
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-3.18/alsa-seq-avoid-invalid-lockdep-class-warning.patch
queue-3.18/alsa-seq-fix-oss-sysex-delivery-in-oss-emulation.patch
On Mon, Nov 06, 2017 at 09:15:14PM +0000, James Hogan wrote:
> From: Matt Redfearn <matt.redfearn(a)imgtec.com>
>
> commit 9e8c399a88f0b87e41a894911475ed2a8f8dff9e upstream.
>
> Commit 6f542ebeaee0 ("MIPS: Fix race on setting and getting
> cpu_online_mask") effectively reverted commit 8f46cca1e6c06 ("MIPS: SMP:
> Fix possibility of deadlock when bringing CPUs online") and thus has
> reinstated the possibility of deadlock.
>
> The commit was based on testing of kernel v4.4, where the CPU hotplug
> core code issued a BUG() if the starting CPU is not marked online when
> the boot CPU returns from __cpu_up. The commit fixes this race (in
> v4.4), but re-introduces the deadlock situation.
>
> As noted in the commit message, upstream differs in this area. Commit
> 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up")
> adds a completion event in the CPU hotplug core code, making this race
> impossible. However, people were unhappy with relying on the core code
> to do the right thing.
>
> To address the issues both commits were trying to fix, add a second
> completion event in the MIPS smp hotplug path. It removes the
> possibility of a race, since the MIPS smp hotplug code now synchronises
> both the boot and secondary CPUs before they return to the hotplug core
> code. It also addresses the deadlock by ensuring that the secondary CPU
> is not marked online before it's counters are synchronised.
>
> This fix should also be backported to fix the race condition introduced
> by the backport of commit 8f46cca1e6c06 ("MIPS: SMP: Fix possibility of
> deadlock when bringing CPUs online"), through really that race only
> existed before commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu
> bring itself fully up").
>
> Signed-off-by: Matt Redfearn <matt.redfearn(a)imgtec.com>
> Fixes: 6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask")
> CC: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext(a)nokia.com>
> Cc: <stable(a)vger.kernel.org> # v4.1+: 8f46cca1e6c0: "MIPS: SMP: Fix possibility of deadlock when bringing CPUs online"
> Cc: <stable(a)vger.kernel.org> # v4.1+: a00eeede507c: "MIPS: SMP: Use a completion event to signal CPU up"
> Cc: <stable(a)vger.kernel.org> # v4.1+: 6f542ebeaee0: "MIPS: Fix race on setting and getting cpu_online_mask"
These did not apply to 3.18, so this patch overall did not apply there
either.
I don't know if you care about 3.18, but if so, can you provide
backports of these for that tree, and then resend this patch so I can
queue it up?
thanks,
greg k-h
On Mon, Nov 06, 2017 at 12:11:36PM +0200, Mika Westerberg wrote:
> Hi,
>
> Currently there is an issue in v4.13 where booting system with
> Thunderbolt device connected causes problems. Typically the device will
> not be tunneled properly and will not function as expected.
>
> The issue has been root caused to the way Linux initializes and handles
> ACPI GPEs (General Purpose Events). In summary we enable them too late
> and that results the PCI core finds upstream PCIe port of the
> Thunderbolt host controller too early (it is not fully configured by the
> BIOS SMI handler yet).
>
> This has been fixed in mainline starting from v4.14-rc1 by the following
> commits:
>
> ecc1165b8b74 ("ACPICA: Dispatch active GPEs at init time")
> 1312b7e0caca ("ACPICA: Make it possible to enable runtime GPEs earlier")
> eb7f43c4adb4 ("ACPI / scan: Enable GPEs before scanning the namespace")
>
> In order to get Thunderbolt working even when there is a device
> connected during boot, can the above 3 commits be included in stable for
> v4.13?
Now all queued up, thanks.
greg k-h