From 838500767090a3eddaef93f31b0cfc1046e7c3a2 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 13 Aug 2018 08:46:58 +0200 Subject: [PATCH] 4.9-stable patches added patches: init-rename-and-re-order-boot_cpu_state_init.patch scsi-sr-avoid-that-opening-a-cd-rom-hangs-with-runtime-power-management-enabled.patch --- ...ame-and-re-order-boot_cpu_state_init.patch | 92 ++++++++++++++ ...ith-runtime-power-management-enabled.patch | 118 ++++++++++++++++++ queue-4.9/series | 2 + 3 files changed, 212 insertions(+) create mode 100644 queue-4.9/init-rename-and-re-order-boot_cpu_state_init.patch create mode 100644 queue-4.9/scsi-sr-avoid-that-opening-a-cd-rom-hangs-with-runtime-power-management-enabled.patch diff --git a/queue-4.9/init-rename-and-re-order-boot_cpu_state_init.patch b/queue-4.9/init-rename-and-re-order-boot_cpu_state_init.patch new file mode 100644 index 00000000000..723889e77ad --- /dev/null +++ b/queue-4.9/init-rename-and-re-order-boot_cpu_state_init.patch @@ -0,0 +1,92 @@ +From b5b1404d0815894de0690de8a1ab58269e56eae6 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Sun, 12 Aug 2018 12:19:42 -0700 +Subject: init: rename and re-order boot_cpu_state_init() + +From: Linus Torvalds + +commit b5b1404d0815894de0690de8a1ab58269e56eae6 upstream. + +This is purely a preparatory patch for upcoming changes during the 4.19 +merge window. + +We have a function called "boot_cpu_state_init()" that isn't really +about the bootup cpu state: that is done much earlier by the similarly +named "boot_cpu_init()" (note lack of "state" in name). + +This function initializes some hotplug CPU state, and needs to run after +the percpu data has been properly initialized. It even has a comment to +that effect. + +Except it _doesn't_ actually run after the percpu data has been properly +initialized. On x86 it happens to do that, but on at least arm and +arm64, the percpu base pointers are initialized by the arch-specific +'smp_prepare_boot_cpu()' hook, which ran _after_ boot_cpu_state_init(). + +This had some unexpected results, and in particular we have a patch +pending for the merge window that did the obvious cleanup of using +'this_cpu_write()' in the cpu hotplug init code: + + - per_cpu_ptr(&cpuhp_state, smp_processor_id())->state = CPUHP_ONLINE; + + this_cpu_write(cpuhp_state.state, CPUHP_ONLINE); + +which is obviously the right thing to do. Except because of the +ordering issue, it actually failed miserably and unexpectedly on arm64. + +So this just fixes the ordering, and changes the name of the function to +be 'boot_cpu_hotplug_init()' to make it obvious that it's about cpu +hotplug state, because the core CPU state was supposed to have already +been done earlier. + +Marked for stable, since the (not yet merged) patch that will show this +problem is marked for stable. + +Reported-by: Vlastimil Babka +Reported-by: Mian Yousaf Kaukab +Suggested-by: Catalin Marinas +Acked-by: Thomas Gleixner +Cc: Will Deacon +Cc: stable@kernel.org +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/cpu.h | 2 +- + init/main.c | 2 +- + kernel/cpu.c | 2 +- + 3 files changed, 3 insertions(+), 3 deletions(-) + +--- a/include/linux/cpu.h ++++ b/include/linux/cpu.h +@@ -29,7 +29,7 @@ struct cpu { + }; + + extern void boot_cpu_init(void); +-extern void boot_cpu_state_init(void); ++extern void boot_cpu_hotplug_init(void); + + extern int register_cpu(struct cpu *cpu, int num); + extern struct device *get_cpu_device(unsigned cpu); +--- a/init/main.c ++++ b/init/main.c +@@ -509,8 +509,8 @@ asmlinkage __visible void __init start_k + setup_command_line(command_line); + setup_nr_cpu_ids(); + setup_per_cpu_areas(); +- boot_cpu_state_init(); + smp_prepare_boot_cpu(); /* arch-specific boot-cpu hooks */ ++ boot_cpu_hotplug_init(); + + build_all_zonelists(NULL, NULL); + page_alloc_init(); +--- a/kernel/cpu.c ++++ b/kernel/cpu.c +@@ -1944,7 +1944,7 @@ void __init boot_cpu_init(void) + /* + * Must be called _AFTER_ setting up the per_cpu areas + */ +-void __init boot_cpu_state_init(void) ++void __init boot_cpu_hotplug_init(void) + { + per_cpu_ptr(&cpuhp_state, smp_processor_id())->state = CPUHP_ONLINE; + } diff --git a/queue-4.9/scsi-sr-avoid-that-opening-a-cd-rom-hangs-with-runtime-power-management-enabled.patch b/queue-4.9/scsi-sr-avoid-that-opening-a-cd-rom-hangs-with-runtime-power-management-enabled.patch new file mode 100644 index 00000000000..155f159cd92 --- /dev/null +++ b/queue-4.9/scsi-sr-avoid-that-opening-a-cd-rom-hangs-with-runtime-power-management-enabled.patch @@ -0,0 +1,118 @@ +From 1214fd7b497400d200e3f4e64e2338b303a20949 Mon Sep 17 00:00:00 2001 +From: Bart Van Assche +Date: Thu, 2 Aug 2018 10:44:42 -0700 +Subject: scsi: sr: Avoid that opening a CD-ROM hangs with runtime power management enabled + +From: Bart Van Assche + +commit 1214fd7b497400d200e3f4e64e2338b303a20949 upstream. + +Surround scsi_execute() calls with scsi_autopm_get_device() and +scsi_autopm_put_device(). Note: removing sr_mutex protection from the +scsi_cd_get() and scsi_cd_put() calls is safe because the purpose of +sr_mutex is to serialize cdrom_*() calls. + +This patch avoids that complaints similar to the following appear in the +kernel log if runtime power management is enabled: + +INFO: task systemd-udevd:650 blocked for more than 120 seconds. + Not tainted 4.18.0-rc7-dbg+ #1 +"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. +systemd-udevd D28176 650 513 0x00000104 +Call Trace: +__schedule+0x444/0xfe0 +schedule+0x4e/0xe0 +schedule_preempt_disabled+0x18/0x30 +__mutex_lock+0x41c/0xc70 +mutex_lock_nested+0x1b/0x20 +__blkdev_get+0x106/0x970 +blkdev_get+0x22c/0x5a0 +blkdev_open+0xe9/0x100 +do_dentry_open.isra.19+0x33e/0x570 +vfs_open+0x7c/0xd0 +path_openat+0x6e3/0x1120 +do_filp_open+0x11c/0x1c0 +do_sys_open+0x208/0x2d0 +__x64_sys_openat+0x59/0x70 +do_syscall_64+0x77/0x230 +entry_SYSCALL_64_after_hwframe+0x49/0xbe + +Signed-off-by: Bart Van Assche +Cc: Maurizio Lombardi +Cc: Johannes Thumshirn +Cc: Alan Stern +Cc: +Tested-by: Johannes Thumshirn +Reviewed-by: Johannes Thumshirn +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/sr.c | 29 +++++++++++++++++++++-------- + 1 file changed, 21 insertions(+), 8 deletions(-) + +--- a/drivers/scsi/sr.c ++++ b/drivers/scsi/sr.c +@@ -520,18 +520,26 @@ static int sr_init_command(struct scsi_c + static int sr_block_open(struct block_device *bdev, fmode_t mode) + { + struct scsi_cd *cd; ++ struct scsi_device *sdev; + int ret = -ENXIO; + ++ cd = scsi_cd_get(bdev->bd_disk); ++ if (!cd) ++ goto out; ++ ++ sdev = cd->device; ++ scsi_autopm_get_device(sdev); + check_disk_change(bdev); + + mutex_lock(&sr_mutex); +- cd = scsi_cd_get(bdev->bd_disk); +- if (cd) { +- ret = cdrom_open(&cd->cdi, bdev, mode); +- if (ret) +- scsi_cd_put(cd); +- } ++ ret = cdrom_open(&cd->cdi, bdev, mode); + mutex_unlock(&sr_mutex); ++ ++ scsi_autopm_put_device(sdev); ++ if (ret) ++ scsi_cd_put(cd); ++ ++out: + return ret; + } + +@@ -559,6 +567,8 @@ static int sr_block_ioctl(struct block_d + if (ret) + goto out; + ++ scsi_autopm_get_device(sdev); ++ + /* + * Send SCSI addressing ioctls directly to mid level, send other + * ioctls to cdrom/block level. +@@ -567,15 +577,18 @@ static int sr_block_ioctl(struct block_d + case SCSI_IOCTL_GET_IDLUN: + case SCSI_IOCTL_GET_BUS_NUMBER: + ret = scsi_ioctl(sdev, cmd, argp); +- goto out; ++ goto put; + } + + ret = cdrom_ioctl(&cd->cdi, bdev, mode, cmd, arg); + if (ret != -ENOSYS) +- goto out; ++ goto put; + + ret = scsi_ioctl(sdev, cmd, argp); + ++put: ++ scsi_autopm_put_device(sdev); ++ + out: + mutex_unlock(&sr_mutex); + return ret; diff --git a/queue-4.9/series b/queue-4.9/series index 271ec812dc5..97501840dbe 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -6,3 +6,5 @@ kasan-add-no_sanitize-attribute-for-clang-builds.patch mark-hi-and-tasklet-softirq-synchronous.patch xen-netfront-don-t-cache-skb_shinfo.patch acpi-lpss-add-missing-prv_offset-setting-for-byt-cht-pwm-devices.patch +scsi-sr-avoid-that-opening-a-cd-rom-hangs-with-runtime-power-management-enabled.patch +init-rename-and-re-order-boot_cpu_state_init.patch -- 2.47.3