From: Greg Kroah-Hartman Date: Mon, 20 Jul 2020 12:44:12 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v4.4.231~16 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=7fe1152d3b4900a29f0f30a018528cf0c735596f;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: arm64-ptrace-override-spsr.ss-when-single-stepping-is-enabled.patch dmaengine-fsl-edma-fix-null-pointer-exception-in-fsl_edma_tx_handler.patch fuse-fix-parameter-for-fs_ioc_-get-set-flags.patch hwmon-emc2103-fix-unable-to-change-fan-pwm1_enable-attribute.patch input-i8042-add-lenovo-xiaoxin-air-12-to-i8042-nomux-list.patch irqchip-gic-atomically-update-affinity.patch mei-bus-don-t-clean-driver-pointer.patch mips-fix-build-for-lts-kernel-caused-by-backporting-lpj-adjustment.patch misc-atmel-ssc-lock-with-mutex-instead-of-spinlock.patch sched-fair-handle-case-of-task_h_load-returning-0.patch timer-fix-wheel-index-calculation-on-last-level.patch uio_pdrv_genirq-fix-use-without-device-tree-and-no-interrupt.patch --- diff --git a/queue-4.9/arm64-ptrace-override-spsr.ss-when-single-stepping-is-enabled.patch b/queue-4.9/arm64-ptrace-override-spsr.ss-when-single-stepping-is-enabled.patch new file mode 100644 index 00000000000..a9a20c145c1 --- /dev/null +++ b/queue-4.9/arm64-ptrace-override-spsr.ss-when-single-stepping-is-enabled.patch @@ -0,0 +1,110 @@ +From 3a5a4366cecc25daa300b9a9174f7fdd352b9068 Mon Sep 17 00:00:00 2001 +From: Will Deacon +Date: Thu, 13 Feb 2020 12:06:26 +0000 +Subject: arm64: ptrace: Override SPSR.SS when single-stepping is enabled + +From: Will Deacon + +commit 3a5a4366cecc25daa300b9a9174f7fdd352b9068 upstream. + +Luis reports that, when reverse debugging with GDB, single-step does not +function as expected on arm64: + + | I've noticed, under very specific conditions, that a PTRACE_SINGLESTEP + | request by GDB won't execute the underlying instruction. As a consequence, + | the PC doesn't move, but we return a SIGTRAP just like we would for a + | regular successful PTRACE_SINGLESTEP request. + +The underlying problem is that when the CPU register state is restored +as part of a reverse step, the SPSR.SS bit is cleared and so the hardware +single-step state can transition to the "active-pending" state, causing +an unexpected step exception to be taken immediately if a step operation +is attempted. + +In hindsight, we probably shouldn't have exposed SPSR.SS in the pstate +accessible by the GPR regset, but it's a bit late for that now. Instead, +simply prevent userspace from configuring the bit to a value which is +inconsistent with the TIF_SINGLESTEP state for the task being traced. + +Cc: +Cc: Mark Rutland +Cc: Keno Fischer +Link: https://lore.kernel.org/r/1eed6d69-d53d-9657-1fc9-c089be07f98c@linaro.org +Reported-by: Luis Machado +Tested-by: Luis Machado +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/include/asm/debug-monitors.h | 2 ++ + arch/arm64/kernel/debug-monitors.c | 20 ++++++++++++++++---- + arch/arm64/kernel/ptrace.c | 4 ++-- + 3 files changed, 20 insertions(+), 6 deletions(-) + +--- a/arch/arm64/include/asm/debug-monitors.h ++++ b/arch/arm64/include/asm/debug-monitors.h +@@ -116,6 +116,8 @@ void disable_debug_monitors(enum dbg_act + + void user_rewind_single_step(struct task_struct *task); + void user_fastforward_single_step(struct task_struct *task); ++void user_regs_reset_single_step(struct user_pt_regs *regs, ++ struct task_struct *task); + + void kernel_enable_single_step(struct pt_regs *regs); + void kernel_disable_single_step(void); +--- a/arch/arm64/kernel/debug-monitors.c ++++ b/arch/arm64/kernel/debug-monitors.c +@@ -149,17 +149,20 @@ postcore_initcall(debug_monitors_init); + /* + * Single step API and exception handling. + */ +-static void set_regs_spsr_ss(struct pt_regs *regs) ++static void set_user_regs_spsr_ss(struct user_pt_regs *regs) + { + regs->pstate |= DBG_SPSR_SS; + } +-NOKPROBE_SYMBOL(set_regs_spsr_ss); ++NOKPROBE_SYMBOL(set_user_regs_spsr_ss); + +-static void clear_regs_spsr_ss(struct pt_regs *regs) ++static void clear_user_regs_spsr_ss(struct user_pt_regs *regs) + { + regs->pstate &= ~DBG_SPSR_SS; + } +-NOKPROBE_SYMBOL(clear_regs_spsr_ss); ++NOKPROBE_SYMBOL(clear_user_regs_spsr_ss); ++ ++#define set_regs_spsr_ss(r) set_user_regs_spsr_ss(&(r)->user_regs) ++#define clear_regs_spsr_ss(r) clear_user_regs_spsr_ss(&(r)->user_regs) + + /* EL1 Single Step Handler hooks */ + static LIST_HEAD(step_hook); +@@ -388,6 +391,15 @@ void user_fastforward_single_step(struct + clear_regs_spsr_ss(task_pt_regs(task)); + } + ++void user_regs_reset_single_step(struct user_pt_regs *regs, ++ struct task_struct *task) ++{ ++ if (test_tsk_thread_flag(task, TIF_SINGLESTEP)) ++ set_user_regs_spsr_ss(regs); ++ else ++ clear_user_regs_spsr_ss(regs); ++} ++ + /* Kernel API */ + void kernel_enable_single_step(struct pt_regs *regs) + { +--- a/arch/arm64/kernel/ptrace.c ++++ b/arch/arm64/kernel/ptrace.c +@@ -1447,8 +1447,8 @@ static int valid_native_regs(struct user + */ + int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task) + { +- if (!test_tsk_thread_flag(task, TIF_SINGLESTEP)) +- regs->pstate &= ~DBG_SPSR_SS; ++ /* https://lore.kernel.org/lkml/20191118131525.GA4180@willie-the-truck */ ++ user_regs_reset_single_step(regs, task); + + if (is_compat_thread(task_thread_info(task))) + return valid_compat_regs(regs); diff --git a/queue-4.9/dmaengine-fsl-edma-fix-null-pointer-exception-in-fsl_edma_tx_handler.patch b/queue-4.9/dmaengine-fsl-edma-fix-null-pointer-exception-in-fsl_edma_tx_handler.patch new file mode 100644 index 00000000000..cd03416ebe6 --- /dev/null +++ b/queue-4.9/dmaengine-fsl-edma-fix-null-pointer-exception-in-fsl_edma_tx_handler.patch @@ -0,0 +1,77 @@ +From f5e5677c420346b4e9788051c2e4d750996c428c Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Thu, 11 Jun 2020 14:17:41 +0200 +Subject: dmaengine: fsl-edma: Fix NULL pointer exception in fsl_edma_tx_handler + +From: Krzysztof Kozlowski + +commit f5e5677c420346b4e9788051c2e4d750996c428c upstream. + +NULL pointer exception happens occasionally on serial output initiated +by login timeout. This was reproduced only if kernel was built with +significant debugging options and EDMA driver is used with serial +console. + + col-vf50 login: root + Password: + Login timed out after 60 seconds. + Unable to handle kernel NULL pointer dereference at virtual address 00000044 + Internal error: Oops: 5 [#1] ARM + CPU: 0 PID: 157 Comm: login Not tainted 5.7.0-next-20200610-dirty #4 + Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) + (fsl_edma_tx_handler) from [<8016eb10>] (__handle_irq_event_percpu+0x64/0x304) + (__handle_irq_event_percpu) from [<8016eddc>] (handle_irq_event_percpu+0x2c/0x7c) + (handle_irq_event_percpu) from [<8016ee64>] (handle_irq_event+0x38/0x5c) + (handle_irq_event) from [<801729e4>] (handle_fasteoi_irq+0xa4/0x160) + (handle_fasteoi_irq) from [<8016ddcc>] (generic_handle_irq+0x34/0x44) + (generic_handle_irq) from [<8016e40c>] (__handle_domain_irq+0x54/0xa8) + (__handle_domain_irq) from [<80508bc8>] (gic_handle_irq+0x4c/0x80) + (gic_handle_irq) from [<80100af0>] (__irq_svc+0x70/0x98) + Exception stack(0x8459fe80 to 0x8459fec8) + fe80: 72286b00 e3359f64 00000001 0000412d a0070013 85c98840 85c98840 a0070013 + fea0: 8054e0d4 00000000 00000002 00000000 00000002 8459fed0 8081fbe8 8081fbec + fec0: 60070013 ffffffff + (__irq_svc) from [<8081fbec>] (_raw_spin_unlock_irqrestore+0x30/0x58) + (_raw_spin_unlock_irqrestore) from [<8056cb48>] (uart_flush_buffer+0x88/0xf8) + (uart_flush_buffer) from [<80554e60>] (tty_ldisc_hangup+0x38/0x1ac) + (tty_ldisc_hangup) from [<8054c7f4>] (__tty_hangup+0x158/0x2bc) + (__tty_hangup) from [<80557b90>] (disassociate_ctty.part.1+0x30/0x23c) + (disassociate_ctty.part.1) from [<8011fc18>] (do_exit+0x580/0xba0) + (do_exit) from [<801214f8>] (do_group_exit+0x3c/0xb4) + (do_group_exit) from [<80121580>] (__wake_up_parent+0x0/0x14) + +Issue looks like race condition between interrupt handler fsl_edma_tx_handler() +(called as result of fsl_edma_xfer_desc()) and terminating the transfer with +fsl_edma_terminate_all(). + +The fsl_edma_tx_handler() handles interrupt for a transfer with already freed +edesc and idle==true. + +Fixes: d6be34fbd39b ("dma: Add Freescale eDMA engine driver support") +Signed-off-by: Krzysztof Kozlowski +Reviewed-by: Robin Gong +Cc: +Link: https://lore.kernel.org/r/1591877861-28156-2-git-send-email-krzk@kernel.org +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/dma/fsl-edma.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/dma/fsl-edma.c ++++ b/drivers/dma/fsl-edma.c +@@ -682,6 +682,13 @@ static irqreturn_t fsl_edma_tx_handler(i + fsl_chan = &fsl_edma->chans[ch]; + + spin_lock(&fsl_chan->vchan.lock); ++ ++ if (!fsl_chan->edesc) { ++ /* terminate_all called before */ ++ spin_unlock(&fsl_chan->vchan.lock); ++ continue; ++ } ++ + if (!fsl_chan->edesc->iscyclic) { + list_del(&fsl_chan->edesc->vdesc.node); + vchan_cookie_complete(&fsl_chan->edesc->vdesc); diff --git a/queue-4.9/fuse-fix-parameter-for-fs_ioc_-get-set-flags.patch b/queue-4.9/fuse-fix-parameter-for-fs_ioc_-get-set-flags.patch new file mode 100644 index 00000000000..bcaf25254cd --- /dev/null +++ b/queue-4.9/fuse-fix-parameter-for-fs_ioc_-get-set-flags.patch @@ -0,0 +1,65 @@ +From 31070f6ccec09f3bd4f1e28cd1e592fa4f3ba0b6 Mon Sep 17 00:00:00 2001 +From: Chirantan Ekbote +Date: Tue, 14 Jul 2020 19:26:39 +0900 +Subject: fuse: Fix parameter for FS_IOC_{GET,SET}FLAGS + +From: Chirantan Ekbote + +commit 31070f6ccec09f3bd4f1e28cd1e592fa4f3ba0b6 upstream. + +The ioctl encoding for this parameter is a long but the documentation says +it should be an int and the kernel drivers expect it to be an int. If the +fuse driver treats this as a long it might end up scribbling over the stack +of a userspace process that only allocated enough space for an int. + +This was previously discussed in [1] and a patch for fuse was proposed in +[2]. From what I can tell the patch in [2] was nacked in favor of adding +new, "fixed" ioctls and using those from userspace. However there is still +no "fixed" version of these ioctls and the fact is that it's sometimes +infeasible to change all userspace to use the new one. + +Handling the ioctls specially in the fuse driver seems like the most +pragmatic way for fuse servers to support them without causing crashes in +userspace applications that call them. + +[1]: https://lore.kernel.org/linux-fsdevel/20131126200559.GH20559@hall.aurel32.net/T/ +[2]: https://sourceforge.net/p/fuse/mailman/message/31771759/ + +Signed-off-by: Chirantan Ekbote +Fixes: 59efec7b9039 ("fuse: implement ioctl support") +Cc: +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman + +--- + fs/fuse/file.c | 12 +++++++++++- + 1 file changed, 11 insertions(+), 1 deletion(-) + +--- a/fs/fuse/file.c ++++ b/fs/fuse/file.c +@@ -17,6 +17,7 @@ + #include + #include + #include ++#include + + static const struct file_operations fuse_direct_io_file_operations; + +@@ -2520,7 +2521,16 @@ long fuse_do_ioctl(struct file *file, un + struct iovec *iov = iov_page; + + iov->iov_base = (void __user *)arg; +- iov->iov_len = _IOC_SIZE(cmd); ++ ++ switch (cmd) { ++ case FS_IOC_GETFLAGS: ++ case FS_IOC_SETFLAGS: ++ iov->iov_len = sizeof(int); ++ break; ++ default: ++ iov->iov_len = _IOC_SIZE(cmd); ++ break; ++ } + + if (_IOC_DIR(cmd) & _IOC_WRITE) { + in_iov = iov; diff --git a/queue-4.9/hwmon-emc2103-fix-unable-to-change-fan-pwm1_enable-attribute.patch b/queue-4.9/hwmon-emc2103-fix-unable-to-change-fan-pwm1_enable-attribute.patch new file mode 100644 index 00000000000..2898c993bed --- /dev/null +++ b/queue-4.9/hwmon-emc2103-fix-unable-to-change-fan-pwm1_enable-attribute.patch @@ -0,0 +1,40 @@ +From 14b0e83dc4f1e52b94acaeb85a18fd7fdd46d2dc Mon Sep 17 00:00:00 2001 +From: Vishwas M +Date: Tue, 7 Jul 2020 19:57:47 +0530 +Subject: hwmon: (emc2103) fix unable to change fan pwm1_enable attribute + +From: Vishwas M + +commit 14b0e83dc4f1e52b94acaeb85a18fd7fdd46d2dc upstream. + +This patch fixes a bug which does not let FAN mode to be changed from +sysfs(pwm1_enable). i.e pwm1_enable can not be set to 3, it will always +remain at 0. + +This is caused because the device driver handles the result of +"read_u8_from_i2c(client, REG_FAN_CONF1, &conf_reg)" incorrectly. The +driver thinks an error has occurred if the (result != 0). This has been +fixed by changing the condition to (result < 0). + +Signed-off-by: Vishwas M +Link: https://lore.kernel.org/r/20200707142747.118414-1-vishwas.reddy.vr@gmail.com +Fixes: 9df7305b5a86 ("hwmon: Add driver for SMSC EMC2103 temperature monitor and fan controller") +Cc: stable@vger.kernel.org +Signed-off-by: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hwmon/emc2103.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/hwmon/emc2103.c ++++ b/drivers/hwmon/emc2103.c +@@ -452,7 +452,7 @@ static ssize_t set_pwm_enable(struct dev + } + + result = read_u8_from_i2c(client, REG_FAN_CONF1, &conf_reg); +- if (result) { ++ if (result < 0) { + count = result; + goto err; + } diff --git a/queue-4.9/input-i8042-add-lenovo-xiaoxin-air-12-to-i8042-nomux-list.patch b/queue-4.9/input-i8042-add-lenovo-xiaoxin-air-12-to-i8042-nomux-list.patch new file mode 100644 index 00000000000..4b8bb9c3475 --- /dev/null +++ b/queue-4.9/input-i8042-add-lenovo-xiaoxin-air-12-to-i8042-nomux-list.patch @@ -0,0 +1,39 @@ +From 17d51429da722cd8fc77a365a112f008abf4f8b3 Mon Sep 17 00:00:00 2001 +From: David Pedersen +Date: Mon, 6 Jul 2020 18:48:51 -0700 +Subject: Input: i8042 - add Lenovo XiaoXin Air 12 to i8042 nomux list + +From: David Pedersen + +commit 17d51429da722cd8fc77a365a112f008abf4f8b3 upstream. + +This fixes two finger trackpad scroll on the Lenovo XiaoXin Air 12. +Without nomux, the trackpad behaves as if only one finger is present and +moves the cursor when trying to scroll. + +Signed-off-by: David Pedersen +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20200625133754.291325-1-limero1337@gmail.com +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/input/serio/i8042-x86ia64io.h | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/input/serio/i8042-x86ia64io.h ++++ b/drivers/input/serio/i8042-x86ia64io.h +@@ -430,6 +430,13 @@ static const struct dmi_system_id __init + }, + }, + { ++ /* Lenovo XiaoXin Air 12 */ ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "80UN"), ++ }, ++ }, ++ { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Acer"), + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 1360"), diff --git a/queue-4.9/irqchip-gic-atomically-update-affinity.patch b/queue-4.9/irqchip-gic-atomically-update-affinity.patch new file mode 100644 index 00000000000..da2d11fe06a --- /dev/null +++ b/queue-4.9/irqchip-gic-atomically-update-affinity.patch @@ -0,0 +1,61 @@ +From 005c34ae4b44f085120d7f371121ec7ded677761 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Sun, 21 Jun 2020 14:43:15 +0100 +Subject: irqchip/gic: Atomically update affinity + +From: Marc Zyngier + +commit 005c34ae4b44f085120d7f371121ec7ded677761 upstream. + +The GIC driver uses a RMW sequence to update the affinity, and +relies on the gic_lock_irqsave/gic_unlock_irqrestore sequences +to update it atomically. + +But these sequences only expand into anything meaningful if +the BL_SWITCHER option is selected, which almost never happens. + +It also turns out that using a RMW and locks is just as silly, +as the GIC distributor supports byte accesses for the GICD_TARGETRn +registers, which when used make the update atomic by definition. + +Drop the terminally broken code and replace it by a byte write. + +Fixes: 04c8b0f82c7d ("irqchip/gic: Make locking a BL_SWITCHER only feature") +Cc: stable@vger.kernel.org +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman + + +--- + drivers/irqchip/irq-gic.c | 13 +++---------- + 1 file changed, 3 insertions(+), 10 deletions(-) + +--- a/drivers/irqchip/irq-gic.c ++++ b/drivers/irqchip/irq-gic.c +@@ -324,10 +324,8 @@ static int gic_irq_set_vcpu_affinity(str + static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val, + bool force) + { +- void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + (gic_irq(d) & ~3); +- unsigned int cpu, shift = (gic_irq(d) % 4) * 8; +- u32 val, mask, bit; +- unsigned long flags; ++ void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + gic_irq(d); ++ unsigned int cpu; + + if (!force) + cpu = cpumask_any_and(mask_val, cpu_online_mask); +@@ -337,12 +335,7 @@ static int gic_set_affinity(struct irq_d + if (cpu >= NR_GIC_CPU_IF || cpu >= nr_cpu_ids) + return -EINVAL; + +- gic_lock_irqsave(flags); +- mask = 0xff << shift; +- bit = gic_cpu_map[cpu] << shift; +- val = readl_relaxed(reg) & ~mask; +- writel_relaxed(val | bit, reg); +- gic_unlock_irqrestore(flags); ++ writeb_relaxed(gic_cpu_map[cpu], reg); + + return IRQ_SET_MASK_OK_DONE; + } diff --git a/queue-4.9/mei-bus-don-t-clean-driver-pointer.patch b/queue-4.9/mei-bus-don-t-clean-driver-pointer.patch new file mode 100644 index 00000000000..c3ebe1790e3 --- /dev/null +++ b/queue-4.9/mei-bus-don-t-clean-driver-pointer.patch @@ -0,0 +1,50 @@ +From e852c2c251ed9c23ae6e3efebc5ec49adb504207 Mon Sep 17 00:00:00 2001 +From: Alexander Usyskin +Date: Mon, 29 Jun 2020 01:53:59 +0300 +Subject: mei: bus: don't clean driver pointer + +From: Alexander Usyskin + +commit e852c2c251ed9c23ae6e3efebc5ec49adb504207 upstream. + +It's not needed to set driver to NULL in mei_cl_device_remove() +which is bus_type remove() handler as this is done anyway +in __device_release_driver(). + +Actually this is causing an endless loop in driver_detach() +on ubuntu patched kernel, while removing (rmmod) the mei_hdcp module. +The reason list_empty(&drv->p->klist_devices.k_list) is always not-empty. +as the check is always true in __device_release_driver() + if (dev->driver != drv) + return; + +The non upstream patch is causing this behavior, titled: +'vfio -- release device lock before userspace requests' + +Nevertheless the fix is correct also for the upstream. + +Link: https://patchwork.ozlabs.org/project/ubuntu-kernel/patch/20180912085046.3401-2-apw@canonical.com/ +Cc: +Cc: Andy Whitcroft +Signed-off-by: Alexander Usyskin +Signed-off-by: Tomas Winkler +Link: https://lore.kernel.org/r/20200628225359.2185929-1-tomas.winkler@intel.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/misc/mei/bus.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/misc/mei/bus.c ++++ b/drivers/misc/mei/bus.c +@@ -639,9 +639,8 @@ static int mei_cl_device_remove(struct d + ret = cldrv->remove(cldev); + + module_put(THIS_MODULE); +- dev->driver = NULL; +- return ret; + ++ return ret; + } + + static ssize_t name_show(struct device *dev, struct device_attribute *a, diff --git a/queue-4.9/mips-fix-build-for-lts-kernel-caused-by-backporting-lpj-adjustment.patch b/queue-4.9/mips-fix-build-for-lts-kernel-caused-by-backporting-lpj-adjustment.patch new file mode 100644 index 00000000000..ad2906bb6aa --- /dev/null +++ b/queue-4.9/mips-fix-build-for-lts-kernel-caused-by-backporting-lpj-adjustment.patch @@ -0,0 +1,62 @@ +From chenhc@lemote.com Mon Jul 20 14:10:23 2020 +From: Huacai Chen +Date: Thu, 16 Jul 2020 17:39:29 +0800 +Subject: MIPS: Fix build for LTS kernel caused by backporting lpj adjustment +To: Thomas Bogendoerfer +Cc: linux-mips@vger.kernel.org, Fuxin Zhang , Zhangjin Wu , Huacai Chen , Jiaxun Yang , Huacai Chen , Serge Semin , "Stable # 4 . 4/4 . 9/4 . 14/4 . 19" +Message-ID: <1594892369-28060-1-git-send-email-chenhc@lemote.com> + +From: Huacai Chen + +Commit ed26aacfb5f71eecb20a ("mips: Add udelay lpj numbers adjustment") +has backported to 4.4~5.4, but the "struct cpufreq_freqs" (and also the +cpufreq notifier machanism) of 4.4~4.19 are different from the upstream +kernel. These differences cause build errors, and this patch can fix the +build. + +Cc: Serge Semin +Cc: Stable # 4.4/4.9/4.14/4.19 +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman + +--- + arch/mips/kernel/time.c | 13 ++++--------- + 1 file changed, 4 insertions(+), 9 deletions(-) + +--- a/arch/mips/kernel/time.c ++++ b/arch/mips/kernel/time.c +@@ -40,10 +40,8 @@ static unsigned long glb_lpj_ref_freq; + static int cpufreq_callback(struct notifier_block *nb, + unsigned long val, void *data) + { +- struct cpufreq_freqs *freq = data; +- struct cpumask *cpus = freq->policy->cpus; +- unsigned long lpj; + int cpu; ++ struct cpufreq_freqs *freq = data; + + /* + * Skip lpj numbers adjustment if the CPU-freq transition is safe for +@@ -64,6 +62,7 @@ static int cpufreq_callback(struct notif + } + } + ++ cpu = freq->cpu; + /* + * Adjust global lpj variable and per-CPU udelay_val number in + * accordance with the new CPU frequency. +@@ -74,12 +73,8 @@ static int cpufreq_callback(struct notif + glb_lpj_ref_freq, + freq->new); + +- for_each_cpu(cpu, cpus) { +- lpj = cpufreq_scale(per_cpu(pcp_lpj_ref, cpu), +- per_cpu(pcp_lpj_ref_freq, cpu), +- freq->new); +- cpu_data[cpu].udelay_val = (unsigned int)lpj; +- } ++ cpu_data[cpu].udelay_val = cpufreq_scale(per_cpu(pcp_lpj_ref, cpu), ++ per_cpu(pcp_lpj_ref_freq, cpu), freq->new); + } + + return NOTIFY_OK; diff --git a/queue-4.9/misc-atmel-ssc-lock-with-mutex-instead-of-spinlock.patch b/queue-4.9/misc-atmel-ssc-lock-with-mutex-instead-of-spinlock.patch new file mode 100644 index 00000000000..db492005767 --- /dev/null +++ b/queue-4.9/misc-atmel-ssc-lock-with-mutex-instead-of-spinlock.patch @@ -0,0 +1,118 @@ +From b037d60a3b1d1227609fd858fa34321f41829911 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Micha=C5=82=20Miros=C5=82aw?= +Date: Wed, 24 Jun 2020 13:35:41 +0200 +Subject: misc: atmel-ssc: lock with mutex instead of spinlock +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Michał Mirosław + +commit b037d60a3b1d1227609fd858fa34321f41829911 upstream. + +Uninterruptible context is not needed in the driver and causes lockdep +warning because of mutex taken in of_alias_get_id(). Convert the lock to +mutex to avoid the issue. + +Cc: stable@vger.kernel.org +Fixes: 099343c64e16 ("ARM: at91: atmel-ssc: add device tree support") +Signed-off-by: Michał Mirosław +Link: https://lore.kernel.org/r/50f0d7fa107f318296afb49477c3571e4d6978c5.1592998403.git.mirq-linux@rere.qmqm.pl +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/misc/atmel-ssc.c | 24 ++++++++++++------------ + 1 file changed, 12 insertions(+), 12 deletions(-) + +--- a/drivers/misc/atmel-ssc.c ++++ b/drivers/misc/atmel-ssc.c +@@ -13,7 +13,7 @@ + #include + #include + #include +-#include ++#include + #include + #include + #include +@@ -21,7 +21,7 @@ + #include + + /* Serialize access to ssc_list and user count */ +-static DEFINE_SPINLOCK(user_lock); ++static DEFINE_MUTEX(user_lock); + static LIST_HEAD(ssc_list); + + struct ssc_device *ssc_request(unsigned int ssc_num) +@@ -29,7 +29,7 @@ struct ssc_device *ssc_request(unsigned + int ssc_valid = 0; + struct ssc_device *ssc; + +- spin_lock(&user_lock); ++ mutex_lock(&user_lock); + list_for_each_entry(ssc, &ssc_list, list) { + if (ssc->pdev->dev.of_node) { + if (of_alias_get_id(ssc->pdev->dev.of_node, "ssc") +@@ -45,18 +45,18 @@ struct ssc_device *ssc_request(unsigned + } + + if (!ssc_valid) { +- spin_unlock(&user_lock); ++ mutex_unlock(&user_lock); + pr_err("ssc: ssc%d platform device is missing\n", ssc_num); + return ERR_PTR(-ENODEV); + } + + if (ssc->user) { +- spin_unlock(&user_lock); ++ mutex_unlock(&user_lock); + dev_dbg(&ssc->pdev->dev, "module busy\n"); + return ERR_PTR(-EBUSY); + } + ssc->user++; +- spin_unlock(&user_lock); ++ mutex_unlock(&user_lock); + + clk_prepare(ssc->clk); + +@@ -68,14 +68,14 @@ void ssc_free(struct ssc_device *ssc) + { + bool disable_clk = true; + +- spin_lock(&user_lock); ++ mutex_lock(&user_lock); + if (ssc->user) + ssc->user--; + else { + disable_clk = false; + dev_dbg(&ssc->pdev->dev, "device already free\n"); + } +- spin_unlock(&user_lock); ++ mutex_unlock(&user_lock); + + if (disable_clk) + clk_unprepare(ssc->clk); +@@ -195,9 +195,9 @@ static int ssc_probe(struct platform_dev + return -ENXIO; + } + +- spin_lock(&user_lock); ++ mutex_lock(&user_lock); + list_add_tail(&ssc->list, &ssc_list); +- spin_unlock(&user_lock); ++ mutex_unlock(&user_lock); + + platform_set_drvdata(pdev, ssc); + +@@ -211,9 +211,9 @@ static int ssc_remove(struct platform_de + { + struct ssc_device *ssc = platform_get_drvdata(pdev); + +- spin_lock(&user_lock); ++ mutex_lock(&user_lock); + list_del(&ssc->list); +- spin_unlock(&user_lock); ++ mutex_unlock(&user_lock); + + return 0; + } diff --git a/queue-4.9/sched-fair-handle-case-of-task_h_load-returning-0.patch b/queue-4.9/sched-fair-handle-case-of-task_h_load-returning-0.patch new file mode 100644 index 00000000000..82b5325e1ee --- /dev/null +++ b/queue-4.9/sched-fair-handle-case-of-task_h_load-returning-0.patch @@ -0,0 +1,57 @@ +From 01cfcde9c26d8555f0e6e9aea9d6049f87683998 Mon Sep 17 00:00:00 2001 +From: Vincent Guittot +Date: Fri, 10 Jul 2020 17:24:26 +0200 +Subject: sched/fair: handle case of task_h_load() returning 0 + +From: Vincent Guittot + +commit 01cfcde9c26d8555f0e6e9aea9d6049f87683998 upstream. + +task_h_load() can return 0 in some situations like running stress-ng +mmapfork, which forks thousands of threads, in a sched group on a 224 cores +system. The load balance doesn't handle this correctly because +env->imbalance never decreases and it will stop pulling tasks only after +reaching loop_max, which can be equal to the number of running tasks of +the cfs. Make sure that imbalance will be decreased by at least 1. + +misfit task is the other feature that doesn't handle correctly such +situation although it's probably more difficult to face the problem +because of the smaller number of CPUs and running tasks on heterogenous +system. + +We can't simply ensure that task_h_load() returns at least one because it +would imply to handle underflow in other places. + +Signed-off-by: Vincent Guittot +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Valentin Schneider +Reviewed-by: Dietmar Eggemann +Tested-by: Dietmar Eggemann +Cc: # v4.4+ +Link: https://lkml.kernel.org/r/20200710152426.16981-1-vincent.guittot@linaro.org +Signed-off-by: Greg Kroah-Hartman + + +--- + kernel/sched/fair.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +--- a/kernel/sched/fair.c ++++ b/kernel/sched/fair.c +@@ -6561,7 +6561,15 @@ static int detach_tasks(struct lb_env *e + if (!can_migrate_task(p, env)) + goto next; + +- load = task_h_load(p); ++ /* ++ * Depending of the number of CPUs and tasks and the ++ * cgroup hierarchy, task_h_load() can return a null ++ * value. Make sure that env->imbalance decreases ++ * otherwise detach_tasks() will stop only after ++ * detaching up to loop_max tasks. ++ */ ++ load = max_t(unsigned long, task_h_load(p), 1); ++ + + if (sched_feat(LB_MIN) && load < 16 && !env->sd->nr_balance_failed) + goto next; diff --git a/queue-4.9/series b/queue-4.9/series index bb2f4d68c85..97a85283a81 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -72,3 +72,15 @@ usb-serial-ch341-add-new-product-id-for-ch340.patch usb-serial-option-add-gosuncn-gm500-series.patch usb-serial-option-add-quectel-eg95-lte-modem.patch virtio-virtio_console-add-missing-module_device_table-for-rproc-serial.patch +fuse-fix-parameter-for-fs_ioc_-get-set-flags.patch +mei-bus-don-t-clean-driver-pointer.patch +input-i8042-add-lenovo-xiaoxin-air-12-to-i8042-nomux-list.patch +uio_pdrv_genirq-fix-use-without-device-tree-and-no-interrupt.patch +timer-fix-wheel-index-calculation-on-last-level.patch +mips-fix-build-for-lts-kernel-caused-by-backporting-lpj-adjustment.patch +hwmon-emc2103-fix-unable-to-change-fan-pwm1_enable-attribute.patch +dmaengine-fsl-edma-fix-null-pointer-exception-in-fsl_edma_tx_handler.patch +misc-atmel-ssc-lock-with-mutex-instead-of-spinlock.patch +arm64-ptrace-override-spsr.ss-when-single-stepping-is-enabled.patch +sched-fair-handle-case-of-task_h_load-returning-0.patch +irqchip-gic-atomically-update-affinity.patch diff --git a/queue-4.9/timer-fix-wheel-index-calculation-on-last-level.patch b/queue-4.9/timer-fix-wheel-index-calculation-on-last-level.patch new file mode 100644 index 00000000000..02a3639a0e0 --- /dev/null +++ b/queue-4.9/timer-fix-wheel-index-calculation-on-last-level.patch @@ -0,0 +1,44 @@ +From e2a71bdea81690b6ef11f4368261ec6f5b6891aa Mon Sep 17 00:00:00 2001 +From: Frederic Weisbecker +Date: Fri, 17 Jul 2020 16:05:40 +0200 +Subject: timer: Fix wheel index calculation on last level + +From: Frederic Weisbecker + +commit e2a71bdea81690b6ef11f4368261ec6f5b6891aa upstream. + +When an expiration delta falls into the last level of the wheel, that delta +has be compared against the maximum possible delay and reduced to fit in if +necessary. + +However instead of comparing the delta against the maximum, the code +compares the actual expiry against the maximum. Then instead of fixing the +delta to fit in, it sets the maximum delta as the expiry value. + +This can result in various undesired outcomes, the worst possible one +being a timer expiring 15 days ahead to fire immediately. + +Fixes: 500462a9de65 ("timers: Switch to a non-cascading wheel") +Signed-off-by: Frederic Weisbecker +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20200717140551.29076-2-frederic@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/time/timer.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/time/timer.c ++++ b/kernel/time/timer.c +@@ -500,8 +500,8 @@ static int calc_wheel_index(unsigned lon + * Force expire obscene large timeouts to expire at the + * capacity limit of the wheel. + */ +- if (expires >= WHEEL_TIMEOUT_CUTOFF) +- expires = WHEEL_TIMEOUT_MAX; ++ if (delta >= WHEEL_TIMEOUT_CUTOFF) ++ expires = clk + WHEEL_TIMEOUT_MAX; + + idx = calc_index(expires, LVL_DEPTH - 1); + } diff --git a/queue-4.9/uio_pdrv_genirq-fix-use-without-device-tree-and-no-interrupt.patch b/queue-4.9/uio_pdrv_genirq-fix-use-without-device-tree-and-no-interrupt.patch new file mode 100644 index 00000000000..20ae56f8ac3 --- /dev/null +++ b/queue-4.9/uio_pdrv_genirq-fix-use-without-device-tree-and-no-interrupt.patch @@ -0,0 +1,42 @@ +From bf12fdf0ab728ca8e5933aac46dd972c0dd0421e Mon Sep 17 00:00:00 2001 +From: Esben Haabendal +Date: Wed, 1 Jul 2020 16:56:58 +0200 +Subject: uio_pdrv_genirq: fix use without device tree and no interrupt + +From: Esben Haabendal + +commit bf12fdf0ab728ca8e5933aac46dd972c0dd0421e upstream. + +While e3a3c3a20555 ("UIO: fix uio_pdrv_genirq with device tree but no +interrupt") added support for using uio_pdrv_genirq for devices without +interrupt for device tree platforms, the removal of uio_pdrv in +26dac3c49d56 ("uio: Remove uio_pdrv and use uio_pdrv_genirq instead") +broke the support for non device tree platforms. + +This change fixes this, so that uio_pdrv_genirq can be used without +interrupt on all platforms. + +This still leaves the support that uio_pdrv had for custom interrupt +handler lacking, as uio_pdrv_genirq does not handle it (yet). + +Fixes: 26dac3c49d56 ("uio: Remove uio_pdrv and use uio_pdrv_genirq instead") +Signed-off-by: Esben Haabendal +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20200701145659.3978-3-esben@geanix.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/uio/uio_pdrv_genirq.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/uio/uio_pdrv_genirq.c ++++ b/drivers/uio/uio_pdrv_genirq.c +@@ -148,7 +148,7 @@ static int uio_pdrv_genirq_probe(struct + if (!uioinfo->irq) { + ret = platform_get_irq(pdev, 0); + uioinfo->irq = ret; +- if (ret == -ENXIO && pdev->dev.of_node) ++ if (ret == -ENXIO) + uioinfo->irq = UIO_IRQ_NONE; + else if (ret < 0) { + dev_err(&pdev->dev, "failed to get IRQ\n");