- Linux-stable-mirror - lists.linaro.org

Patch "workqueue: Allow retrieval of current task's work struct" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

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.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: workqueue-allow-retrieval-of-current-task-s-work-struct.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 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 @@ -467,6 +467,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 @@ -4185,6 +4185,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.14/workqueue-allow-retrieval-of-current-task-s-work-struct.patch queue-4.14/drm-radeon-fix-deadlock-on-runtime-suspend.patch queue-4.14/drm-amdgpu-fix-deadlock-on-runtime-suspend.patch queue-4.14/drm-allow-determining-if-current-task-is-output-poll-worker.patch queue-4.14/drm-nouveau-fix-deadlock-on-runtime-suspend.patch

7 years, 9 months

1
0
0 0

Patch "virtio_ring: fix num_free handling in error case" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

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.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: virtio_ring-fix-num_free-handling-in-error-case.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 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 @@ -428,8 +428,6 @@ unmap_release: i = virtio16_to_cpu(_vq->vdev, 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.14/virtio_ring-fix-num_free-handling-in-error-case.patch

7 years, 9 months

1
0
0 0

Patch "scsi: qla2xxx: Fix recursion while sending terminate exchange" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix recursion while sending terminate exchange to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-qla2xxx-fix-recursion-while-sending-terminate-exchange.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3efc31f76dd7fc8a71cd86683909f637e9b7cadb Mon Sep 17 00:00:00 2001 From: "himanshu.madhani(a)cavium.com" <himanshu.madhani(a)cavium.com> Date: Mon, 15 Jan 2018 20:46:47 -0800 Subject: scsi: qla2xxx: Fix recursion while sending terminate exchange From: himanshu.madhani(a)cavium.com <himanshu.madhani(a)cavium.com> commit 3efc31f76dd7fc8a71cd86683909f637e9b7cadb upstream. During error test case where switch port status is toggled from enable to disable, following stack trace is seen which indicates recursion trying to send terminate exchange. This regression was introduced by commit 82de802ad46e ("scsi: qla2xxx: Preparation for Target MQ.") BUG: stack guard page was hit at ffffb96488383ff8 (stack is ffffb96488384000..ffffb96488387fff) BUG: stack guard page was hit at ffffb964886c3ff8 (stack is ffffb964886c4000..ffffb964886c7fff) kernel stack overflow (double-fault): 0000 [#1] SMP qlt_term_ctio_exchange+0x9c/0xb0 [qla2xxx] qlt_term_ctio_exchange+0x9c/0xb0 [qla2xxx] qlt_term_ctio_exchange+0x9c/0xb0 [qla2xxx] qlt_term_ctio_exchange+0x9c/0xb0 [qla2xxx] qlt_term_ctio_exchange+0x9c/0xb0 [qla2xxx] Fixes: 82de802ad46e ("scsi: qla2xxx: Preparation for Target MQ.") Cc: <stable(a)vger.kernel.org> #4.10 Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com> 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_target.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/qla2xxx/qla_target.c +++ b/drivers/scsi/qla2xxx/qla_target.c @@ -3708,7 +3708,7 @@ static int qlt_term_ctio_exchange(struct term = 1; if (term) - qlt_term_ctio_exchange(qpair, ctio, cmd, status); + qlt_send_term_exchange(qpair, cmd, &cmd->atio, 1, 0); return term; } Patches currently in stable-queue which might be from himanshu.madhani(a)cavium.com are queue-4.14/scsi-qla2xxx-fix-null-pointer-crash-due-to-active-timer-for-abts.patch queue-4.14/scsi-qla2xxx-fix-recursion-while-sending-terminate-exchange.patch queue-4.14/scsi-qla2xxx-fix-null-pointer-crash-due-to-probe-failure.patch

7 years, 9 months

1
0
0 0

Patch "scsi: qla2xxx: Fix NULL pointer crash due to probe failure" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix NULL pointer crash due to probe failure to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-qla2xxx-fix-null-pointer-crash-due-to-probe-failure.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d64d6c5671db5e693a0caaee79f2571b098749c9 Mon Sep 17 00:00:00 2001 From: "himanshu.madhani(a)cavium.com" <himanshu.madhani(a)cavium.com> Date: Mon, 15 Jan 2018 20:46:46 -0800 Subject: scsi: qla2xxx: Fix NULL pointer crash due to probe failure From: himanshu.madhani(a)cavium.com <himanshu.madhani(a)cavium.com> commit d64d6c5671db5e693a0caaee79f2571b098749c9 upstream. This patch fixes regression added by commit d74595278f4ab ("scsi: qla2xxx: Add multiple queue pair functionality."). When driver is not able to get reqeusted IRQs from the system, driver will attempt tp clean up memory before failing hardware probe. During this cleanup, driver assigns NULL value to the pointer which has not been allocated by driver yet. This results in a NULL pointer access. Log file will show following message and stack trace qla2xxx [0000:a3:00.1]-00c7:21: MSI-X: Failed to enable support, giving up -- 32/-1. qla2xxx [0000:a3:00.1]-0037:21: Falling back-to MSI mode --1. qla2xxx [0000:a3:00.1]-003a:21: Failed to reserve interrupt 821 already in use. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffc010c4b6>] qla2x00_probe_one+0x18b6/0x2730 [qla2xxx] PGD 0 Oops: 0002 [#1] SMP Fixes: d74595278f4ab ("scsi: qla2xxx: Add multiple queue pair functionality."). Cc: <stable(a)vger.kernel.org> # 4.10 Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com> 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_os.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/drivers/scsi/qla2xxx/qla_os.c +++ b/drivers/scsi/qla2xxx/qla_os.c @@ -3003,9 +3003,6 @@ qla2x00_probe_one(struct pci_dev *pdev, base_vha = qla2x00_create_host(sht, ha); if (!base_vha) { ret = -ENOMEM; - qla2x00_mem_free(ha); - qla2x00_free_req_que(ha, req); - qla2x00_free_rsp_que(ha, rsp); goto probe_hw_failed; } @@ -3066,7 +3063,7 @@ qla2x00_probe_one(struct pci_dev *pdev, /* Set up the irqs */ ret = qla2x00_request_irqs(ha, rsp); if (ret) - goto probe_init_failed; + goto probe_hw_failed; /* Alloc arrays of request and response ring ptrs */ if (!qla2x00_alloc_queues(ha, req, rsp)) { @@ -3374,6 +3371,9 @@ probe_failed: scsi_host_put(base_vha->host); probe_hw_failed: + qla2x00_mem_free(ha); + qla2x00_free_req_que(ha, req); + qla2x00_free_rsp_que(ha, rsp); qla2x00_clear_drv_active(ha); iospace_config_failed: Patches currently in stable-queue which might be from himanshu.madhani(a)cavium.com are queue-4.14/scsi-qla2xxx-fix-null-pointer-crash-due-to-active-timer-for-abts.patch queue-4.14/scsi-qla2xxx-fix-recursion-while-sending-terminate-exchange.patch queue-4.14/scsi-qla2xxx-fix-null-pointer-crash-due-to-probe-failure.patch

7 years, 9 months

1
0
0 0

Patch "scsi: qla2xxx: Fix NULL pointer crash due to active timer for ABTS" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

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.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-qla2xxx-fix-null-pointer-crash-due-to-active-timer-for-abts.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 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 @@ -1348,6 +1348,7 @@ qla24xx_abort_sp_done(void *ptr, int res srb_t *sp = 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.14/scsi-qla2xxx-fix-null-pointer-crash-due-to-active-timer-for-abts.patch queue-4.14/scsi-qla2xxx-fix-recursion-while-sending-terminate-exchange.patch queue-4.14/scsi-qla2xxx-fix-null-pointer-crash-due-to-probe-failure.patch

7 years, 9 months

1
0
0 0

Patch "scsi: core: Avoid that ATA error handling can trigger a kernel hang or oops" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: core: Avoid that ATA error handling can trigger a kernel hang or oops to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-core-avoid-that-ata-error-handling-can-trigger-a-kernel-hang-or-oops.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3be8828fc507cdafe7040a3dcf361a2bcd8e305b Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Thu, 22 Feb 2018 11:30:20 -0800 Subject: scsi: core: Avoid that ATA error handling can trigger a kernel hang or oops From: Bart Van Assche <bart.vanassche(a)wdc.com> commit 3be8828fc507cdafe7040a3dcf361a2bcd8e305b upstream. Avoid that the recently introduced call_rcu() call in the SCSI core triggers a double call_rcu() call. Reported-by: Natanael Copa <ncopa(a)alpinelinux.org> Reported-by: Damien Le Moal <damien.lemoal(a)wdc.com> References: https://bugzilla.kernel.org/show_bug.cgi?id=198861 Fixes: 3bd6f43f5cb3 ("scsi: core: Ensure that the SCSI error handler gets woken up") Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Reviewed-by: Damien Le Moal <damien.lemoal(a)wdc.com> Tested-by: Damien Le Moal <damien.lemoal(a)wdc.com> Cc: Natanael Copa <ncopa(a)alpinelinux.org> Cc: Damien Le Moal <damien.lemoal(a)wdc.com> Cc: Alexandre Oliva <oliva(a)gnu.org> Cc: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> Cc: Hannes Reinecke <hare(a)suse.com> Cc: Johannes Thumshirn <jthumshirn(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/hosts.c | 3 --- drivers/scsi/scsi_error.c | 5 +++-- drivers/scsi/scsi_lib.c | 2 ++ include/scsi/scsi_cmnd.h | 3 +++ include/scsi/scsi_host.h | 2 -- 5 files changed, 8 insertions(+), 7 deletions(-) --- a/drivers/scsi/hosts.c +++ b/drivers/scsi/hosts.c @@ -328,8 +328,6 @@ static void scsi_host_dev_release(struct if (shost->work_q) destroy_workqueue(shost->work_q); - destroy_rcu_head(&shost->rcu); - if (shost->shost_state == SHOST_CREATED) { /* * Free the shost_dev device name here if scsi_host_alloc() @@ -404,7 +402,6 @@ struct Scsi_Host *scsi_host_alloc(struct INIT_LIST_HEAD(&shost->starved_list); init_waitqueue_head(&shost->host_wait); mutex_init(&shost->scan_mutex); - init_rcu_head(&shost->rcu); index = ida_simple_get(&host_index_ida, 0, 0, GFP_KERNEL); if (index < 0) --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -222,7 +222,8 @@ static void scsi_eh_reset(struct scsi_cm static void scsi_eh_inc_host_failed(struct rcu_head *head) { - struct Scsi_Host *shost = container_of(head, typeof(*shost), rcu); + struct scsi_cmnd *scmd = container_of(head, typeof(*scmd), rcu); + struct Scsi_Host *shost = scmd->device->host; unsigned long flags; spin_lock_irqsave(shost->host_lock, flags); @@ -258,7 +259,7 @@ void scsi_eh_scmd_add(struct scsi_cmnd * * Ensure that all tasks observe the host state change before the * host_failed change. */ - call_rcu(&shost->rcu, scsi_eh_inc_host_failed); + call_rcu(&scmd->rcu, scsi_eh_inc_host_failed); } /** --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -670,6 +670,7 @@ static bool scsi_end_request(struct requ if (!blk_rq_is_scsi(req)) { WARN_ON_ONCE(!(cmd->flags & SCMD_INITIALIZED)); cmd->flags &= ~SCMD_INITIALIZED; + destroy_rcu_head(&cmd->rcu); } if (req->mq_ctx) { @@ -1150,6 +1151,7 @@ void scsi_initialize_rq(struct request * struct scsi_cmnd *cmd = blk_mq_rq_to_pdu(rq); scsi_req_init(&cmd->req); + init_rcu_head(&cmd->rcu); cmd->jiffies_at_alloc = jiffies; cmd->retries = 0; } --- a/include/scsi/scsi_cmnd.h +++ b/include/scsi/scsi_cmnd.h @@ -69,6 +69,9 @@ struct scsi_cmnd { struct list_head list; /* scsi_cmnd participates in queue lists */ struct list_head eh_entry; /* entry for the host eh_cmd_q */ struct delayed_work abort_work; + + struct rcu_head rcu; + int eh_eflags; /* Used by error handlr */ /* --- a/include/scsi/scsi_host.h +++ b/include/scsi/scsi_host.h @@ -571,8 +571,6 @@ struct Scsi_Host { struct blk_mq_tag_set tag_set; }; - struct rcu_head rcu; - atomic_t host_busy; /* commands actually active on low-level */ atomic_t host_blocked; Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.14/scsi-core-avoid-that-ata-error-handling-can-trigger-a-kernel-hang-or-oops.patch

7 years, 9 months

1
0
0 0

Patch "Revert "drm/radeon/pm: autoswitch power state when in balanced mode"" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Revert "drm/radeon/pm: autoswitch power state when in balanced mode" to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: revert-drm-radeon-pm-autoswitch-power-state-when-in-balanced-mode.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 53bf277b487eb5ae6695db01bede0fe406792119 Mon Sep 17 00:00:00 2001 From: Alex Deucher <alexander.deucher(a)amd.com> Date: Thu, 15 Feb 2018 08:40:30 -0500 Subject: Revert "drm/radeon/pm: autoswitch power state when in balanced mode" From: Alex Deucher <alexander.deucher(a)amd.com> commit 53bf277b487eb5ae6695db01bede0fe406792119 upstream. This reverts commit 1c331f75aa6ccbf64ebcc5a019183e617c9d818a. Breaks resume on some systems. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100759 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/radeon/radeon_pm.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -47,7 +47,6 @@ static bool radeon_pm_in_vbl(struct rade static bool radeon_pm_debug_check_in_vbl(struct radeon_device *rdev, bool finish); static void radeon_pm_update_profile(struct radeon_device *rdev); static void radeon_pm_set_clocks(struct radeon_device *rdev); -static void radeon_pm_compute_clocks_dpm(struct radeon_device *rdev); int radeon_pm_get_type_index(struct radeon_device *rdev, enum radeon_pm_state_type ps_type, @@ -80,8 +79,6 @@ void radeon_pm_acpi_event_handler(struct radeon_dpm_enable_bapm(rdev, rdev->pm.dpm.ac_power); } mutex_unlock(&rdev->pm.mutex); - /* allow new DPM state to be picked */ - radeon_pm_compute_clocks_dpm(rdev); } else if (rdev->pm.pm_method == PM_METHOD_PROFILE) { if (rdev->pm.profile == PM_PROFILE_AUTO) { mutex_lock(&rdev->pm.mutex); @@ -885,8 +882,7 @@ static struct radeon_ps *radeon_dpm_pick dpm_state = POWER_STATE_TYPE_INTERNAL_3DPERF; /* balanced states don't exist at the moment */ if (dpm_state == POWER_STATE_TYPE_BALANCED) - dpm_state = rdev->pm.dpm.ac_power ? - POWER_STATE_TYPE_PERFORMANCE : POWER_STATE_TYPE_BATTERY; + dpm_state = POWER_STATE_TYPE_PERFORMANCE; restart_search: /* Pick the best power state based on current conditions */ Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are queue-4.14/drm-amdgpu-notify-sbios-device-ready-before-send-request.patch queue-4.14/workqueue-allow-retrieval-of-current-task-s-work-struct.patch queue-4.14/drm-amd-powerplay-vega10-allow-mclk-switching-with-no-displays.patch queue-4.14/drm-radeon-fix-kv-harvesting.patch queue-4.14/drm-radeon-fix-deadlock-on-runtime-suspend.patch queue-4.14/drm-amdgpu-correct-max-uvd-handles.patch queue-4.14/drm-amd-powerplay-smu7-allow-mclk-switching-with-no-displays.patch queue-4.14/drm-amdgpu-fix-deadlock-on-runtime-suspend.patch queue-4.14/drm-amd-powerplay-fix-power-over-limit-on-fiji.patch queue-4.14/drm-allow-determining-if-current-task-is-output-poll-worker.patch queue-4.14/drm-amdgpu-used-cached-pcie-gen-info-for-si-v2.patch queue-4.14/revert-drm-radeon-pm-autoswitch-power-state-when-in-balanced-mode.patch queue-4.14/drm-amdgpu-fix-kv-harvesting.patch queue-4.14/drm-amdgpu-always-save-uvd-vcpu_bo-in-vm-mode.patch queue-4.14/drm-radeon-insist-on-32-bit-dma-for-cedar-on-ppc64-ppc64le.patch

7 years, 9 months

1
0
0 0

Patch "regulator: stm32-vrefbuf: fix check on ready flag" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled regulator: stm32-vrefbuf: fix check on ready flag to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: regulator-stm32-vrefbuf-fix-check-on-ready-flag.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f63248fac563125fd5a2f0bc780ce7a299872cab Mon Sep 17 00:00:00 2001 From: Fabrice Gasnier <fabrice.gasnier(a)st.com> Date: Thu, 8 Feb 2018 14:43:05 +0100 Subject: regulator: stm32-vrefbuf: fix check on ready flag From: Fabrice Gasnier <fabrice.gasnier(a)st.com> commit f63248fac563125fd5a2f0bc780ce7a299872cab upstream. stm32_vrefbuf_enable() wrongly checks VRR bit: 0 stands for not ready, 1 for ready. It currently checks the opposite. This makes enable routine to exit immediately without waiting for ready flag. Fixes: 0cdbf481e927 ("regulator: Add support for stm32-vrefbuf") Signed-off-by: Fabrice Gasnier <fabrice.gasnier(a)st.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/regulator/stm32-vrefbuf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/regulator/stm32-vrefbuf.c +++ b/drivers/regulator/stm32-vrefbuf.c @@ -51,7 +51,7 @@ static int stm32_vrefbuf_enable(struct r * arbitrary timeout. */ ret = readl_poll_timeout(priv->base + STM32_VREFBUF_CSR, val, - !(val & STM32_VRR), 650, 10000); + val & STM32_VRR, 650, 10000); if (ret) { dev_err(&rdev->dev, "stm32 vrefbuf timed out!\n"); val = readl_relaxed(priv->base + STM32_VREFBUF_CSR); Patches currently in stable-queue which might be from fabrice.gasnier(a)st.com are queue-4.14/regulator-stm32-vrefbuf-fix-check-on-ready-flag.patch

7 years, 9 months

1
0
0 0

Patch "perf tools: Fix trigger class trigger_on()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

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.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-tools-fix-trigger-class-trigger_on.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 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 @@ -12,7 +12,7 @@ * States and transits: * * - * OFF--(on)--> READY --(hit)--> HIT + * OFF--> ON --> READY --(hit)--> HIT * ^ | * | (ready) * | | @@ -27,8 +27,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; }; @@ -50,7 +51,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.14/perf-tools-fix-trigger-class-trigger_on.patch

7 years, 9 months

1
0
0 0

Patch "PCI: dwc: Fix enumeration end when reaching root subordinate" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI: dwc: Fix enumeration end when reaching root subordinate to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pci-dwc-fix-enumeration-end-when-reaching-root-subordinate.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fc110ebdd014dd1368c98e7685b47789c31fab42 Mon Sep 17 00:00:00 2001 From: Koen Vandeputte <koen.vandeputte(a)ncentric.com> Date: Wed, 7 Mar 2018 10:46:39 -0600 Subject: PCI: dwc: Fix enumeration end when reaching root subordinate From: Koen Vandeputte <koen.vandeputte(a)ncentric.com> commit fc110ebdd014dd1368c98e7685b47789c31fab42 upstream. The subordinate value indicates the highest bus number which can be reached downstream though a certain device. Commit a20c7f36bd3d ("PCI: Do not allocate more buses than available in parent") ensures that downstream devices cannot assign busnumbers higher than the upstream device subordinate number, which was indeed illogical. By default, dw_pcie_setup_rc() inits the Root Complex subordinate to a value of 0x01. Due to this combined with above commit, enumeration stops digging deeper downstream as soon as bus num 0x01 has been assigned, which is always the case for a bridge device. This results in all devices behind a bridge bus remaining undetected, as these would be connected to bus 0x02 or higher. Fix this by initializing the RC to a subordinate value of 0xff, which is not altering hardware behaviour in any way, but informs probing function pci_scan_bridge() later on which reads this value back from register. The following nasty errors during boot are also fixed by this: pci_bus 0000:02: busn_res: can not insert [bus 02-ff] under [bus 01] (conflicts with (null) [bus 01]) ... pci_bus 0000:03: [bus 03] partially hidden behind bridge 0000:01 [bus 01] ... pci_bus 0000:04: [bus 04] partially hidden behind bridge 0000:01 [bus 01] ... pci_bus 0000:05: [bus 05] partially hidden behind bridge 0000:01 [bus 01] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 05 pci_bus 0000:02: busn_res: can not insert [bus 02-05] under [bus 01] (conflicts with (null) [bus 01]) pci_bus 0000:02: [bus 02-05] partially hidden behind bridge 0000:01 [bus 01] Fixes: a20c7f36bd3d ("PCI: Do not allocate more buses than available in parent") Tested-by: Niklas Cassel <niklas.cassel(a)axis.com> Tested-by: Fabio Estevam <fabio.estevam(a)nxp.com> Tested-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk> Signed-off-by: Koen Vandeputte <koen.vandeputte(a)ncentric.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Reviewed-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Acked-by: Lucas Stach <l.stach(a)pengutronix.de> Cc: stable(a)vger.kernel.org # v4.15+ Cc: Binghui Wang <wangbinghui(a)hisilicon.com> Cc: Jesper Nilsson <jesper.nilsson(a)axis.com> Cc: Jianguo Sun <sunjianguo1(a)huawei.com> Cc: Jingoo Han <jingoohan1(a)gmail.com> Cc: Kishon Vijay Abraham I <kishon(a)ti.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com> Cc: Minghuan Lian <minghuan.Lian(a)freescale.com> Cc: Mingkai Hu <mingkai.hu(a)freescale.com> Cc: Murali Karicheri <m-karicheri2(a)ti.com> Cc: Pratyush Anand <pratyush.anand(a)gmail.com> Cc: Richard Zhu <hongxing.zhu(a)nxp.com> Cc: Roy Zang <tie-fei.zang(a)freescale.com> Cc: Shawn Guo <shawn.guo(a)linaro.org> Cc: Stanimir Varbanov <svarbanov(a)mm-sol.com> Cc: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com> Cc: Xiaowei Song <songxiaowei(a)hisilicon.com> Cc: Zhou Wang <wangzhou1(a)hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/dwc/pcie-designware-host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/pci/dwc/pcie-designware-host.c +++ b/drivers/pci/dwc/pcie-designware-host.c @@ -607,7 +607,7 @@ void dw_pcie_setup_rc(struct pcie_port * /* setup bus numbers */ val = dw_pcie_readl_dbi(pci, PCI_PRIMARY_BUS); val &= 0xff000000; - val |= 0x00010100; + val |= 0x00ff0100; dw_pcie_writel_dbi(pci, PCI_PRIMARY_BUS, val); /* setup command register */ Patches currently in stable-queue which might be from koen.vandeputte(a)ncentric.com are queue-4.14/pci-dwc-fix-enumeration-end-when-reaching-root-subordinate.patch

7 years, 9 months

1
0
0 0

Patch "mm/page_alloc: fix memmap_init_zone pageblock alignment" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm/page_alloc: fix memmap_init_zone pageblock alignment to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mm-page_alloc-fix-memmap_init_zone-pageblock-alignment.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 864b75f9d6b0100bb24fdd9a20d156e7cda9b5ae Mon Sep 17 00:00:00 2001 From: Daniel Vacek <neelx(a)redhat.com> Date: Fri, 9 Mar 2018 15:51:13 -0800 Subject: mm/page_alloc: fix memmap_init_zone pageblock alignment From: Daniel Vacek <neelx(a)redhat.com> commit 864b75f9d6b0100bb24fdd9a20d156e7cda9b5ae upstream. Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns where possible") introduced a bug where move_freepages() triggers a VM_BUG_ON() on uninitialized page structure due to pageblock alignment. To fix this, simply align the skipped pfns in memmap_init_zone() the same way as in move_freepages_block(). Seen in one of the RHEL reports: crash> log | grep -e BUG -e RIP -e Call.Trace -e move_freepages_block -e rmqueue -e freelist -A1 kernel BUG at mm/page_alloc.c:1389! invalid opcode: 0000 [#1] SMP -- RIP: 0010:[<ffffffff8118833e>] [<ffffffff8118833e>] move_freepages+0x15e/0x160 RSP: 0018:ffff88054d727688 EFLAGS: 00010087 -- Call Trace: [<ffffffff811883b3>] move_freepages_block+0x73/0x80 [<ffffffff81189e63>] __rmqueue+0x263/0x460 [<ffffffff8118c781>] get_page_from_freelist+0x7e1/0x9e0 [<ffffffff8118caf6>] __alloc_pages_nodemask+0x176/0x420 -- RIP [<ffffffff8118833e>] move_freepages+0x15e/0x160 RSP <ffff88054d727688> crash> page_init_bug -v | grep RAM <struct resource 0xffff88067fffd2f8> 1000 - 9bfff System RAM (620.00 KiB) <struct resource 0xffff88067fffd3a0> 100000 - 430bffff System RAM ( 1.05 GiB = 1071.75 MiB = 1097472.00 KiB) <struct resource 0xffff88067fffd410> 4b0c8000 - 4bf9cfff System RAM ( 14.83 MiB = 15188.00 KiB) <struct resource 0xffff88067fffd480> 4bfac000 - 646b1fff System RAM (391.02 MiB = 400408.00 KiB) <struct resource 0xffff88067fffd560> 7b788000 - 7b7fffff System RAM (480.00 KiB) <struct resource 0xffff88067fffd640> 100000000 - 67fffffff System RAM ( 22.00 GiB) crash> page_init_bug | head -6 <struct resource 0xffff88067fffd560> 7b788000 - 7b7fffff System RAM (480.00 KiB) <struct page 0xffffea0001ede200> 1fffff00000000 0 <struct pglist_data 0xffff88047ffd9000> 1 <struct zone 0xffff88047ffd9800> DMA32 4096 1048575 <struct page 0xffffea0001ede200> 505736 505344 <struct page 0xffffea0001ed8000> 505855 <struct page 0xffffea0001edffc0> <struct page 0xffffea0001ed8000> 0 0 <struct pglist_data 0xffff88047ffd9000> 0 <struct zone 0xffff88047ffd9000> DMA 1 4095 <struct page 0xffffea0001edffc0> 1fffff00000400 0 <struct pglist_data 0xffff88047ffd9000> 1 <struct zone 0xffff88047ffd9800> DMA32 4096 1048575 BUG, zones differ! Note that this range follows two not populated sections 68000000-77ffffff in this zone. 7b788000-7b7fffff is the first one after a gap. This makes memmap_init_zone() skip all the pfns up to the beginning of this range. But this range is not pageblock (2M) aligned. In fact no range has to be. crash> kmem -p 77fff000 78000000 7b5ff000 7b600000 7b787000 7b788000 PAGE PHYSICAL MAPPING INDEX CNT FLAGS ffffea0001e00000 78000000 0 0 0 0 ffffea0001ed7fc0 7b5ff000 0 0 0 0 ffffea0001ed8000 7b600000 0 0 0 0 <<<< ffffea0001ede1c0 7b787000 0 0 0 0 ffffea0001ede200 7b788000 0 0 1 1fffff00000000 Top part of page flags should contain nodeid and zonenr, which is not the case for page ffffea0001ed8000 here (<<<<). crash> log | grep -o fffea0001ed[^\ ]* | sort -u fffea0001ed8000 fffea0001eded20 fffea0001edffc0 crash> bt -r | grep -o fffea0001ed[^\ ]* | sort -u fffea0001ed8000 fffea0001eded00 fffea0001eded20 fffea0001edffc0 Initialization of the whole beginning of the section is skipped up to the start of the range due to the commit b92df1de5d28. Now any code calling move_freepages_block() (like reusing the page from a freelist as in this example) with a page from the beginning of the range will get the page rounded down to start_page ffffea0001ed8000 and passed to move_freepages() which crashes on assertion getting wrong zonenr. > VM_BUG_ON(page_zone(start_page) != page_zone(end_page)); Note, page_zone() derives the zone from page flags here. >From similar machine before commit b92df1de5d28: crash> kmem -p 77fff000 78000000 7b5ff000 7b600000 7b7fe000 7b7ff000 PAGE PHYSICAL MAPPING INDEX CNT FLAGS fffff73941e00000 78000000 0 0 1 1fffff00000000 fffff73941ed7fc0 7b5ff000 0 0 1 1fffff00000000 fffff73941ed8000 7b600000 0 0 1 1fffff00000000 fffff73941edff80 7b7fe000 0 0 1 1fffff00000000 fffff73941edffc0 7b7ff000 ffff8e67e04d3ae0 ad84 1 1fffff00020068 uptodate,lru,active,mappedtodisk All the pages since the beginning of the section are initialized. move_freepages()' not gonna blow up. The same machine with this fix applied: crash> kmem -p 77fff000 78000000 7b5ff000 7b600000 7b7fe000 7b7ff000 PAGE PHYSICAL MAPPING INDEX CNT FLAGS ffffea0001e00000 78000000 0 0 0 0 ffffea0001e00000 7b5ff000 0 0 0 0 ffffea0001ed8000 7b600000 0 0 1 1fffff00000000 ffffea0001edff80 7b7fe000 0 0 1 1fffff00000000 ffffea0001edffc0 7b7ff000 ffff88017fb13720 8 2 1fffff00020068 uptodate,lru,active,mappedtodisk At least the bare minimum of pages is initialized preventing the crash as well. Customers started to report this as soon as 7.4 (where b92df1de5d28 was merged in RHEL) was released. I remember reports from September/October-ish times. It's not easily reproduced and happens on a handful of machines only. I guess that's why. But that does not make it less serious, I think. Though there actually is a report here: https://bugzilla.kernel.org/show_bug.cgi?id=196443 And there are reports for Fedora from July: https://bugzilla.redhat.com/show_bug.cgi?id=1473242 and CentOS: https://bugs.centos.org/view.php?id=13964 and we internally track several dozens reports for RHEL bug https://bugzilla.redhat.com/show_bug.cgi?id=1525121 Link: http://lkml.kernel.org/r/0485727b2e82da7efbce5f6ba42524b429d0391a.152001194… Fixes: b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns where possible") Signed-off-by: Daniel Vacek <neelx(a)redhat.com> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Paul Burton <paul.burton(a)imgtec.com> Cc: Pavel Tatashin <pasha.tatashin(a)oracle.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> 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> --- mm/page_alloc.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5307,9 +5307,14 @@ void __meminit memmap_init_zone(unsigned /* * Skip to the pfn preceding the next valid one (or * end_pfn), such that we hit a valid pfn (or end_pfn) - * on our next iteration of the loop. + * on our next iteration of the loop. Note that it needs + * to be pageblock aligned even when the region itself + * is not. move_freepages_block() can shift ahead of + * the valid region but still depends on correct page + * metadata. */ - pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1; + pfn = (memblock_next_valid_pfn(pfn, end_pfn) & + ~(pageblock_nr_pages-1)) - 1; #endif continue; } Patches currently in stable-queue which might be from neelx(a)redhat.com are queue-4.14/mm-page_alloc-fix-memmap_init_zone-pageblock-alignment.patch queue-4.14/mm-memblock.c-hardcode-the-end_pfn-being-1.patch

7 years, 9 months

1
0
0 0

Patch "mm/memblock.c: hardcode the end_pfn being -1" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm/memblock.c: hardcode the end_pfn being -1 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mm-memblock.c-hardcode-the-end_pfn-being-1.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 379b03b7fa05f7db521b7732a52692448a3c34fe Mon Sep 17 00:00:00 2001 From: Daniel Vacek <neelx(a)redhat.com> Date: Fri, 9 Mar 2018 15:51:09 -0800 Subject: mm/memblock.c: hardcode the end_pfn being -1 From: Daniel Vacek <neelx(a)redhat.com> commit 379b03b7fa05f7db521b7732a52692448a3c34fe upstream. This is just a cleanup. It aids handling the special end case in the next commit. [akpm(a)linux-foundation.org: make it work against current -linus, not against -mm] [akpm(a)linux-foundation.org: make it work against current -linus, not against -mm some more] Link: http://lkml.kernel.org/r/1ca478d4269125a99bcfb1ca04d7b88ac1aee924.152001194… Signed-off-by: Daniel Vacek <neelx(a)redhat.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Pavel Tatashin <pasha.tatashin(a)oracle.com> Cc: Paul Burton <paul.burton(a)imgtec.com> Cc: <stable(a)vger.kernel.org> 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> --- mm/memblock.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/mm/memblock.c +++ b/mm/memblock.c @@ -1107,7 +1107,7 @@ unsigned long __init_memblock memblock_n struct memblock_type *type = &memblock.memory; unsigned int right = type->cnt; unsigned int mid, left = 0; - phys_addr_t addr = PFN_PHYS(pfn + 1); + phys_addr_t addr = PFN_PHYS(++pfn); do { mid = (right + left) / 2; @@ -1118,15 +1118,15 @@ unsigned long __init_memblock memblock_n type->regions[mid].size)) left = mid + 1; else { - /* addr is within the region, so pfn + 1 is valid */ - return min(pfn + 1, max_pfn); + /* addr is within the region, so pfn is valid */ + return pfn; } } while (left < right); if (right == type->cnt) - return max_pfn; + return -1UL; else - return min(PHYS_PFN(type->regions[right].base), max_pfn); + return PHYS_PFN(type->regions[right].base); } /** Patches currently in stable-queue which might be from neelx(a)redhat.com are queue-4.14/mm-page_alloc-fix-memmap_init_zone-pageblock-alignment.patch queue-4.14/mm-memblock.c-hardcode-the-end_pfn-being-1.patch

7 years, 9 months

1
0
0 0

Patch "MIPS: OCTEON: irq: Check for null return on kzalloc allocation" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

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.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mips-octeon-irq-check-for-null-return-on-kzalloc-allocation.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 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.14/mips-ath25-check-for-kzalloc-allocation-failure.patch queue-4.14/mips-octeon-irq-check-for-null-return-on-kzalloc-allocation.patch

7 years, 9 months

1
0
0 0

Patch "MIPS: BMIPS: Do not mask IPIs during suspend" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

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.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mips-bmips-do-not-mask-ipis-during-suspend.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 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 @@ -168,11 +168,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.14/mips-bmips-do-not-mask-ipis-during-suspend.patch

7 years, 9 months

1
0
0 0

Patch "MIPS: ath25: Check for kzalloc allocation failure" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

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.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mips-ath25-check-for-kzalloc-allocation-failure.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 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.14/mips-ath25-check-for-kzalloc-allocation-failure.patch queue-4.14/mips-octeon-irq-check-for-null-return-on-kzalloc-allocation.patch

7 years, 9 months

1
0
0 0

Patch "loop: Fix lost writes caused by missing flag" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

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.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: loop-fix-lost-writes-caused-by-missing-flag.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 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 @@ -266,7 +266,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, 0); Patches currently in stable-queue which might be from ross.zwisler(a)linux.intel.com are queue-4.14/loop-fix-lost-writes-caused-by-missing-flag.patch

7 years, 9 months

1
0
0 0

Patch "lib/bug.c: exclude non-BUG/WARN exceptions from report_bug()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled lib/bug.c: exclude non-BUG/WARN exceptions from report_bug() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: lib-bug.c-exclude-non-bug-warn-exceptions-from-report_bug.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1b4cfe3c0a30dde968fb43c577a8d7e262a145ee Mon Sep 17 00:00:00 2001 From: Kees Cook <keescook(a)chromium.org> Date: Fri, 9 Mar 2018 15:51:02 -0800 Subject: lib/bug.c: exclude non-BUG/WARN exceptions from report_bug() From: Kees Cook <keescook(a)chromium.org> commit 1b4cfe3c0a30dde968fb43c577a8d7e262a145ee upstream. Commit b8347c219649 ("x86/debug: Handle warnings before the notifier chain, to fix KGDB crash") changed the ordering of fixups, and did not take into account the case of x86 processing non-WARN() and non-BUG() exceptions. This would lead to output of a false BUG line with no other information. In the case of a refcount exception, it would be immediately followed by the refcount WARN(), producing very strange double-"cut here": lkdtm: attempting bad refcount_inc() overflow ------------[ cut here ]------------ Kernel BUG at 0000000065f29de5 [verbose debug info unavailable] ------------[ cut here ]------------ refcount_t overflow at lkdtm_REFCOUNT_INC_OVERFLOW+0x6b/0x90 in cat[3065], uid/euid: 0/0 WARNING: CPU: 0 PID: 3065 at kernel/panic.c:657 refcount_error_report+0x9a/0xa4 ... In the prior ordering, exceptions were searched first: do_trap_no_signal(struct task_struct *tsk, int trapnr, char *str, ... if (fixup_exception(regs, trapnr)) return 0; - if (fixup_bug(regs, trapnr)) - return 0; - As a result, fixup_bugs()'s is_valid_bugaddr() didn't take into account needing to search the exception list first, since that had already happened. So, instead of searching the exception list twice (once in is_valid_bugaddr() and then again in fixup_exception()), just add a simple sanity check to report_bug() that will immediately bail out if a BUG() (or WARN()) entry is not found. Link: http://lkml.kernel.org/r/20180301225934.GA34350@beast Fixes: b8347c219649 ("x86/debug: Handle warnings before the notifier chain, to fix KGDB crash") Signed-off-by: Kees Cook <keescook(a)chromium.org> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Richard Weinberger <richard.weinberger(a)gmail.com> Cc: <stable(a)vger.kernel.org> 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> --- lib/bug.c | 2 ++ 1 file changed, 2 insertions(+) --- a/lib/bug.c +++ b/lib/bug.c @@ -150,6 +150,8 @@ enum bug_trap_type report_bug(unsigned l return BUG_TRAP_TYPE_NONE; bug = find_bug(bugaddr); + if (!bug) + return BUG_TRAP_TYPE_NONE; file = NULL; line = 0; Patches currently in stable-queue which might be from keescook(a)chromium.org are queue-4.14/bug-use-pb-in-bug-and-stack-protector-failure.patch queue-4.14/lib-bug.c-exclude-non-bug-warn-exceptions-from-report_bug.patch

7 years, 9 months

1
0
0 0

Patch "KVM: s390: fix memory overwrites when not using SCA entries" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

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.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-s390-fix-memory-overwrites-when-not-using-sca-entries.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 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 @@ -2119,6 +2119,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.14/kvm-s390-fix-memory-overwrites-when-not-using-sca-entries.patch

7 years, 9 months

1
0
0 0

Patch "kbuild: Handle builtin dtb file names containing hyphens" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

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.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kbuild-handle-builtin-dtb-file-names-containing-hyphens.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 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 @@ -294,11 +294,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.14/mips-bmips-do-not-mask-ipis-during-suspend.patch queue-4.14/mips-ath25-check-for-kzalloc-allocation-failure.patch queue-4.14/kbuild-handle-builtin-dtb-file-names-containing-hyphens.patch queue-4.14/mips-octeon-irq-check-for-null-return-on-kzalloc-allocation.patch

7 years, 9 months

1
0
0 0

Patch "Input: matrix_keypad - fix race when disabling interrupts" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

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.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: input-matrix_keypad-fix-race-when-disabling-interrupts.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 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 @@ -218,8 +218,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.14/input-matrix_keypad-fix-race-when-disabling-interrupts.patch

7 years, 9 months

1
0
0 0

Patch "IB/mlx5: Fix incorrect size of klms in the memory region" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

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.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx5-fix-incorrect-size-of-klms-in-the-memory-region.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 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 @@ -1813,7 +1813,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)) @@ -1825,6 +1824,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.14/ib-mlx5-fix-incorrect-size-of-klms-in-the-memory-region.patch

7 years, 9 months

1
0
0 0

Patch "IB/core: Fix missing RDMA cgroups release in case of failure to register device" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/core: Fix missing RDMA cgroups release in case of failure to register device to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-core-fix-missing-rdma-cgroups-release-in-case-of-failure-to-register-device.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2fb4f4eadd180a50112618dd9c5fef7fc50d4f08 Mon Sep 17 00:00:00 2001 From: Parav Pandit <parav(a)mellanox.com> Date: Sun, 25 Feb 2018 13:39:56 +0200 Subject: IB/core: Fix missing RDMA cgroups release in case of failure to register device From: Parav Pandit <parav(a)mellanox.com> commit 2fb4f4eadd180a50112618dd9c5fef7fc50d4f08 upstream. During IB device registration process, if query_device() fails or if ib_core fails to registers sysfs entries, rdma cgroup cleanup is skipped. Cc: <stable(a)vger.kernel.org> # v4.2+ Fixes: 4be3a4fa51f4 ("IB/core: Fix kernel crash during fail to initialize device") Reviewed-by: Daniel Jurgens <danielj(a)mellanox.com> Signed-off-by: Parav Pandit <parav(a)mellanox.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/core/device.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/infiniband/core/device.c +++ b/drivers/infiniband/core/device.c @@ -534,14 +534,14 @@ int ib_register_device(struct ib_device ret = device->query_device(device, &device->attrs, &uhw); if (ret) { pr_warn("Couldn't query the device attributes\n"); - goto cache_cleanup; + goto cg_cleanup; } ret = ib_device_register_sysfs(device, port_callback); if (ret) { pr_warn("Couldn't register device %s with driver model\n", device->name); - goto cache_cleanup; + goto cg_cleanup; } device->reg_state = IB_DEV_REGISTERED; @@ -557,6 +557,8 @@ int ib_register_device(struct ib_device mutex_unlock(&device_mutex); return 0; +cg_cleanup: + ib_device_unregister_rdmacg(device); cache_cleanup: ib_cache_cleanup_one(device); ib_cache_release_one(device); Patches currently in stable-queue which might be from parav(a)mellanox.com are queue-4.14/ib-core-fix-missing-rdma-cgroups-release-in-case-of-failure-to-register-device.patch

7 years, 9 months

1
0
0 0

Patch "drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-radeon-insist-on-32-bit-dma-for-cedar-on-ppc64-ppc64le.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2c83029cda55a5e7665c7c6326909427d6a01350 Mon Sep 17 00:00:00 2001 From: Ben Crocker <bcrocker(a)redhat.com> Date: Thu, 22 Feb 2018 17:52:19 -0500 Subject: drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE From: Ben Crocker <bcrocker(a)redhat.com> commit 2c83029cda55a5e7665c7c6326909427d6a01350 upstream. In radeon_device_init, set the need_dma32 flag for Cedar chips (e.g. FirePro 2270). This fixes, or at least works around, a bug on PowerPC exposed by last year's commits 8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey) and 253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple) which enabled the 64-bit DMA iommu bypass. This caused the device to freeze, in some cases unrecoverably, and is the subject of several bug reports internal to Red Hat. Signed-off-by: Ben Crocker <bcrocker(a)redhat.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/radeon/radeon_device.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1397,6 +1397,10 @@ int radeon_device_init(struct radeon_dev if ((rdev->flags & RADEON_IS_PCI) && (rdev->family <= CHIP_RS740)) rdev->need_dma32 = true; +#ifdef CONFIG_PPC64 + if (rdev->family == CHIP_CEDAR) + rdev->need_dma32 = true; +#endif dma_bits = rdev->need_dma32 ? 32 : 40; r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits)); Patches currently in stable-queue which might be from bcrocker(a)redhat.com are queue-4.14/drm-radeon-insist-on-32-bit-dma-for-cedar-on-ppc64-ppc64le.patch

7 years, 9 months

1
0
0 0

Patch "drm/radeon: fix KV harvesting" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/radeon: fix KV harvesting to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-radeon-fix-kv-harvesting.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 0b58d90f89545e021d188c289fa142e5ff9e708b Mon Sep 17 00:00:00 2001 From: Alex Deucher <alexander.deucher(a)amd.com> Date: Thu, 1 Mar 2018 11:03:27 -0500 Subject: drm/radeon: fix KV harvesting MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Alex Deucher <alexander.deucher(a)amd.com> commit 0b58d90f89545e021d188c289fa142e5ff9e708b upstream. Always set the graphics values to the max for the asic type. E.g., some 1 RB chips are actually 1 RB chips, others are actually harvested 2 RB chips. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99353 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/radeon/cik.c | 31 ++----------------------------- 1 file changed, 2 insertions(+), 29 deletions(-) --- a/drivers/gpu/drm/radeon/cik.c +++ b/drivers/gpu/drm/radeon/cik.c @@ -3229,35 +3229,8 @@ static void cik_gpu_init(struct radeon_d case CHIP_KAVERI: rdev->config.cik.max_shader_engines = 1; rdev->config.cik.max_tile_pipes = 4; - if ((rdev->pdev->device == 0x1304) || - (rdev->pdev->device == 0x1305) || - (rdev->pdev->device == 0x130C) || - (rdev->pdev->device == 0x130F) || - (rdev->pdev->device == 0x1310) || - (rdev->pdev->device == 0x1311) || - (rdev->pdev->device == 0x131C)) { - rdev->config.cik.max_cu_per_sh = 8; - rdev->config.cik.max_backends_per_se = 2; - } else if ((rdev->pdev->device == 0x1309) || - (rdev->pdev->device == 0x130A) || - (rdev->pdev->device == 0x130D) || - (rdev->pdev->device == 0x1313) || - (rdev->pdev->device == 0x131D)) { - rdev->config.cik.max_cu_per_sh = 6; - rdev->config.cik.max_backends_per_se = 2; - } else if ((rdev->pdev->device == 0x1306) || - (rdev->pdev->device == 0x1307) || - (rdev->pdev->device == 0x130B) || - (rdev->pdev->device == 0x130E) || - (rdev->pdev->device == 0x1315) || - (rdev->pdev->device == 0x1318) || - (rdev->pdev->device == 0x131B)) { - rdev->config.cik.max_cu_per_sh = 4; - rdev->config.cik.max_backends_per_se = 1; - } else { - rdev->config.cik.max_cu_per_sh = 3; - rdev->config.cik.max_backends_per_se = 1; - } + rdev->config.cik.max_cu_per_sh = 8; + rdev->config.cik.max_backends_per_se = 2; rdev->config.cik.max_sh_per_se = 1; rdev->config.cik.max_texture_channel_caches = 4; rdev->config.cik.max_gprs = 256; Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are queue-4.14/drm-amdgpu-notify-sbios-device-ready-before-send-request.patch queue-4.14/workqueue-allow-retrieval-of-current-task-s-work-struct.patch queue-4.14/drm-amd-powerplay-vega10-allow-mclk-switching-with-no-displays.patch queue-4.14/drm-radeon-fix-kv-harvesting.patch queue-4.14/drm-radeon-fix-deadlock-on-runtime-suspend.patch queue-4.14/drm-amdgpu-correct-max-uvd-handles.patch queue-4.14/drm-amd-powerplay-smu7-allow-mclk-switching-with-no-displays.patch queue-4.14/drm-amdgpu-fix-deadlock-on-runtime-suspend.patch queue-4.14/drm-amd-powerplay-fix-power-over-limit-on-fiji.patch queue-4.14/drm-allow-determining-if-current-task-is-output-poll-worker.patch queue-4.14/drm-amdgpu-used-cached-pcie-gen-info-for-si-v2.patch queue-4.14/revert-drm-radeon-pm-autoswitch-power-state-when-in-balanced-mode.patch queue-4.14/drm-amdgpu-fix-kv-harvesting.patch queue-4.14/drm-amdgpu-always-save-uvd-vcpu_bo-in-vm-mode.patch queue-4.14/drm-radeon-insist-on-32-bit-dma-for-cedar-on-ppc64-ppc64le.patch

7 years, 9 months

1
0
0 0

Patch "drm/radeon: Fix deadlock on runtime suspend" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

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.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-radeon-fix-deadlock-on-runtime-suspend.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 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 @@ -900,9 +900,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); @@ -925,8 +927,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; } @@ -1040,9 +1046,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) @@ -1109,8 +1117,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; } @@ -1174,9 +1184,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) @@ -1188,8 +1200,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; } @@ -1252,9 +1268,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; @@ -1437,8 +1455,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; } @@ -1689,9 +1709,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; @@ -1778,8 +1800,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.14/workqueue-allow-retrieval-of-current-task-s-work-struct.patch queue-4.14/drm-radeon-fix-deadlock-on-runtime-suspend.patch queue-4.14/drm-amdgpu-fix-deadlock-on-runtime-suspend.patch queue-4.14/drm-allow-determining-if-current-task-is-output-poll-worker.patch queue-4.14/drm-nouveau-fix-deadlock-on-runtime-suspend.patch

7 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror