From: Josef Bacik <jbacik(a)fb.com>
I messed up changing the size of an NBD device while it was connected by
not actually updating the device or doing the uevent. Fix this by
updating everything if we're connected and we change the size.
cc: stable(a)vger.kernel.org
Fixes: 639812a ("nbd: don't set the device size until we're connected")
Signed-off-by: Josef Bacik <jbacik(a)fb.com>
---
drivers/block/nbd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 86258b00a1d4..7106b98a35fb 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -243,6 +243,8 @@ static void nbd_size_set(struct nbd_device *nbd, loff_t blocksize,
struct nbd_config *config = nbd->config;
config->blksize = blocksize;
config->bytesize = blocksize * nr_blocks;
+ if (nbd->task_recv != NULL)
+ nbd_size_update(nbd);
}
static void nbd_complete_rq(struct request *req)
--
2.14.3
This is a note to let you know that I've just added the patch titled
x86/spectre_v2: Don't check microcode versions when running under hypervisors
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:
x86-spectre_v2-don-t-check-microcode-versions-when-running-under-hypervisors.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 36268223c1e9981d6cfc33aff8520b3bde4b8114 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Date: Mon, 26 Feb 2018 09:35:01 -0500
Subject: x86/spectre_v2: Don't check microcode versions when running under hypervisors
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
commit 36268223c1e9981d6cfc33aff8520b3bde4b8114 upstream.
As:
1) It's known that hypervisors lie about the environment anyhow (host
mismatch)
2) Even if the hypervisor (Xen, KVM, VMWare, etc) provided a valid
"correct" value, it all gets to be very murky when migration happens
(do you provide the "new" microcode of the machine?).
And in reality the cloud vendors are the ones that should make sure that
the microcode that is running is correct and we should just sing lalalala
and trust them.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Wanpeng Li <kernellwp(a)gmail.com>
Cc: kvm <kvm(a)vger.kernel.org>
Cc: Krčmář <rkrcmar(a)redhat.com>
Cc: Borislav Petkov <bp(a)alien8.de>
CC: "H. Peter Anvin" <hpa(a)zytor.com>
CC: stable(a)vger.kernel.org
Link: https://lkml.kernel.org/r/20180226213019.GE9497@char.us.oracle.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/intel.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -103,6 +103,13 @@ static bool bad_spectre_microcode(struct
{
int i;
+ /*
+ * We know that the hypervisor lie to us on the microcode version so
+ * we may as well hope that it is running the correct version.
+ */
+ if (cpu_has(c, X86_FEATURE_HYPERVISOR))
+ return false;
+
for (i = 0; i < ARRAY_SIZE(spectre_bad_microcodes); i++) {
if (c->x86_model == spectre_bad_microcodes[i].model &&
c->x86_stepping == spectre_bad_microcodes[i].stepping)
Patches currently in stable-queue which might be from konrad.wilk(a)oracle.com are
queue-4.9/x86-spectre_v2-don-t-check-microcode-versions-when-running-under-hypervisors.patch
This is a note to let you know that I've just added the patch titled
x86/MCE: Serialize sysfs 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:
x86-mce-serialize-sysfs-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 b3b7c4795ccab5be71f080774c45bbbcc75c2aaf Mon Sep 17 00:00:00 2001
From: Seunghun Han <kkamagui(a)gmail.com>
Date: Tue, 6 Mar 2018 15:21:43 +0100
Subject: x86/MCE: Serialize sysfs changes
From: Seunghun Han <kkamagui(a)gmail.com>
commit b3b7c4795ccab5be71f080774c45bbbcc75c2aaf upstream.
The check_interval file in
/sys/devices/system/machinecheck/machinecheck<cpu number>
directory is a global timer value for MCE polling. If it is changed by one
CPU, mce_restart() broadcasts the event to other CPUs to delete and restart
the MCE polling timer and __mcheck_cpu_init_timer() reinitializes the
mce_timer variable.
If more than one CPU writes a specific value to the check_interval file
concurrently, mce_timer is not protected from such concurrent accesses and
all kinds of explosions happen. Since only root can write to those sysfs
variables, the issue is not a big deal security-wise.
However, concurrent writes to these configuration variables is void of
reason so the proper thing to do is to serialize the access with a mutex.
Boris:
- Make store_int_with_restart() use device_store_ulong() to filter out
negative intervals
- Limit min interval to 1 second
- Correct locking
- Massage commit message
Signed-off-by: Seunghun Han <kkamagui(a)gmail.com>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Tony Luck <tony.luck(a)intel.com>
Cc: linux-edac <linux-edac(a)vger.kernel.org>
Cc: stable(a)vger.kernel.org
Link: http://lkml.kernel.org/r/20180302202706.9434-1-kkamagui@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/mcheck/mce.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -61,6 +61,9 @@ static DEFINE_MUTEX(mce_chrdev_read_mute
smp_load_acquire(&(p)); \
})
+/* sysfs synchronization */
+static DEFINE_MUTEX(mce_sysfs_mutex);
+
#define CREATE_TRACE_POINTS
#include <trace/events/mce.h>
@@ -2308,6 +2311,7 @@ static ssize_t set_ignore_ce(struct devi
if (kstrtou64(buf, 0, &new) < 0)
return -EINVAL;
+ mutex_lock(&mce_sysfs_mutex);
if (mca_cfg.ignore_ce ^ !!new) {
if (new) {
/* disable ce features */
@@ -2320,6 +2324,8 @@ static ssize_t set_ignore_ce(struct devi
on_each_cpu(mce_enable_ce, (void *)1, 1);
}
}
+ mutex_unlock(&mce_sysfs_mutex);
+
return size;
}
@@ -2332,6 +2338,7 @@ static ssize_t set_cmci_disabled(struct
if (kstrtou64(buf, 0, &new) < 0)
return -EINVAL;
+ mutex_lock(&mce_sysfs_mutex);
if (mca_cfg.cmci_disabled ^ !!new) {
if (new) {
/* disable cmci */
@@ -2343,6 +2350,8 @@ static ssize_t set_cmci_disabled(struct
on_each_cpu(mce_enable_ce, NULL, 1);
}
}
+ mutex_unlock(&mce_sysfs_mutex);
+
return size;
}
@@ -2350,8 +2359,19 @@ static ssize_t store_int_with_restart(st
struct device_attribute *attr,
const char *buf, size_t size)
{
- ssize_t ret = device_store_int(s, attr, buf, size);
+ unsigned long old_check_interval = check_interval;
+ ssize_t ret = device_store_ulong(s, attr, buf, size);
+
+ if (check_interval == old_check_interval)
+ return ret;
+
+ if (check_interval < 1)
+ check_interval = 1;
+
+ mutex_lock(&mce_sysfs_mutex);
mce_restart();
+ mutex_unlock(&mce_sysfs_mutex);
+
return ret;
}
Patches currently in stable-queue which might be from kkamagui(a)gmail.com are
queue-4.9/x86-mce-serialize-sysfs-changes.patch
This is a note to let you know that I've just added the patch titled
workqueue: Allow retrieval of current task's work struct
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:
workqueue-allow-retrieval-of-current-task-s-work-struct.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 27d4ee03078aba88c5e07dcc4917e8d01d046f38 Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Sun, 11 Feb 2018 10:38:28 +0100
Subject: workqueue: Allow retrieval of current task's work struct
From: Lukas Wunner <lukas(a)wunner.de>
commit 27d4ee03078aba88c5e07dcc4917e8d01d046f38 upstream.
Introduce a helper to retrieve the current task's work struct if it is
a workqueue worker.
This allows us to fix a long-standing deadlock in several DRM drivers
wherein the ->runtime_suspend callback waits for a specific worker to
finish and that worker in turn calls a function which waits for runtime
suspend to finish. That function is invoked from multiple call sites
and waiting for runtime suspend to finish is the correct thing to do
except if it's executing in the context of the worker.
Cc: Lai Jiangshan <jiangshanlai(a)gmail.com>
Cc: Dave Airlie <airlied(a)redhat.com>
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Cc: Alex Deucher <alexander.deucher(a)amd.com>
Acked-by: Tejun Heo <tj(a)kernel.org>
Reviewed-by: Lyude Paul <lyude(a)redhat.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/2d8f603074131eb87e588d2b803a7…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/workqueue.h | 1 +
kernel/workqueue.c | 16 ++++++++++++++++
2 files changed, 17 insertions(+)
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -453,6 +453,7 @@ extern bool cancel_delayed_work_sync(str
extern void workqueue_set_max_active(struct workqueue_struct *wq,
int max_active);
+extern struct work_struct *current_work(void);
extern bool current_is_workqueue_rescuer(void);
extern bool workqueue_congested(int cpu, struct workqueue_struct *wq);
extern unsigned int work_busy(struct work_struct *work);
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -4130,6 +4130,22 @@ void workqueue_set_max_active(struct wor
EXPORT_SYMBOL_GPL(workqueue_set_max_active);
/**
+ * current_work - retrieve %current task's work struct
+ *
+ * Determine if %current task is a workqueue worker and what it's working on.
+ * Useful to find out the context that the %current task is running in.
+ *
+ * Return: work struct if %current task is a workqueue worker, %NULL otherwise.
+ */
+struct work_struct *current_work(void)
+{
+ struct worker *worker = current_wq_worker();
+
+ return worker ? worker->current_work : NULL;
+}
+EXPORT_SYMBOL(current_work);
+
+/**
* current_is_workqueue_rescuer - is %current workqueue rescuer?
*
* Determine whether %current is a workqueue rescuer. Can be used from
Patches currently in stable-queue which might be from lukas(a)wunner.de are
queue-4.9/workqueue-allow-retrieval-of-current-task-s-work-struct.patch
queue-4.9/drm-radeon-fix-deadlock-on-runtime-suspend.patch
queue-4.9/drm-amdgpu-fix-deadlock-on-runtime-suspend.patch
queue-4.9/drm-allow-determining-if-current-task-is-output-poll-worker.patch
queue-4.9/drm-nouveau-fix-deadlock-on-runtime-suspend.patch
This is a note to let you know that I've just added the patch titled
virtio_ring: fix num_free handling in error case
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:
virtio_ring-fix-num_free-handling-in-error-case.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 e82df670235138575b37ff0ec24412a471efd97f Mon Sep 17 00:00:00 2001
From: Tiwei Bie <tiwei.bie(a)intel.com>
Date: Fri, 23 Feb 2018 19:41:30 +0800
Subject: virtio_ring: fix num_free handling in error case
From: Tiwei Bie <tiwei.bie(a)intel.com>
commit e82df670235138575b37ff0ec24412a471efd97f upstream.
The vq->vq.num_free hasn't been changed when error happens,
so it shouldn't be changed when handling the error.
Fixes: 780bc7903a32 ("virtio_ring: Support DMA APIs")
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Michael S. Tsirkin <mst(a)redhat.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Tiwei Bie <tiwei.bie(a)intel.com>
Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/virtio/virtio_ring.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -423,8 +423,6 @@ unmap_release:
i = vq->vring.desc[i].next;
}
- vq->vq.num_free += total_sg;
-
if (indirect)
kfree(desc);
Patches currently in stable-queue which might be from tiwei.bie(a)intel.com are
queue-4.9/virtio_ring-fix-num_free-handling-in-error-case.patch
This is a note to let you know that I've just added the patch titled
scsi: qla2xxx: Fix NULL pointer crash due to active timer for ABTS
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:
scsi-qla2xxx-fix-null-pointer-crash-due-to-active-timer-for-abts.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 1514839b366417934e2f1328edb50ed1e8a719f5 Mon Sep 17 00:00:00 2001
From: "himanshu.madhani(a)cavium.com" <himanshu.madhani(a)cavium.com>
Date: Mon, 12 Feb 2018 10:28:14 -0800
Subject: scsi: qla2xxx: Fix NULL pointer crash due to active timer for ABTS
From: himanshu.madhani(a)cavium.com <himanshu.madhani(a)cavium.com>
commit 1514839b366417934e2f1328edb50ed1e8a719f5 upstream.
This patch fixes NULL pointer crash due to active timer running for abort
IOCB.
>From crash dump analysis it was discoverd that get_next_timer_interrupt()
encountered a corrupted entry on the timer list.
#9 [ffff95e1f6f0fd40] page_fault at ffffffff914fe8f8
[exception RIP: get_next_timer_interrupt+440]
RIP: ffffffff90ea3088 RSP: ffff95e1f6f0fdf0 RFLAGS: 00010013
RAX: ffff95e1f6451028 RBX: 000218e2389e5f40 RCX: 00000001232ad600
RDX: 0000000000000001 RSI: ffff95e1f6f0fdf0 RDI: 0000000001232ad6
RBP: ffff95e1f6f0fe40 R8: ffff95e1f6451188 R9: 0000000000000001
R10: 0000000000000016 R11: 0000000000000016 R12: 00000001232ad5f6
R13: ffff95e1f6450000 R14: ffff95e1f6f0fdf8 R15: ffff95e1f6f0fe10
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
Looking at the assembly of get_next_timer_interrupt(), address came
from %r8 (ffff95e1f6451188) which is pointing to list_head with single
entry at ffff95e5ff621178.
0xffffffff90ea307a <get_next_timer_interrupt+426>: mov (%r8),%rdx
0xffffffff90ea307d <get_next_timer_interrupt+429>: cmp %r8,%rdx
0xffffffff90ea3080 <get_next_timer_interrupt+432>: je 0xffffffff90ea30a7 <get_next_timer_interrupt+471>
0xffffffff90ea3082 <get_next_timer_interrupt+434>: nopw 0x0(%rax,%rax,1)
0xffffffff90ea3088 <get_next_timer_interrupt+440>: testb $0x1,0x18(%rdx)
crash> rd ffff95e1f6451188 10
ffff95e1f6451188: ffff95e5ff621178 ffff95e5ff621178 x.b.....x.b.....
ffff95e1f6451198: ffff95e1f6451198 ffff95e1f6451198 ..E.......E.....
ffff95e1f64511a8: ffff95e1f64511a8 ffff95e1f64511a8 ..E.......E.....
ffff95e1f64511b8: ffff95e77cf509a0 ffff95e77cf509a0 ...|.......|....
ffff95e1f64511c8: ffff95e1f64511c8 ffff95e1f64511c8 ..E.......E.....
crash> rd ffff95e5ff621178 10
ffff95e5ff621178: 0000000000000001 ffff95e15936aa00 ..........6Y....
ffff95e5ff621188: 0000000000000000 00000000ffffffff ................
ffff95e5ff621198: 00000000000000a0 0000000000000010 ................
ffff95e5ff6211a8: ffff95e5ff621198 000000000000000c ..b.............
ffff95e5ff6211b8: 00000f5800000000 ffff95e751f8d720 ....X... ..Q....
ffff95e5ff621178 belongs to freed mempool object at ffff95e5ff621080.
CACHE NAME OBJSIZE ALLOCATED TOTAL SLABS SSIZE
ffff95dc7fd74d00 mnt_cache 384 19785 24948 594 16k
SLAB MEMORY NODE TOTAL ALLOCATED FREE
ffffdc5dabfd8800 ffff95e5ff620000 1 42 29 13
FREE / [ALLOCATED]
ffff95e5ff621080 (cpu 6 cache)
Examining the contents of that memory reveals a pointer to a constant string
in the driver, "abort\0", which is set by qla24xx_async_abort_cmd().
crash> rd ffffffffc059277c 20
ffffffffc059277c: 6e490074726f6261 0074707572726574 abort.Interrupt.
ffffffffc059278c: 00676e696c6c6f50 6920726576697244 Polling.Driver i
ffffffffc059279c: 646f6d207325206e 6974736554000a65 n %s mode..Testi
ffffffffc05927ac: 636976656420676e 786c252074612065 ng device at %lx
ffffffffc05927bc: 6b63656843000a2e 646f727020676e69 ...Checking prod
ffffffffc05927cc: 6f20444920746375 0a2e706968632066 uct ID of chip..
ffffffffc05927dc: 5120646e756f4600 204130303232414c .Found QLA2200A
ffffffffc05927ec: 43000a2e70696843 20676e696b636568 Chip...Checking
ffffffffc05927fc: 65786f626c69616d 6c636e69000a2e73 mailboxes...incl
ffffffffc059280c: 756e696c2f656475 616d2d616d642f78 ude/linux/dma-ma
crash> struct -ox srb_iocb
struct srb_iocb {
union {
struct {...} logio;
struct {...} els_logo;
struct {...} tmf;
struct {...} fxiocb;
struct {...} abt;
struct ct_arg ctarg;
struct {...} mbx;
struct {...} nack;
[0x0 ] } u;
[0xb8] struct timer_list timer;
[0x108] void (*timeout)(void *);
}
SIZE: 0x110
crash> ! bc
ibase=16
obase=10
B8+40
F8
The object is a srb_t, and at offset 0xf8 within that structure
(i.e. ffff95e5ff621080 + f8 -> ffff95e5ff621178) is a struct timer_list.
Cc: <stable(a)vger.kernel.org> #4.4+
Fixes: 4440e46d5db7 ("[SCSI] qla2xxx: Add IOCB Abort command asynchronous handling.")
Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Reviewed-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/qla2xxx/qla_init.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -369,6 +369,7 @@ qla24xx_abort_sp_done(void *data, void *
srb_t *sp = (srb_t *)ptr;
struct srb_iocb *abt = &sp->u.iocb_cmd;
+ del_timer(&sp->u.iocb_cmd.timer);
complete(&abt->u.abt.comp);
}
Patches currently in stable-queue which might be from himanshu.madhani(a)cavium.com are
queue-4.9/scsi-qla2xxx-fix-null-pointer-crash-due-to-active-timer-for-abts.patch
This is a note to let you know that I've just added the patch titled
perf tools: Fix trigger class trigger_on()
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:
perf-tools-fix-trigger-class-trigger_on.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 de19e5c3c51fdb1ff20d0f61d099db902ff7494b Mon Sep 17 00:00:00 2001
From: Adrian Hunter <adrian.hunter(a)intel.com>
Date: Wed, 28 Feb 2018 10:39:04 +0200
Subject: perf tools: Fix trigger class trigger_on()
From: Adrian Hunter <adrian.hunter(a)intel.com>
commit de19e5c3c51fdb1ff20d0f61d099db902ff7494b upstream.
trigger_on() means that the trigger is available but not ready, however
trigger_on() was making it ready. That can segfault if the signal comes
before trigger_ready(). e.g. (USR2 signal delivery not shown)
$ perf record -e intel_pt//u -S sleep 1
perf: Segmentation fault
Obtained 16 stack frames.
/home/ahunter/bin/perf(sighandler_dump_stack+0x40) [0x4ec550]
/lib/x86_64-linux-gnu/libc.so.6(+0x36caf) [0x7fa76411acaf]
/home/ahunter/bin/perf(perf_evsel__disable+0x26) [0x4b9dd6]
/home/ahunter/bin/perf() [0x43a45b]
/lib/x86_64-linux-gnu/libc.so.6(+0x36caf) [0x7fa76411acaf]
/lib/x86_64-linux-gnu/libc.so.6(__xstat64+0x15) [0x7fa7641d2cc5]
/home/ahunter/bin/perf() [0x4ec6c9]
/home/ahunter/bin/perf() [0x4ec73b]
/home/ahunter/bin/perf() [0x4ec73b]
/home/ahunter/bin/perf() [0x4ec73b]
/home/ahunter/bin/perf() [0x4eca15]
/home/ahunter/bin/perf(machine__create_kernel_maps+0x257) [0x4f0b77]
/home/ahunter/bin/perf(perf_session__new+0xc0) [0x4f86f0]
/home/ahunter/bin/perf(cmd_record+0x722) [0x43c132]
/home/ahunter/bin/perf() [0x4a11ae]
/home/ahunter/bin/perf(main+0x5d4) [0x427fb4]
Note, for testing purposes, this is hard to hit unless you add some sleep()
in builtin-record.c before record__open().
Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com>
Acked-by: Jiri Olsa <jolsa(a)kernel.org>
Cc: Wang Nan <wangnan0(a)huawei.com>
Cc: stable(a)vger.kernel.org
Fixes: 3dcc4436fa6f ("perf tools: Introduce trigger class")
Link: http://lkml.kernel.org/r/1519807144-30694-1-git-send-email-adrian.hunter@in…
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/util/trigger.h | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/tools/perf/util/trigger.h
+++ b/tools/perf/util/trigger.h
@@ -11,7 +11,7 @@
* States and transits:
*
*
- * OFF--(on)--> READY --(hit)--> HIT
+ * OFF--> ON --> READY --(hit)--> HIT
* ^ |
* | (ready)
* | |
@@ -26,8 +26,9 @@ struct trigger {
volatile enum {
TRIGGER_ERROR = -2,
TRIGGER_OFF = -1,
- TRIGGER_READY = 0,
- TRIGGER_HIT = 1,
+ TRIGGER_ON = 0,
+ TRIGGER_READY = 1,
+ TRIGGER_HIT = 2,
} state;
const char *name;
};
@@ -49,7 +50,7 @@ static inline bool trigger_is_error(stru
static inline void trigger_on(struct trigger *t)
{
TRIGGER_WARN_ONCE(t, TRIGGER_OFF);
- t->state = TRIGGER_READY;
+ t->state = TRIGGER_ON;
}
static inline void trigger_ready(struct trigger *t)
Patches currently in stable-queue which might be from adrian.hunter(a)intel.com are
queue-4.9/perf-tools-fix-trigger-class-trigger_on.patch
This is a note to let you know that I've just added the patch titled
MIPS: OCTEON: irq: Check for null return on kzalloc allocation
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:
mips-octeon-irq-check-for-null-return-on-kzalloc-allocation.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 902f4d067a50ccf645a58dd5fb1d113b6e0f9b5b Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king(a)canonical.com>
Date: Thu, 22 Feb 2018 18:08:53 +0000
Subject: MIPS: OCTEON: irq: Check for null return on kzalloc allocation
From: Colin Ian King <colin.king(a)canonical.com>
commit 902f4d067a50ccf645a58dd5fb1d113b6e0f9b5b upstream.
The allocation of host_data is not null checked, leading to a null
pointer dereference if the allocation fails. Fix this by adding a null
check and return with -ENOMEM.
Fixes: 64b139f97c01 ("MIPS: OCTEON: irq: add CIB and other fixes")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Acked-by: David Daney <david.daney(a)cavium.com>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: "Steven J. Hill" <Steven.Hill(a)cavium.com>
Cc: linux-mips(a)linux-mips.org
Cc: <stable(a)vger.kernel.org> # 4.0+
Patchwork: https://patchwork.linux-mips.org/patch/18658/
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/cavium-octeon/octeon-irq.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/mips/cavium-octeon/octeon-irq.c
+++ b/arch/mips/cavium-octeon/octeon-irq.c
@@ -2277,6 +2277,8 @@ static int __init octeon_irq_init_cib(st
}
host_data = kzalloc(sizeof(*host_data), GFP_KERNEL);
+ if (!host_data)
+ return -ENOMEM;
raw_spin_lock_init(&host_data->lock);
addr = of_get_address(ciu_node, 0, NULL, NULL);
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.9/mips-ath25-check-for-kzalloc-allocation-failure.patch
queue-4.9/mips-octeon-irq-check-for-null-return-on-kzalloc-allocation.patch
This is a note to let you know that I've just added the patch titled
MIPS: BMIPS: Do not mask IPIs during 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:
mips-bmips-do-not-mask-ipis-during-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 06a3f0c9f2725f5d7c63c4203839373c9bd00c28 Mon Sep 17 00:00:00 2001
From: Justin Chen <justinpopo6(a)gmail.com>
Date: Wed, 27 Sep 2017 17:15:15 -0700
Subject: MIPS: BMIPS: Do not mask IPIs during suspend
From: Justin Chen <justinpopo6(a)gmail.com>
commit 06a3f0c9f2725f5d7c63c4203839373c9bd00c28 upstream.
Commit a3e6c1eff548 ("MIPS: IRQ: Fix disable_irq on CPU IRQs") fixes an
issue where disable_irq did not actually disable the irq. The bug caused
our IPIs to not be disabled, which actually is the correct behavior.
With the addition of commit a3e6c1eff548 ("MIPS: IRQ: Fix disable_irq on
CPU IRQs"), the IPIs were getting disabled going into suspend, thus
schedule_ipi() was not being called. This caused deadlocks where
schedulable task were not being scheduled and other cpus were waiting
for them to do something.
Add the IRQF_NO_SUSPEND flag so an irq_disable will not be called on the
IPIs during suspend.
Signed-off-by: Justin Chen <justinpopo6(a)gmail.com>
Fixes: a3e6c1eff548 ("MIPS: IRQ: Fix disabled_irq on CPU IRQs")
Cc: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: linux-mips(a)linux-mips.org
Cc: stable(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17385/
[jhogan(a)kernel.org: checkpatch: wrap long lines and fix commit refs]
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/smp-bmips.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -166,11 +166,11 @@ static void bmips_prepare_cpus(unsigned
return;
}
- if (request_irq(IPI0_IRQ, bmips_ipi_interrupt, IRQF_PERCPU,
- "smp_ipi0", NULL))
+ if (request_irq(IPI0_IRQ, bmips_ipi_interrupt,
+ IRQF_PERCPU | IRQF_NO_SUSPEND, "smp_ipi0", NULL))
panic("Can't request IPI0 interrupt");
- if (request_irq(IPI1_IRQ, bmips_ipi_interrupt, IRQF_PERCPU,
- "smp_ipi1", NULL))
+ if (request_irq(IPI1_IRQ, bmips_ipi_interrupt,
+ IRQF_PERCPU | IRQF_NO_SUSPEND, "smp_ipi1", NULL))
panic("Can't request IPI1 interrupt");
}
Patches currently in stable-queue which might be from justinpopo6(a)gmail.com are
queue-4.9/mips-bmips-do-not-mask-ipis-during-suspend.patch
This is a note to let you know that I've just added the patch titled
MIPS: ath25: Check for kzalloc 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:
mips-ath25-check-for-kzalloc-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 1b22b4b28fd5fbc51855219e3238b3ab81da8466 Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king(a)canonical.com>
Date: Thu, 22 Feb 2018 17:50:12 +0000
Subject: MIPS: ath25: Check for kzalloc allocation failure
From: Colin Ian King <colin.king(a)canonical.com>
commit 1b22b4b28fd5fbc51855219e3238b3ab81da8466 upstream.
Currently there is no null check on a failed allocation of board_data,
and hence a null pointer dereference will occurr. Fix this by checking
for the out of memory null pointer.
Fixes: a7473717483e ("MIPS: ath25: add board configuration detection")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: linux-mips(a)linux-mips.org
Cc: <stable(a)vger.kernel.org> # 3.19+
Patchwork: https://patchwork.linux-mips.org/patch/18657/
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/ath25/board.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/mips/ath25/board.c
+++ b/arch/mips/ath25/board.c
@@ -135,6 +135,8 @@ int __init ath25_find_config(phys_addr_t
}
board_data = kzalloc(BOARD_CONFIG_BUFSZ, GFP_KERNEL);
+ if (!board_data)
+ goto error;
ath25_board.config = (struct ath25_boarddata *)board_data;
memcpy_fromio(board_data, bcfg, 0x100);
if (broken_boarddata) {
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.9/mips-ath25-check-for-kzalloc-allocation-failure.patch
queue-4.9/mips-octeon-irq-check-for-null-return-on-kzalloc-allocation.patch
This is a note to let you know that I've just added the patch titled
loop: Fix lost writes caused by missing flag
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:
loop-fix-lost-writes-caused-by-missing-flag.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 1d037577c323e5090ce281e96bc313ab2eee5be2 Mon Sep 17 00:00:00 2001
From: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Date: Fri, 9 Mar 2018 08:36:36 -0700
Subject: loop: Fix lost writes caused by missing flag
From: Ross Zwisler <ross.zwisler(a)linux.intel.com>
commit 1d037577c323e5090ce281e96bc313ab2eee5be2 upstream.
The following commit:
commit aa4d86163e4e ("block: loop: switch to VFS ITER_BVEC")
replaced __do_lo_send_write(), which used ITER_KVEC iterators, with
lo_write_bvec() which uses ITER_BVEC iterators. In this change, though,
the WRITE flag was lost:
- iov_iter_kvec(&from, ITER_KVEC | WRITE, &kvec, 1, len);
+ iov_iter_bvec(&i, ITER_BVEC, bvec, 1, bvec->bv_len);
This flag is necessary for the DAX case because we make decisions based on
whether or not the iterator is a READ or a WRITE in dax_iomap_actor() and
in dax_iomap_rw().
We end up going through this path in configurations where we combine a PMEM
device with 4k sectors, a loopback device and DAX. The consequence of this
missed flag is that what we intend as a write actually turns into a read in
the DAX code, so no data is ever written.
The very simplest test case is to create a loopback device and try and
write a small string to it, then hexdump a few bytes of the device to see
if the write took. Without this patch you read back all zeros, with this
you read back the string you wrote.
For XFS this causes us to fail or panic during the following xfstests:
xfs/074 xfs/078 xfs/216 xfs/217 xfs/250
For ext4 we have a similar issue where writes never happen, but we don't
currently have any xfstests that use loopback and show this issue.
Fix this by restoring the WRITE flag argument to iov_iter_bvec(). This
causes the xfstests to all pass.
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: stable(a)vger.kernel.org
Fixes: commit aa4d86163e4e ("block: loop: switch to VFS ITER_BVEC")
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Reviewed-by: Ming Lei <ming.lei(a)redhat.com>
Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/loop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -263,7 +263,7 @@ static int lo_write_bvec(struct file *fi
struct iov_iter i;
ssize_t bw;
- iov_iter_bvec(&i, ITER_BVEC, bvec, 1, bvec->bv_len);
+ iov_iter_bvec(&i, ITER_BVEC | WRITE, bvec, 1, bvec->bv_len);
file_start_write(file);
bw = vfs_iter_write(file, &i, ppos);
Patches currently in stable-queue which might be from ross.zwisler(a)linux.intel.com are
queue-4.9/loop-fix-lost-writes-caused-by-missing-flag.patch
This is a note to let you know that I've just added the patch titled
KVM: s390: fix memory overwrites when not using SCA entries
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-s390-fix-memory-overwrites-when-not-using-sca-entries.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 f07afa0462b76a5b9c4f3a43d5ac24fdb86a90c2 Mon Sep 17 00:00:00 2001
From: David Hildenbrand <david(a)redhat.com>
Date: Tue, 6 Mar 2018 14:27:58 +0100
Subject: KVM: s390: fix memory overwrites when not using SCA entries
From: David Hildenbrand <david(a)redhat.com>
commit f07afa0462b76a5b9c4f3a43d5ac24fdb86a90c2 upstream.
Even if we don't have extended SCA support, we can have more than 64 CPUs
if we don't enable any HW features that might use the SCA entries.
Now, this works just fine, but we missed a return, which is why we
would actually store the SCA entries. If we have more than 64 CPUs, this
means writing outside of the basic SCA - bad.
Let's fix this. This allows > 64 CPUs when running nested (under vSIE)
without random crashes.
Fixes: a6940674c384 ("KVM: s390: allow 255 VCPUs when sca entries aren't used")
Reported-by: Christian Borntraeger <borntraeger(a)de.ibm.com>
Tested-by: Christian Borntraeger <borntraeger(a)de.ibm.com>
Signed-off-by: David Hildenbrand <david(a)redhat.com>
Message-Id: <20180306132758.21034-1-david(a)redhat.com>
Cc: stable(a)vger.kernel.org
Reviewed-by: Cornelia Huck <cohuck(a)redhat.com>
Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/s390/kvm/kvm-s390.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -1601,6 +1601,7 @@ static void sca_add_vcpu(struct kvm_vcpu
/* we still need the basic sca for the ipte control */
vcpu->arch.sie_block->scaoh = (__u32)(((__u64)sca) >> 32);
vcpu->arch.sie_block->scaol = (__u32)(__u64)sca;
+ return;
}
read_lock(&vcpu->kvm->arch.sca_lock);
if (vcpu->kvm->arch.use_esca) {
Patches currently in stable-queue which might be from david(a)redhat.com are
queue-4.9/kvm-s390-fix-memory-overwrites-when-not-using-sca-entries.patch
This is a note to let you know that I've just added the patch titled
kbuild: Handle builtin dtb file names containing hyphens
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:
kbuild-handle-builtin-dtb-file-names-containing-hyphens.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 55fe6da9efba102866e2fb5b40b04b6a4b26c19e Mon Sep 17 00:00:00 2001
From: James Hogan <jhogan(a)kernel.org>
Date: Thu, 8 Mar 2018 11:02:46 +0000
Subject: kbuild: Handle builtin dtb file names containing hyphens
From: James Hogan <jhogan(a)kernel.org>
commit 55fe6da9efba102866e2fb5b40b04b6a4b26c19e upstream.
cmd_dt_S_dtb constructs the assembly source to incorporate a devicetree
FDT (that is, the .dtb file) as binary data in the kernel image. This
assembly source contains labels before and after the binary data. The
label names incorporate the file name of the corresponding .dtb file.
Hyphens are not legal characters in labels, so .dtb files built into the
kernel with hyphens in the file name result in errors like the
following:
bcm3368-netgear-cvg834g.dtb.S: Assembler messages:
bcm3368-netgear-cvg834g.dtb.S:5: Error: : no such section
bcm3368-netgear-cvg834g.dtb.S:5: Error: junk at end of line, first unrecognized character is `-'
bcm3368-netgear-cvg834g.dtb.S:6: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_begin:'
bcm3368-netgear-cvg834g.dtb.S:8: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_end:'
bcm3368-netgear-cvg834g.dtb.S:9: Error: : no such section
bcm3368-netgear-cvg834g.dtb.S:9: Error: junk at end of line, first unrecognized character is `-'
Fix this by updating cmd_dt_S_dtb to transform all hyphens from the file
name to underscores when constructing the labels.
As of v4.16-rc2, 1139 .dts files across ARM64, ARM, MIPS and PowerPC
contain hyphens in their names, but the issue only currently manifests
on Broadcom MIPS platforms, as that is the only place where such files
are built into the kernel. For example when CONFIG_DT_NETGEAR_CVG834G=y,
or on BMIPS kernels when the dtbs target is used (in the latter case it
admittedly shouldn't really build all the dtb.o files, but thats a
separate issue).
Fixes: 695835511f96 ("MIPS: BMIPS: rename bcm96358nb4ser to bcm6358-neufbox4-sercom")
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Reviewed-by: Frank Rowand <frowand.list(a)gmail.com>
Cc: Rob Herring <robh+dt(a)kernel.org>
Cc: Michal Marek <michal.lkml(a)markovi.net>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: Kevin Cernekee <cernekee(a)gmail.com>
Cc: <stable(a)vger.kernel.org> # 4.9+
Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
scripts/Makefile.lib | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -290,11 +290,11 @@ cmd_dt_S_dtb= \
echo '\#include <asm-generic/vmlinux.lds.h>'; \
echo '.section .dtb.init.rodata,"a"'; \
echo '.balign STRUCT_ALIGNMENT'; \
- echo '.global __dtb_$(*F)_begin'; \
- echo '__dtb_$(*F)_begin:'; \
+ echo '.global __dtb_$(subst -,_,$(*F))_begin'; \
+ echo '__dtb_$(subst -,_,$(*F))_begin:'; \
echo '.incbin "$<" '; \
- echo '__dtb_$(*F)_end:'; \
- echo '.global __dtb_$(*F)_end'; \
+ echo '__dtb_$(subst -,_,$(*F))_end:'; \
+ echo '.global __dtb_$(subst -,_,$(*F))_end'; \
echo '.balign STRUCT_ALIGNMENT'; \
) > $@
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-4.9/mips-bmips-do-not-mask-ipis-during-suspend.patch
queue-4.9/mips-ath25-check-for-kzalloc-allocation-failure.patch
queue-4.9/kbuild-handle-builtin-dtb-file-names-containing-hyphens.patch
queue-4.9/mips-octeon-irq-check-for-null-return-on-kzalloc-allocation.patch
This is a note to let you know that I've just added the patch titled
Input: matrix_keypad - fix race when disabling interrupts
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:
input-matrix_keypad-fix-race-when-disabling-interrupts.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 ea4f7bd2aca9f68470e9aac0fc9432fd180b1fe7 Mon Sep 17 00:00:00 2001
From: Zhang Bo <zbsdta(a)126.com>
Date: Mon, 5 Feb 2018 14:56:21 -0800
Subject: Input: matrix_keypad - fix race when disabling interrupts
From: Zhang Bo <zbsdta(a)126.com>
commit ea4f7bd2aca9f68470e9aac0fc9432fd180b1fe7 upstream.
If matrix_keypad_stop() is executing and the keypad interrupt is triggered,
disable_row_irqs() may be called by both matrix_keypad_interrupt() and
matrix_keypad_stop() at the same time, causing interrupts to be disabled
twice and the keypad being "stuck" after resuming.
Take lock when setting keypad->stopped to ensure that ISR will not race
with matrix_keypad_stop() disabling interrupts.
Signed-off-by: Zhang Bo <zbsdta(a)126.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/keyboard/matrix_keypad.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/input/keyboard/matrix_keypad.c
+++ b/drivers/input/keyboard/matrix_keypad.c
@@ -216,8 +216,10 @@ static void matrix_keypad_stop(struct in
{
struct matrix_keypad *keypad = input_get_drvdata(dev);
+ spin_lock_irq(&keypad->lock);
keypad->stopped = true;
- mb();
+ spin_unlock_irq(&keypad->lock);
+
flush_work(&keypad->work.work);
/*
* matrix_keypad_scan() will leave IRQs enabled;
Patches currently in stable-queue which might be from zbsdta(a)126.com are
queue-4.9/input-matrix_keypad-fix-race-when-disabling-interrupts.patch
This is a note to let you know that I've just added the patch titled
IB/mlx5: Fix incorrect size of klms in the memory region
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-mlx5-fix-incorrect-size-of-klms-in-the-memory-region.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 da343b6d90e11132f1e917d865d88ee35d6e6d00 Mon Sep 17 00:00:00 2001
From: Sergey Gorenko <sergeygo(a)mellanox.com>
Date: Sun, 25 Feb 2018 13:39:48 +0200
Subject: IB/mlx5: Fix incorrect size of klms in the memory region
From: Sergey Gorenko <sergeygo(a)mellanox.com>
commit da343b6d90e11132f1e917d865d88ee35d6e6d00 upstream.
The value of mr->ndescs greater than mr->max_descs is set in the
function mlx5_ib_sg_to_klms() if sg_nents is greater than
mr->max_descs. This is an invalid value and it causes the
following error when registering mr:
mlx5_0:dump_cqe:276:(pid 193): dump error cqe
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 00 00 0f 00 78 06 25 00 00 8b 08 1e 8f d3
Cc: <stable(a)vger.kernel.org> # 4.5
Fixes: b005d3164713 ("mlx5: Add arbitrary sg list support")
Signed-off-by: Sergey Gorenko <sergeygo(a)mellanox.com>
Tested-by: Laurence Oberman <loberman(a)redhat.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx5/mr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1821,7 +1821,6 @@ mlx5_ib_sg_to_klms(struct mlx5_ib_mr *mr
mr->ibmr.iova = sg_dma_address(sg) + sg_offset;
mr->ibmr.length = 0;
- mr->ndescs = sg_nents;
for_each_sg(sgl, sg, sg_nents, i) {
if (unlikely(i >= mr->max_descs))
@@ -1833,6 +1832,7 @@ mlx5_ib_sg_to_klms(struct mlx5_ib_mr *mr
sg_offset = 0;
}
+ mr->ndescs = i;
if (sg_offset_p)
*sg_offset_p = sg_offset;
Patches currently in stable-queue which might be from sergeygo(a)mellanox.com are
queue-4.9/ib-mlx5-fix-incorrect-size-of-klms-in-the-memory-region.patch
This is a note to let you know that I've just added the patch titled
drm/radeon: Fix deadlock on runtime 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:
drm-radeon-fix-deadlock-on-runtime-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 15734feff2bdac24aa3266c437cffa42851990e3 Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Sun, 11 Feb 2018 10:38:28 +0100
Subject: drm/radeon: Fix deadlock on runtime suspend
From: Lukas Wunner <lukas(a)wunner.de>
commit 15734feff2bdac24aa3266c437cffa42851990e3 upstream.
radeon's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.
The output poll worker meanwhile calls pm_runtime_get_sync() in
radeon's ->detect hooks, which waits for the ongoing suspend to finish,
causing a deadlock.
Fix by not acquiring a runtime PM ref if the ->detect hooks are called
in the output poll worker's context. This is safe because the poll
worker is only enabled while runtime active and we know that
->runtime_suspend waits for it to finish.
Stack trace for posterity:
INFO: task kworker/0:3:31847 blocked for more than 120 seconds
Workqueue: events output_poll_execute [drm_kms_helper]
Call Trace:
schedule+0x3c/0x90
rpm_resume+0x1e2/0x690
__pm_runtime_resume+0x3f/0x60
radeon_lvds_detect+0x39/0xf0 [radeon]
output_poll_execute+0xda/0x1e0 [drm_kms_helper]
process_one_work+0x14b/0x440
worker_thread+0x48/0x4a0
INFO: task kworker/2:0:10493 blocked for more than 120 seconds.
Workqueue: pm pm_runtime_work
Call Trace:
schedule+0x3c/0x90
schedule_timeout+0x1b3/0x240
wait_for_common+0xc2/0x180
wait_for_completion+0x1d/0x20
flush_work+0xfc/0x1a0
__cancel_work_timer+0xa5/0x1d0
cancel_delayed_work_sync+0x13/0x20
drm_kms_helper_poll_disable+0x1f/0x30 [drm_kms_helper]
radeon_pmops_runtime_suspend+0x3d/0xa0 [radeon]
pci_pm_runtime_suspend+0x61/0x1a0
vga_switcheroo_runtime_suspend+0x21/0x70
__rpm_callback+0x32/0x70
rpm_callback+0x24/0x80
rpm_suspend+0x12b/0x640
pm_runtime_work+0x6f/0xb0
process_one_work+0x14b/0x440
worker_thread+0x48/0x4a0
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94147
Fixes: 10ebc0bc0934 ("drm/radeon: add runtime PM support (v2)")
Cc: stable(a)vger.kernel.org # v3.13+: 27d4ee03078a: workqueue: Allow retrieval of current task's work struct
Cc: stable(a)vger.kernel.org # v3.13+: 25c058ccaf2e: drm: Allow determining if current task is output poll worker
Cc: Ismo Toijala <ismo.toijala(a)gmail.com>
Cc: Alex Deucher <alexander.deucher(a)amd.com>
Cc: Dave Airlie <airlied(a)redhat.com>
Reviewed-by: Lyude Paul <lyude(a)redhat.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/64ea02c44f91dda19bc563902b97b…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_connectors.c | 74 +++++++++++++++++++----------
1 file changed, 49 insertions(+), 25 deletions(-)
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -897,9 +897,11 @@ radeon_lvds_detect(struct drm_connector
enum drm_connector_status ret = connector_status_disconnected;
int r;
- r = pm_runtime_get_sync(connector->dev->dev);
- if (r < 0)
- return connector_status_disconnected;
+ if (!drm_kms_helper_is_poll_worker()) {
+ r = pm_runtime_get_sync(connector->dev->dev);
+ if (r < 0)
+ return connector_status_disconnected;
+ }
if (encoder) {
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
@@ -922,8 +924,12 @@ radeon_lvds_detect(struct drm_connector
/* check acpi lid status ??? */
radeon_connector_update_scratch_regs(connector, ret);
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
+
return ret;
}
@@ -1037,9 +1043,11 @@ radeon_vga_detect(struct drm_connector *
enum drm_connector_status ret = connector_status_disconnected;
int r;
- r = pm_runtime_get_sync(connector->dev->dev);
- if (r < 0)
- return connector_status_disconnected;
+ if (!drm_kms_helper_is_poll_worker()) {
+ r = pm_runtime_get_sync(connector->dev->dev);
+ if (r < 0)
+ return connector_status_disconnected;
+ }
encoder = radeon_best_single_encoder(connector);
if (!encoder)
@@ -1106,8 +1114,10 @@ radeon_vga_detect(struct drm_connector *
radeon_connector_update_scratch_regs(connector, ret);
out:
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
return ret;
}
@@ -1171,9 +1181,11 @@ radeon_tv_detect(struct drm_connector *c
if (!radeon_connector->dac_load_detect)
return ret;
- r = pm_runtime_get_sync(connector->dev->dev);
- if (r < 0)
- return connector_status_disconnected;
+ if (!drm_kms_helper_is_poll_worker()) {
+ r = pm_runtime_get_sync(connector->dev->dev);
+ if (r < 0)
+ return connector_status_disconnected;
+ }
encoder = radeon_best_single_encoder(connector);
if (!encoder)
@@ -1185,8 +1197,12 @@ radeon_tv_detect(struct drm_connector *c
if (ret == connector_status_connected)
ret = radeon_connector_analog_encoder_conflict_solve(connector, encoder, ret, false);
radeon_connector_update_scratch_regs(connector, ret);
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
+
return ret;
}
@@ -1249,9 +1265,11 @@ radeon_dvi_detect(struct drm_connector *
enum drm_connector_status ret = connector_status_disconnected;
bool dret = false, broken_edid = false;
- r = pm_runtime_get_sync(connector->dev->dev);
- if (r < 0)
- return connector_status_disconnected;
+ if (!drm_kms_helper_is_poll_worker()) {
+ r = pm_runtime_get_sync(connector->dev->dev);
+ if (r < 0)
+ return connector_status_disconnected;
+ }
if (radeon_connector->detected_hpd_without_ddc) {
force = true;
@@ -1434,8 +1452,10 @@ out:
}
exit:
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
return ret;
}
@@ -1686,9 +1706,11 @@ radeon_dp_detect(struct drm_connector *c
if (radeon_dig_connector->is_mst)
return connector_status_disconnected;
- r = pm_runtime_get_sync(connector->dev->dev);
- if (r < 0)
- return connector_status_disconnected;
+ if (!drm_kms_helper_is_poll_worker()) {
+ r = pm_runtime_get_sync(connector->dev->dev);
+ if (r < 0)
+ return connector_status_disconnected;
+ }
if (!force && radeon_check_hpd_status_unchanged(connector)) {
ret = connector->status;
@@ -1775,8 +1797,10 @@ radeon_dp_detect(struct drm_connector *c
}
out:
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
return ret;
}
Patches currently in stable-queue which might be from lukas(a)wunner.de are
queue-4.9/workqueue-allow-retrieval-of-current-task-s-work-struct.patch
queue-4.9/drm-radeon-fix-deadlock-on-runtime-suspend.patch
queue-4.9/drm-amdgpu-fix-deadlock-on-runtime-suspend.patch
queue-4.9/drm-allow-determining-if-current-task-is-output-poll-worker.patch
queue-4.9/drm-nouveau-fix-deadlock-on-runtime-suspend.patch
This is a note to let you know that I've just added the patch titled
drm/nouveau: Fix deadlock on runtime 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:
drm-nouveau-fix-deadlock-on-runtime-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 d61a5c1063515e855bedb1b81e20e50b0ac3541e Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Sun, 11 Feb 2018 10:38:28 +0100
Subject: drm/nouveau: Fix deadlock on runtime suspend
From: Lukas Wunner <lukas(a)wunner.de>
commit d61a5c1063515e855bedb1b81e20e50b0ac3541e upstream.
nouveau's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.
The output poll worker meanwhile calls pm_runtime_get_sync() in
nouveau_connector_detect() which waits for the ongoing suspend to finish,
causing a deadlock.
Fix by not acquiring a runtime PM ref if nouveau_connector_detect() is
called in the output poll worker's context. This is safe because
the poll worker is only enabled while runtime active and we know that
->runtime_suspend waits for it to finish.
Other contexts calling nouveau_connector_detect() do require a runtime
PM ref, these comprise:
status_store() drm sysfs interface
->fill_modes drm callback
drm_fb_helper_probe_connector_modes()
drm_mode_getconnector()
nouveau_connector_hotplug()
nouveau_display_hpd_work()
nv17_tv_set_property()
Stack trace for posterity:
INFO: task kworker/0:1:58 blocked for more than 120 seconds.
Workqueue: events output_poll_execute [drm_kms_helper]
Call Trace:
schedule+0x28/0x80
rpm_resume+0x107/0x6e0
__pm_runtime_resume+0x47/0x70
nouveau_connector_detect+0x7e/0x4a0 [nouveau]
nouveau_connector_detect_lvds+0x132/0x180 [nouveau]
drm_helper_probe_detect_ctx+0x85/0xd0 [drm_kms_helper]
output_poll_execute+0x11e/0x1c0 [drm_kms_helper]
process_one_work+0x184/0x380
worker_thread+0x2e/0x390
INFO: task kworker/0:2:252 blocked for more than 120 seconds.
Workqueue: pm pm_runtime_work
Call Trace:
schedule+0x28/0x80
schedule_timeout+0x1e3/0x370
wait_for_completion+0x123/0x190
flush_work+0x142/0x1c0
nouveau_pmops_runtime_suspend+0x7e/0xd0 [nouveau]
pci_pm_runtime_suspend+0x5c/0x180
vga_switcheroo_runtime_suspend+0x1e/0xa0
__rpm_callback+0xc1/0x200
rpm_callback+0x1f/0x70
rpm_suspend+0x13c/0x640
pm_runtime_work+0x6e/0x90
process_one_work+0x184/0x380
worker_thread+0x2e/0x390
Bugzilla: https://bugs.archlinux.org/task/53497
Bugzilla: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870523
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388#c33
Fixes: 5addcf0a5f0f ("nouveau: add runtime PM support (v0.9)")
Cc: stable(a)vger.kernel.org # v3.12+: 27d4ee03078a: workqueue: Allow retrieval of current task's work struct
Cc: stable(a)vger.kernel.org # v3.12+: 25c058ccaf2e: drm: Allow determining if current task is output poll worker
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Cc: Dave Airlie <airlied(a)redhat.com>
Reviewed-by: Lyude Paul <lyude(a)redhat.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/b7d2cbb609a80f59ccabfdf479b9d…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -271,9 +271,15 @@ nouveau_connector_detect(struct drm_conn
nv_connector->edid = NULL;
}
- ret = pm_runtime_get_sync(connector->dev->dev);
- if (ret < 0 && ret != -EACCES)
- return conn_status;
+ /* Outputs are only polled while runtime active, so acquiring a
+ * runtime PM ref here is unnecessary (and would deadlock upon
+ * runtime suspend because it waits for polling to finish).
+ */
+ if (!drm_kms_helper_is_poll_worker()) {
+ ret = pm_runtime_get_sync(connector->dev->dev);
+ if (ret < 0 && ret != -EACCES)
+ return conn_status;
+ }
nv_encoder = nouveau_connector_ddc_detect(connector);
if (nv_encoder && (i2c = nv_encoder->i2c) != NULL) {
@@ -348,8 +354,10 @@ detect_analog:
out:
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
return conn_status;
}
Patches currently in stable-queue which might be from lukas(a)wunner.de are
queue-4.9/workqueue-allow-retrieval-of-current-task-s-work-struct.patch
queue-4.9/drm-radeon-fix-deadlock-on-runtime-suspend.patch
queue-4.9/drm-amdgpu-fix-deadlock-on-runtime-suspend.patch
queue-4.9/drm-allow-determining-if-current-task-is-output-poll-worker.patch
queue-4.9/drm-nouveau-fix-deadlock-on-runtime-suspend.patch
This is a note to let you know that I've just added the patch titled
drm/i915: Try EDID bitbanging on HDMI after failed read
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:
drm-i915-try-edid-bitbanging-on-hdmi-after-failed-read.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 90024a5951029685acc5396258f1b0de9b23cf4a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Br=C3=BCns?= <stefan.bruens(a)rwth-aachen.de>
Date: Sun, 31 Dec 2017 23:34:54 +0100
Subject: drm/i915: Try EDID bitbanging on HDMI after failed read
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Stefan Brüns <stefan.bruens(a)rwth-aachen.de>
commit 90024a5951029685acc5396258f1b0de9b23cf4a upstream.
The ACK/NACK implementation as found in e.g. the G965 has the falling
clock edge and the release of the data line after the ACK for the received
byte happen at the same time.
This is conformant with the I2C specification, which allows a zero hold
time, see footnote [3]: "A device must internally provide a hold time of
at least 300 ns for the SDA signal (with respect to the V IH(min) of the
SCL signal) to bridge the undefined region of the falling edge of SCL."
Some HDMI-to-VGA converters apparently fail to adhere to this requirement
and latch SDA at the falling clock edge, so instead of an ACK
sometimes a NACK is read and the slave (i.e. the EDID ROM) ends the
transfer.
The bitbanging releases the data line for the ACK only 1/4 bit time after
the falling clock edge, so a slave will see the correct value no matter
if it samples at the rising or the falling clock edge or in the center.
Fallback to bitbanging is already done for the CRT connector.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92685
Signed-off-by: Stefan Brüns <stefan.bruens(a)rwth-aachen.de>
Cc: stable(a)vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/a39f080b-81a5-4c93-b3f7-7cb0a…
(cherry picked from commit cfb926e148e99acc02351d72e8b85e32b5f786ef)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_hdmi.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1452,12 +1452,20 @@ intel_hdmi_set_edid(struct drm_connector
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
struct edid *edid;
bool connected = false;
+ struct i2c_adapter *i2c;
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
- edid = drm_get_edid(connector,
- intel_gmbus_get_adapter(dev_priv,
- intel_hdmi->ddc_bus));
+ i2c = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+
+ edid = drm_get_edid(connector, i2c);
+
+ if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
+ DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO bit-banging\n");
+ intel_gmbus_force_bit(i2c, true);
+ edid = drm_get_edid(connector, i2c);
+ intel_gmbus_force_bit(i2c, false);
+ }
intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);
Patches currently in stable-queue which might be from stefan.bruens(a)rwth-aachen.de are
queue-4.9/drm-i915-try-edid-bitbanging-on-hdmi-after-failed-read.patch
This is a note to let you know that I've just added the patch titled
drm/i915: Always call to intel_display_set_init_power() in resume_early.
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:
drm-i915-always-call-to-intel_display_set_init_power-in-resume_early.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 d13a8479f3584613b6aacbb793eae64578b8f69a Mon Sep 17 00:00:00 2001
From: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Date: Tue, 16 Jan 2018 16:53:24 +0100
Subject: drm/i915: Always call to intel_display_set_init_power() in resume_early.
From: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
commit d13a8479f3584613b6aacbb793eae64578b8f69a upstream.
intel_power_domains_init_hw() calls set_init_power, but when using
runtime power management this call is skipped. This prevents hw readout
from taking place.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104172
Link: https://patchwork.freedesktop.org/patch/msgid/20180116155324.75120-1-maarte…
Fixes: bc87229f323e ("drm/i915/skl: enable PC9/10 power states during suspend-to-idle")
Cc: Nivedita Swaminathan <nivedita.swaminathan(a)intel.com>
Cc: Imre Deak <imre.deak(a)intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson(a)linux.intel.com>
Cc: Jani Nikula <jani.nikula(a)linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Cc: <stable(a)vger.kernel.org> # v4.5+
Reviewed-by: Imre Deak <imre.deak(a)intel.com>
(cherry picked from commit ac25dfed15d470d7f23dd817e965b54aa3f94a1e)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1703,6 +1703,8 @@ static int i915_drm_resume_early(struct
if (IS_BROXTON(dev_priv) ||
!(dev_priv->suspended_to_idle && dev_priv->csr.dmc_payload))
intel_power_domains_init_hw(dev_priv, true);
+ else
+ intel_display_set_init_power(dev_priv, true);
enable_rpm_wakeref_asserts(dev_priv);
Patches currently in stable-queue which might be from maarten.lankhorst(a)linux.intel.com are
queue-4.9/drm-i915-always-call-to-intel_display_set_init_power-in-resume_early.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Notify sbios device ready before send 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:
drm-amdgpu-notify-sbios-device-ready-before-send-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 1bced75f4ab04bec55aecb57d99435dc6d0ae5a0 Mon Sep 17 00:00:00 2001
From: Rex Zhu <Rex.Zhu(a)amd.com>
Date: Tue, 27 Feb 2018 18:20:53 +0800
Subject: drm/amdgpu: Notify sbios device ready before send request
From: Rex Zhu <Rex.Zhu(a)amd.com>
commit 1bced75f4ab04bec55aecb57d99435dc6d0ae5a0 upstream.
it is required if a platform supports PCIe root complex
core voltage reduction. After receiving this notification,
SBIOS can apply default PCIe root complex power policy.
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -540,6 +540,9 @@ int amdgpu_acpi_pcie_performance_request
size_t size;
u32 retry = 3;
+ if (amdgpu_acpi_pcie_notify_device_ready(adev))
+ return -EINVAL;
+
/* Get the device handle */
handle = ACPI_HANDLE(&adev->pdev->dev);
if (!handle)
Patches currently in stable-queue which might be from Rex.Zhu(a)amd.com are
queue-4.9/drm-amdgpu-notify-sbios-device-ready-before-send-request.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Fix deadlock on runtime 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:
drm-amdgpu-fix-deadlock-on-runtime-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 aa0aad57909eb321746325951d66af88a83bc956 Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Sun, 11 Feb 2018 10:38:28 +0100
Subject: drm/amdgpu: Fix deadlock on runtime suspend
From: Lukas Wunner <lukas(a)wunner.de>
commit aa0aad57909eb321746325951d66af88a83bc956 upstream.
amdgpu's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.
The output poll worker meanwhile calls pm_runtime_get_sync() in
amdgpu's ->detect hooks, which waits for the ongoing suspend to finish,
causing a deadlock.
Fix by not acquiring a runtime PM ref if the ->detect hooks are called
in the output poll worker's context. This is safe because the poll
worker is only enabled while runtime active and we know that
->runtime_suspend waits for it to finish.
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Cc: stable(a)vger.kernel.org # v4.2+: 27d4ee03078a: workqueue: Allow retrieval of current task's work struct
Cc: stable(a)vger.kernel.org # v4.2+: 25c058ccaf2e: drm: Allow determining if current task is output poll worker
Cc: Alex Deucher <alexander.deucher(a)amd.com>
Tested-by: Mike Lothian <mike(a)fireburn.co.uk>
Reviewed-by: Lyude Paul <lyude(a)redhat.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/4c9bf72aacae1eef062bd134cd112…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 ++++++++++++++++---------
1 file changed, 38 insertions(+), 20 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -739,9 +739,11 @@ amdgpu_connector_lvds_detect(struct drm_
enum drm_connector_status ret = connector_status_disconnected;
int r;
- r = pm_runtime_get_sync(connector->dev->dev);
- if (r < 0)
- return connector_status_disconnected;
+ if (!drm_kms_helper_is_poll_worker()) {
+ r = pm_runtime_get_sync(connector->dev->dev);
+ if (r < 0)
+ return connector_status_disconnected;
+ }
if (encoder) {
struct amdgpu_encoder *amdgpu_encoder = to_amdgpu_encoder(encoder);
@@ -760,8 +762,12 @@ amdgpu_connector_lvds_detect(struct drm_
/* check acpi lid status ??? */
amdgpu_connector_update_scratch_regs(connector, ret);
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
+
return ret;
}
@@ -871,9 +877,11 @@ amdgpu_connector_vga_detect(struct drm_c
enum drm_connector_status ret = connector_status_disconnected;
int r;
- r = pm_runtime_get_sync(connector->dev->dev);
- if (r < 0)
- return connector_status_disconnected;
+ if (!drm_kms_helper_is_poll_worker()) {
+ r = pm_runtime_get_sync(connector->dev->dev);
+ if (r < 0)
+ return connector_status_disconnected;
+ }
encoder = amdgpu_connector_best_single_encoder(connector);
if (!encoder)
@@ -927,8 +935,10 @@ amdgpu_connector_vga_detect(struct drm_c
amdgpu_connector_update_scratch_regs(connector, ret);
out:
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
return ret;
}
@@ -991,9 +1001,11 @@ amdgpu_connector_dvi_detect(struct drm_c
enum drm_connector_status ret = connector_status_disconnected;
bool dret = false, broken_edid = false;
- r = pm_runtime_get_sync(connector->dev->dev);
- if (r < 0)
- return connector_status_disconnected;
+ if (!drm_kms_helper_is_poll_worker()) {
+ r = pm_runtime_get_sync(connector->dev->dev);
+ if (r < 0)
+ return connector_status_disconnected;
+ }
if (!force && amdgpu_connector_check_hpd_status_unchanged(connector)) {
ret = connector->status;
@@ -1118,8 +1130,10 @@ out:
amdgpu_connector_update_scratch_regs(connector, ret);
exit:
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
return ret;
}
@@ -1362,9 +1376,11 @@ amdgpu_connector_dp_detect(struct drm_co
struct drm_encoder *encoder = amdgpu_connector_best_single_encoder(connector);
int r;
- r = pm_runtime_get_sync(connector->dev->dev);
- if (r < 0)
- return connector_status_disconnected;
+ if (!drm_kms_helper_is_poll_worker()) {
+ r = pm_runtime_get_sync(connector->dev->dev);
+ if (r < 0)
+ return connector_status_disconnected;
+ }
if (!force && amdgpu_connector_check_hpd_status_unchanged(connector)) {
ret = connector->status;
@@ -1432,8 +1448,10 @@ amdgpu_connector_dp_detect(struct drm_co
amdgpu_connector_update_scratch_regs(connector, ret);
out:
- pm_runtime_mark_last_busy(connector->dev->dev);
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (!drm_kms_helper_is_poll_worker()) {
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ }
return ret;
}
Patches currently in stable-queue which might be from lukas(a)wunner.de are
queue-4.9/workqueue-allow-retrieval-of-current-task-s-work-struct.patch
queue-4.9/drm-radeon-fix-deadlock-on-runtime-suspend.patch
queue-4.9/drm-amdgpu-fix-deadlock-on-runtime-suspend.patch
queue-4.9/drm-allow-determining-if-current-task-is-output-poll-worker.patch
queue-4.9/drm-nouveau-fix-deadlock-on-runtime-suspend.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu:Correct max uvd handles
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:
drm-amdgpu-correct-max-uvd-handles.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 0e5ee33d2a54e4c55fe92857f23e1cbb0440d6de Mon Sep 17 00:00:00 2001
From: James Zhu <James.Zhu(a)amd.com>
Date: Tue, 6 Mar 2018 14:43:50 -0500
Subject: drm/amdgpu:Correct max uvd handles
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: James Zhu <James.Zhu(a)amd.com>
commit 0e5ee33d2a54e4c55fe92857f23e1cbb0440d6de upstream.
Max uvd handles should use adev->uvd.max_handles instead of
AMDGPU_MAX_UVD_HANDLES here.
Signed-off-by: James Zhu <James.Zhu(a)amd.com>
Reviewed-by: Leo Liu <leo.liu(a)amd.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -277,7 +277,7 @@ int amdgpu_uvd_suspend(struct amdgpu_dev
if (atomic_read(&adev->uvd.handles[i]))
break;
- if (i == AMDGPU_MAX_UVD_HANDLES)
+ if (i == adev->uvd.max_handles)
return 0;
cancel_delayed_work_sync(&adev->uvd.idle_work);
Patches currently in stable-queue which might be from James.Zhu(a)amd.com are
queue-4.9/drm-amdgpu-correct-max-uvd-handles.patch
queue-4.9/drm-amdgpu-always-save-uvd-vcpu_bo-in-vm-mode.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu:Always save uvd vcpu_bo in VM Mode
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:
drm-amdgpu-always-save-uvd-vcpu_bo-in-vm-mode.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 f8bee6135e167f5b35b7789c74c2956dad14d0d5 Mon Sep 17 00:00:00 2001
From: James Zhu <James.Zhu(a)amd.com>
Date: Tue, 6 Mar 2018 14:52:35 -0500
Subject: drm/amdgpu:Always save uvd vcpu_bo in VM Mode
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: James Zhu <James.Zhu(a)amd.com>
commit f8bee6135e167f5b35b7789c74c2956dad14d0d5 upstream.
When UVD is in VM mode, there is not uvd handle exchanged,
uvd.handles are always 0. So vcpu_bo always need save,
Otherwise amdgpu driver will fail during suspend/resume.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105021
Signed-off-by: James Zhu <James.Zhu(a)amd.com>
Reviewed-by: Leo Liu <leo.liu(a)amd.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -273,12 +273,15 @@ int amdgpu_uvd_suspend(struct amdgpu_dev
if (adev->uvd.vcpu_bo == NULL)
return 0;
- for (i = 0; i < adev->uvd.max_handles; ++i)
- if (atomic_read(&adev->uvd.handles[i]))
- break;
+ /* only valid for physical mode */
+ if (adev->asic_type < CHIP_POLARIS10) {
+ for (i = 0; i < adev->uvd.max_handles; ++i)
+ if (atomic_read(&adev->uvd.handles[i]))
+ break;
- if (i == adev->uvd.max_handles)
- return 0;
+ if (i == adev->uvd.max_handles)
+ return 0;
+ }
cancel_delayed_work_sync(&adev->uvd.idle_work);
Patches currently in stable-queue which might be from James.Zhu(a)amd.com are
queue-4.9/drm-amdgpu-correct-max-uvd-handles.patch
queue-4.9/drm-amdgpu-always-save-uvd-vcpu_bo-in-vm-mode.patch