From: Greg Kroah-Hartman Date: Sun, 11 Jul 2021 13:14:05 +0000 (+0200) Subject: 4.14-stable patches X-Git-Tag: v5.4.132~37 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d34448b9acdbac9e29d947eb68a93be9ff4f0c5d;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: arm-dts-at91-sama5d4-fix-pinctrl-muxing.patch ath9k-fix-kernel-null-pointer-dereference-during-ath_reset_internal.patch btrfs-clear-defrag-status-of-a-root-if-starting-transaction-fails.patch btrfs-send-fix-invalid-path-for-unlink-operations-after-parent-orphanization.patch can-bcm-delay-release-of-struct-bcm_op-after-synchronize_rcu.patch can-gw-synchronize-rcu-operations-before-removing-gw-job-entry.patch can-peak_pciefd-pucan_handle_status-fix-a-potential-starvation-issue-in-tx-path.patch ext4-cleanup-in-core-orphan-list-if-ext4_truncate-failed-to-get-a-transaction-handle.patch ext4-correct-the-cache_nr-in-tracepoint-ext4_es_shrink_exit.patch ext4-fix-avefreec-in-find_group_orlov.patch ext4-fix-kernel-infoleak-via-ext4_extent_header.patch ext4-remove-check-for-zero-nr_to_scan-in-ext4_es_scan.patch ext4-use-ext4_grp_locked_error-in-mb_find_extent.patch fuse-check-connected-before-queueing-on-fpq-io.patch iio-ltr501-ltr501_read_ps-add-missing-endianness-conversion.patch iio-ltr501-ltr559-fix-initialization-of-ltr501_als_contr.patch iio-ltr501-mark-register-holding-upper-8-bits-of-als_data-0-1-and-ps_data-as-volatile-too.patch rsi-assign-beacon-rate-settings-to-the-correct-rate_info-descriptor-field.patch rtc-stm32-fix-unbalanced-clk_disable_unprepare-on-probe-error-path.patch s390-cio-dont-call-css_wait_for_slow_path-inside-a-lock.patch seq_buf-make-trace_seq_putmem_hex-support-data-longer-than-8.patch serial-sh-sci-stop-dmaengine-transfer-in-sci_stop_tx.patch serial_cs-add-option-international-gsm-ready-56k-isdn-modem.patch serial_cs-remove-wrong-globetrotter.cis-entry.patch ssb-sdio-don-t-overwrite-const-buffer-if-block_write-fails.patch sunrpc-fix-the-batch-tasks-count-wraparound.patch sunrpc-should-wake-up-the-privileged-task-firstly.patch --- diff --git a/queue-4.14/arm-dts-at91-sama5d4-fix-pinctrl-muxing.patch b/queue-4.14/arm-dts-at91-sama5d4-fix-pinctrl-muxing.patch new file mode 100644 index 00000000000..0e2ff793da3 --- /dev/null +++ b/queue-4.14/arm-dts-at91-sama5d4-fix-pinctrl-muxing.patch @@ -0,0 +1,35 @@ +From 253adffb0e98eaf6da2e7cf73ae68695e21f2f3c Mon Sep 17 00:00:00 2001 +From: Ludovic Desroches +Date: Fri, 25 Oct 2019 10:42:10 +0200 +Subject: ARM: dts: at91: sama5d4: fix pinctrl muxing + +From: Ludovic Desroches + +commit 253adffb0e98eaf6da2e7cf73ae68695e21f2f3c upstream. + +Fix pinctrl muxing, PD28, PD29 and PD31 can be muxed to peripheral A. It +allows to use SCK0, SCK1 and SPI0_NPCS2 signals. + +Signed-off-by: Ludovic Desroches +Fixes: 679f8d92bb01 ("ARM: at91/dt: sama5d4: add pioD pin mux mask and enable pioD") +Cc: stable@vger.kernel.org # v4.4+ +Reviewed-by: Claudiu Beznea +Signed-off-by: Nicolas Ferre +Link: https://lore.kernel.org/r/20191025084210.14726-1-ludovic.desroches@microchip.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/boot/dts/sama5d4.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/boot/dts/sama5d4.dtsi ++++ b/arch/arm/boot/dts/sama5d4.dtsi +@@ -1374,7 +1374,7 @@ + 0xffffffff 0x3ffcfe7c 0x1c010101 /* pioA */ + 0x7fffffff 0xfffccc3a 0x3f00cc3a /* pioB */ + 0xffffffff 0x3ff83fff 0xff00ffff /* pioC */ +- 0x0003ff00 0x8002a800 0x00000000 /* pioD */ ++ 0xb003ff00 0x8002a800 0x00000000 /* pioD */ + 0xffffffff 0x7fffffff 0x76fff1bf /* pioE */ + >; + diff --git a/queue-4.14/ath9k-fix-kernel-null-pointer-dereference-during-ath_reset_internal.patch b/queue-4.14/ath9k-fix-kernel-null-pointer-dereference-during-ath_reset_internal.patch new file mode 100644 index 00000000000..99c89bc6d6e --- /dev/null +++ b/queue-4.14/ath9k-fix-kernel-null-pointer-dereference-during-ath_reset_internal.patch @@ -0,0 +1,117 @@ +From fb312ac5ccb007e843f982b38d4d6886ba4b32f2 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Pali=20Roh=C3=A1r?= +Date: Mon, 31 May 2021 17:41:27 +0300 +Subject: ath9k: Fix kernel NULL pointer dereference during ath_reset_internal() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Pali Rohár + +commit fb312ac5ccb007e843f982b38d4d6886ba4b32f2 upstream. + +I got this crash more times during debugging of PCIe controller and crash +happens somehow at the time when PCIe kernel code started link retraining (as +part of ASPM code) when at the same time PCIe link went down and ath9k probably +executed hw reset procedure. + +Currently I'm not able to reproduce this issue as it looks like to be +some race condition between link training, ASPM, link down and reset +path. And as always, race conditions which depends on more input +parameters are hard to reproduce as it depends on precise timings. + +But it is clear that pointers are zero in this case and should be +properly filled as same code pattern is used in ath9k_stop() function. +Anyway I was able to reproduce this crash by manually triggering ath +reset worker prior putting card up. I created simple patch to export +reset functionality via debugfs and use it to "simulate" of triggering +reset. s proved that NULL-pointer dereference issue is there. + +Function ath9k_hw_reset() is dereferencing chan structure pointer, so it +needs to be non-NULL pointer. + +Function ath9k_stop() already contains code which sets ah->curchan to valid +non-NULL pointer prior calling ath9k_hw_reset() function. + +Add same code pattern also into ath_reset_internal() function to prevent +kernel NULL pointer dereference in ath9k_hw_reset() function. + +This change fixes kernel NULL pointer dereference in ath9k_hw_reset() which +is caused by calling ath9k_hw_reset() from ath_reset_internal() with NULL +chan structure. + + [ 45.334305] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 + [ 45.344417] Mem abort info: + [ 45.347301] ESR = 0x96000005 + [ 45.350448] EC = 0x25: DABT (current EL), IL = 32 bits + [ 45.356166] SET = 0, FnV = 0 + [ 45.359350] EA = 0, S1PTW = 0 + [ 45.362596] Data abort info: + [ 45.365756] ISV = 0, ISS = 0x00000005 + [ 45.369735] CM = 0, WnR = 0 + [ 45.372814] user pgtable: 4k pages, 39-bit VAs, pgdp=000000000685d000 + [ 45.379663] [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 + [ 45.388856] Internal error: Oops: 96000005 [#1] SMP + [ 45.393897] Modules linked in: ath9k ath9k_common ath9k_hw + [ 45.399574] CPU: 1 PID: 309 Comm: kworker/u4:2 Not tainted 5.12.0-rc2-dirty #785 + [ 45.414746] Workqueue: phy0 ath_reset_work [ath9k] + [ 45.419713] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) + [ 45.425910] pc : ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw] + [ 45.431234] lr : ath9k_hw_reset+0xc0/0x1c48 [ath9k_hw] + [ 45.436548] sp : ffffffc0118dbca0 + [ 45.439961] x29: ffffffc0118dbca0 x28: 0000000000000000 + [ 45.445442] x27: ffffff800dee4080 x26: 0000000000000000 + [ 45.450923] x25: ffffff800df9b9d8 x24: 0000000000000000 + [ 45.456404] x23: ffffffc0115f6000 x22: ffffffc008d0d408 + [ 45.461885] x21: ffffff800dee5080 x20: ffffff800df9b9d8 + [ 45.467366] x19: 0000000000000000 x18: 0000000000000000 + [ 45.472846] x17: 0000000000000000 x16: 0000000000000000 + [ 45.478326] x15: 0000000000000010 x14: ffffffffffffffff + [ 45.483807] x13: ffffffc0918db94f x12: ffffffc011498720 + [ 45.489289] x11: 0000000000000003 x10: ffffffc0114806e0 + [ 45.494770] x9 : ffffffc01014b2ec x8 : 0000000000017fe8 + [ 45.500251] x7 : c0000000ffffefff x6 : 0000000000000001 + [ 45.505733] x5 : 0000000000000000 x4 : 0000000000000000 + [ 45.511213] x3 : 0000000000000000 x2 : ffffff801fece870 + [ 45.516693] x1 : ffffffc00eded000 x0 : 000000000000003f + [ 45.522174] Call trace: + [ 45.524695] ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw] + [ 45.529653] ath_reset_internal+0x1a8/0x2b8 [ath9k] + [ 45.534696] ath_reset_work+0x2c/0x40 [ath9k] + [ 45.539198] process_one_work+0x210/0x480 + [ 45.543339] worker_thread+0x5c/0x510 + [ 45.547115] kthread+0x12c/0x130 + [ 45.550445] ret_from_fork+0x10/0x1c + [ 45.554138] Code: 910922c2 9117e021 95ff0398 b4000294 (b9400a61) + [ 45.560430] ---[ end trace 566410ba90b50e8b ]--- + [ 45.565193] Kernel panic - not syncing: Oops: Fatal exception in interrupt + [ 45.572282] SMP: stopping secondary CPUs + [ 45.576331] Kernel Offset: disabled + [ 45.579924] CPU features: 0x00040002,0000200c + [ 45.584416] Memory Limit: none + [ 45.587564] Rebooting in 3 seconds.. + +Signed-off-by: Pali Rohár +Cc: stable@vger.kernel.org +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20210402122653.24014-1-pali@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/ath/ath9k/main.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/net/wireless/ath/ath9k/main.c ++++ b/drivers/net/wireless/ath/ath9k/main.c +@@ -303,6 +303,11 @@ static int ath_reset_internal(struct ath + hchan = ah->curchan; + } + ++ if (!hchan) { ++ fastcc = false; ++ hchan = ath9k_cmn_get_channel(sc->hw, ah, &sc->cur_chan->chandef); ++ } ++ + if (!ath_prepare_reset(sc)) + fastcc = false; + diff --git a/queue-4.14/btrfs-clear-defrag-status-of-a-root-if-starting-transaction-fails.patch b/queue-4.14/btrfs-clear-defrag-status-of-a-root-if-starting-transaction-fails.patch new file mode 100644 index 00000000000..ed841df8687 --- /dev/null +++ b/queue-4.14/btrfs-clear-defrag-status-of-a-root-if-starting-transaction-fails.patch @@ -0,0 +1,41 @@ +From 6819703f5a365c95488b07066a8744841bf14231 Mon Sep 17 00:00:00 2001 +From: David Sterba +Date: Tue, 7 Jul 2020 18:30:06 +0200 +Subject: btrfs: clear defrag status of a root if starting transaction fails + +From: David Sterba + +commit 6819703f5a365c95488b07066a8744841bf14231 upstream. + +The defrag loop processes leaves in batches and starting transaction for +each. The whole defragmentation on a given root is protected by a bit +but in case the transaction fails, the bit is not cleared + +In case the transaction fails the bit would prevent starting +defragmentation again, so make sure it's cleared. + +CC: stable@vger.kernel.org # 4.4+ +Reviewed-by: Qu Wenruo +Reviewed-by: Anand Jain +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/transaction.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/fs/btrfs/transaction.c ++++ b/fs/btrfs/transaction.c +@@ -1319,8 +1319,10 @@ int btrfs_defrag_root(struct btrfs_root + + while (1) { + trans = btrfs_start_transaction(root, 0); +- if (IS_ERR(trans)) +- return PTR_ERR(trans); ++ if (IS_ERR(trans)) { ++ ret = PTR_ERR(trans); ++ break; ++ } + + ret = btrfs_defrag_leaves(trans, root); + diff --git a/queue-4.14/btrfs-send-fix-invalid-path-for-unlink-operations-after-parent-orphanization.patch b/queue-4.14/btrfs-send-fix-invalid-path-for-unlink-operations-after-parent-orphanization.patch new file mode 100644 index 00000000000..0f040a7eacf --- /dev/null +++ b/queue-4.14/btrfs-send-fix-invalid-path-for-unlink-operations-after-parent-orphanization.patch @@ -0,0 +1,172 @@ +From d8ac76cdd1755b21e8c008c28d0b7251c0b14986 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Wed, 9 Jun 2021 11:25:03 +0100 +Subject: btrfs: send: fix invalid path for unlink operations after parent orphanization + +From: Filipe Manana + +commit d8ac76cdd1755b21e8c008c28d0b7251c0b14986 upstream. + +During an incremental send operation, when processing the new references +for the current inode, we might send an unlink operation for another inode +that has a conflicting path and has more than one hard link. However this +path was computed and cached before we processed previous new references +for the current inode. We may have orphanized a directory of that path +while processing a previous new reference, in which case the path will +be invalid and cause the receiver process to fail. + +The following reproducer triggers the problem and explains how/why it +happens in its comments: + + $ cat test-send-unlink.sh + #!/bin/bash + + DEV=/dev/sdi + MNT=/mnt/sdi + + mkfs.btrfs -f $DEV >/dev/null + mount $DEV $MNT + + # Create our test files and directory. Inode 259 (file3) has two hard + # links. + touch $MNT/file1 + touch $MNT/file2 + touch $MNT/file3 + + mkdir $MNT/A + ln $MNT/file3 $MNT/A/hard_link + + # Filesystem looks like: + # + # . (ino 256) + # |----- file1 (ino 257) + # |----- file2 (ino 258) + # |----- file3 (ino 259) + # |----- A/ (ino 260) + # |---- hard_link (ino 259) + # + + # Now create the base snapshot, which is going to be the parent snapshot + # for a later incremental send. + btrfs subvolume snapshot -r $MNT $MNT/snap1 + btrfs send -f /tmp/snap1.send $MNT/snap1 + + # Move inode 257 into directory inode 260. This results in computing the + # path for inode 260 as "/A" and caching it. + mv $MNT/file1 $MNT/A/file1 + + # Move inode 258 (file2) into directory inode 260, with a name of + # "hard_link", moving first inode 259 away since it currently has that + # location and name. + mv $MNT/A/hard_link $MNT/tmp + mv $MNT/file2 $MNT/A/hard_link + + # Now rename inode 260 to something else (B for example) and then create + # a hard link for inode 258 that has the old name and location of inode + # 260 ("/A"). + mv $MNT/A $MNT/B + ln $MNT/B/hard_link $MNT/A + + # Filesystem now looks like: + # + # . (ino 256) + # |----- tmp (ino 259) + # |----- file3 (ino 259) + # |----- B/ (ino 260) + # | |---- file1 (ino 257) + # | |---- hard_link (ino 258) + # | + # |----- A (ino 258) + + # Create another snapshot of our subvolume and use it for an incremental + # send. + btrfs subvolume snapshot -r $MNT $MNT/snap2 + btrfs send -f /tmp/snap2.send -p $MNT/snap1 $MNT/snap2 + + # Now unmount the filesystem, create a new one, mount it and try to + # apply both send streams to recreate both snapshots. + umount $DEV + + mkfs.btrfs -f $DEV >/dev/null + + mount $DEV $MNT + + # First add the first snapshot to the new filesystem by applying the + # first send stream. + btrfs receive -f /tmp/snap1.send $MNT + + # The incremental receive operation below used to fail with the + # following error: + # + # ERROR: unlink A/hard_link failed: No such file or directory + # + # This is because when send is processing inode 257, it generates the + # path for inode 260 as "/A", since that inode is its parent in the send + # snapshot, and caches that path. + # + # Later when processing inode 258, it first processes its new reference + # that has the path of "/A", which results in orphanizing inode 260 + # because there is a a path collision. This results in issuing a rename + # operation from "/A" to "/o260-6-0". + # + # Finally when processing the new reference "B/hard_link" for inode 258, + # it notices that it collides with inode 259 (not yet processed, because + # it has a higher inode number), since that inode has the name + # "hard_link" under the directory inode 260. It also checks that inode + # 259 has two hardlinks, so it decides to issue a unlink operation for + # the name "hard_link" for inode 259. However the path passed to the + # unlink operation is "/A/hard_link", which is incorrect since currently + # "/A" does not exists, due to the orphanization of inode 260 mentioned + # before. The path is incorrect because it was computed and cached + # before the orphanization. This results in the receiver to fail with + # the above error. + btrfs receive -f /tmp/snap2.send $MNT + + umount $MNT + +When running the test, it fails like this: + + $ ./test-send-unlink.sh + Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap1' + At subvol /mnt/sdi/snap1 + Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap2' + At subvol /mnt/sdi/snap2 + At subvol snap1 + At snapshot snap2 + ERROR: unlink A/hard_link failed: No such file or directory + +Fix this by recomputing a path before issuing an unlink operation when +processing the new references for the current inode if we previously +have orphanized a directory. + +A test case for fstests will follow soon. + +CC: stable@vger.kernel.org # 4.4+ +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/send.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/fs/btrfs/send.c ++++ b/fs/btrfs/send.c +@@ -4078,6 +4078,17 @@ static int process_recorded_refs(struct + if (ret < 0) + goto out; + } else { ++ /* ++ * If we previously orphanized a directory that ++ * collided with a new reference that we already ++ * processed, recompute the current path because ++ * that directory may be part of the path. ++ */ ++ if (orphanized_dir) { ++ ret = refresh_ref_path(sctx, cur); ++ if (ret < 0) ++ goto out; ++ } + ret = send_unlink(sctx, cur->full_path); + if (ret < 0) + goto out; diff --git a/queue-4.14/can-bcm-delay-release-of-struct-bcm_op-after-synchronize_rcu.patch b/queue-4.14/can-bcm-delay-release-of-struct-bcm_op-after-synchronize_rcu.patch new file mode 100644 index 00000000000..b762c25e6e7 --- /dev/null +++ b/queue-4.14/can-bcm-delay-release-of-struct-bcm_op-after-synchronize_rcu.patch @@ -0,0 +1,64 @@ +From d5f9023fa61ee8b94f37a93f08e94b136cf1e463 Mon Sep 17 00:00:00 2001 +From: Thadeu Lima de Souza Cascardo +Date: Sat, 19 Jun 2021 13:18:13 -0300 +Subject: can: bcm: delay release of struct bcm_op after synchronize_rcu() + +From: Thadeu Lima de Souza Cascardo + +commit d5f9023fa61ee8b94f37a93f08e94b136cf1e463 upstream. + +can_rx_register() callbacks may be called concurrently to the call to +can_rx_unregister(). The callbacks and callback data, though, are +protected by RCU and the struct sock reference count. + +So the callback data is really attached to the life of sk, meaning +that it should be released on sk_destruct. However, bcm_remove_op() +calls tasklet_kill(), and RCU callbacks may be called under RCU +softirq, so that cannot be used on kernels before the introduction of +HRTIMER_MODE_SOFT. + +However, bcm_rx_handler() is called under RCU protection, so after +calling can_rx_unregister(), we may call synchronize_rcu() in order to +wait for any RCU read-side critical sections to finish. That is, +bcm_rx_handler() won't be called anymore for those ops. So, we only +free them, after we do that synchronize_rcu(). + +Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") +Link: https://lore.kernel.org/r/20210619161813.2098382-1-cascardo@canonical.com +Cc: linux-stable +Reported-by: syzbot+0f7e7e5e2f4f40fa89c0@syzkaller.appspotmail.com +Reported-by: Norbert Slusarek +Signed-off-by: Thadeu Lima de Souza Cascardo +Acked-by: Oliver Hartkopp +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman + +--- + net/can/bcm.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/net/can/bcm.c ++++ b/net/can/bcm.c +@@ -841,6 +841,7 @@ static int bcm_delete_rx_op(struct list_ + bcm_rx_handler, op); + + list_del(&op->list); ++ synchronize_rcu(); + bcm_remove_op(op); + return 1; /* done */ + } +@@ -1594,9 +1595,13 @@ static int bcm_release(struct socket *so + REGMASK(op->can_id), + bcm_rx_handler, op); + +- bcm_remove_op(op); + } + ++ synchronize_rcu(); ++ ++ list_for_each_entry_safe(op, next, &bo->rx_ops, list) ++ bcm_remove_op(op); ++ + #if IS_ENABLED(CONFIG_PROC_FS) + /* remove procfs entry */ + if (net->can.bcmproc_dir && bo->bcm_proc_read) diff --git a/queue-4.14/can-gw-synchronize-rcu-operations-before-removing-gw-job-entry.patch b/queue-4.14/can-gw-synchronize-rcu-operations-before-removing-gw-job-entry.patch new file mode 100644 index 00000000000..62b5d7f203e --- /dev/null +++ b/queue-4.14/can-gw-synchronize-rcu-operations-before-removing-gw-job-entry.patch @@ -0,0 +1,51 @@ +From fb8696ab14adadb2e3f6c17c18ed26b3ecd96691 Mon Sep 17 00:00:00 2001 +From: Oliver Hartkopp +Date: Fri, 18 Jun 2021 19:36:45 +0200 +Subject: can: gw: synchronize rcu operations before removing gw job entry + +From: Oliver Hartkopp + +commit fb8696ab14adadb2e3f6c17c18ed26b3ecd96691 upstream. + +can_can_gw_rcv() is called under RCU protection, so after calling +can_rx_unregister(), we have to call synchronize_rcu in order to wait +for any RCU read-side critical sections to finish before removing the +kmem_cache entry with the referenced gw job entry. + +Link: https://lore.kernel.org/r/20210618173645.2238-1-socketcan@hartkopp.net +Fixes: c1aabdf379bc ("can-gw: add netlink based CAN routing") +Cc: linux-stable +Signed-off-by: Oliver Hartkopp +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman + +--- + net/can/gw.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/net/can/gw.c ++++ b/net/can/gw.c +@@ -494,6 +494,7 @@ static int cgw_notifier(struct notifier_ + if (gwj->src.dev == dev || gwj->dst.dev == dev) { + hlist_del(&gwj->list); + cgw_unregister_filter(net, gwj); ++ synchronize_rcu(); + kmem_cache_free(cgw_cache, gwj); + } + } +@@ -941,6 +942,7 @@ static void cgw_remove_all_jobs(struct n + hlist_for_each_entry_safe(gwj, nx, &net->can.cgw_list, list) { + hlist_del(&gwj->list); + cgw_unregister_filter(net, gwj); ++ synchronize_rcu(); + kmem_cache_free(cgw_cache, gwj); + } + } +@@ -1010,6 +1012,7 @@ static int cgw_remove_job(struct sk_buff + + hlist_del(&gwj->list); + cgw_unregister_filter(net, gwj); ++ synchronize_rcu(); + kmem_cache_free(cgw_cache, gwj); + err = 0; + break; diff --git a/queue-4.14/can-peak_pciefd-pucan_handle_status-fix-a-potential-starvation-issue-in-tx-path.patch b/queue-4.14/can-peak_pciefd-pucan_handle_status-fix-a-potential-starvation-issue-in-tx-path.patch new file mode 100644 index 00000000000..cbd61ce0b04 --- /dev/null +++ b/queue-4.14/can-peak_pciefd-pucan_handle_status-fix-a-potential-starvation-issue-in-tx-path.patch @@ -0,0 +1,41 @@ +From b17233d385d0b6b43ecf81d43008cb1bbb008166 Mon Sep 17 00:00:00 2001 +From: Stephane Grosjean +Date: Wed, 23 Jun 2021 16:26:00 +0200 +Subject: can: peak_pciefd: pucan_handle_status(): fix a potential starvation issue in TX path + +From: Stephane Grosjean + +commit b17233d385d0b6b43ecf81d43008cb1bbb008166 upstream. + +Rather than just indicating that transmission can start, this patch +requires the explicit flushing of the network TX queue when the driver +is informed by the device that it can transmit, next to its +configuration. + +In this way, if frames have already been written by the application, +they will actually be transmitted. + +Fixes: ffd137f7043c ("can: peak/pcie_fd: remove useless code when interface starts") +Link: https://lore.kernel.org/r/20210623142600.149904-1-s.grosjean@peak-system.com +Cc: linux-stable +Signed-off-by: Stephane Grosjean +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/can/peak_canfd/peak_canfd.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/can/peak_canfd/peak_canfd.c ++++ b/drivers/net/can/peak_canfd/peak_canfd.c +@@ -346,8 +346,8 @@ static int pucan_handle_status(struct pe + return err; + } + +- /* start network queue (echo_skb array is empty) */ +- netif_start_queue(ndev); ++ /* wake network queue up (echo_skb array is empty) */ ++ netif_wake_queue(ndev); + + return 0; + } diff --git a/queue-4.14/ext4-cleanup-in-core-orphan-list-if-ext4_truncate-failed-to-get-a-transaction-handle.patch b/queue-4.14/ext4-cleanup-in-core-orphan-list-if-ext4_truncate-failed-to-get-a-transaction-handle.patch new file mode 100644 index 00000000000..87f065c5f9b --- /dev/null +++ b/queue-4.14/ext4-cleanup-in-core-orphan-list-if-ext4_truncate-failed-to-get-a-transaction-handle.patch @@ -0,0 +1,54 @@ +From b9a037b7f3c401d3c63e0423e56aef606b1ffaaf Mon Sep 17 00:00:00 2001 +From: Zhang Yi +Date: Fri, 7 May 2021 15:19:04 +0800 +Subject: ext4: cleanup in-core orphan list if ext4_truncate() failed to get a transaction handle + +From: Zhang Yi + +commit b9a037b7f3c401d3c63e0423e56aef606b1ffaaf upstream. + +In ext4_orphan_cleanup(), if ext4_truncate() failed to get a transaction +handle, it didn't remove the inode from the in-core orphan list, which +may probably trigger below error dump in ext4_destroy_inode() during the +final iput() and could lead to memory corruption on the later orphan +list changes. + + EXT4-fs (sda): Inode 6291467 (00000000b8247c67): orphan list check failed! + 00000000b8247c67: 0001f30a 00000004 00000000 00000023 ............#... + 00000000e24cde71: 00000006 014082a3 00000000 00000000 ......@......... + 0000000072c6a5ee: 00000000 00000000 00000000 00000000 ................ + ... + +This patch fix this by cleanup in-core orphan list manually if +ext4_truncate() return error. + +Cc: stable@kernel.org +Signed-off-by: Zhang Yi +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20210507071904.160808-1-yi.zhang@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/super.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/fs/ext4/super.c ++++ b/fs/ext4/super.c +@@ -2614,8 +2614,15 @@ static void ext4_orphan_cleanup(struct s + inode_lock(inode); + truncate_inode_pages(inode->i_mapping, inode->i_size); + ret = ext4_truncate(inode); +- if (ret) ++ if (ret) { ++ /* ++ * We need to clean up the in-core orphan list ++ * manually if ext4_truncate() failed to get a ++ * transaction handle. ++ */ ++ ext4_orphan_del(NULL, inode); + ext4_std_error(inode->i_sb, ret); ++ } + inode_unlock(inode); + nr_truncates++; + } else { diff --git a/queue-4.14/ext4-correct-the-cache_nr-in-tracepoint-ext4_es_shrink_exit.patch b/queue-4.14/ext4-correct-the-cache_nr-in-tracepoint-ext4_es_shrink_exit.patch new file mode 100644 index 00000000000..9ac01640706 --- /dev/null +++ b/queue-4.14/ext4-correct-the-cache_nr-in-tracepoint-ext4_es_shrink_exit.patch @@ -0,0 +1,35 @@ +From 4fb7c70a889ead2e91e184895ac6e5354b759135 Mon Sep 17 00:00:00 2001 +From: Zhang Yi +Date: Sat, 22 May 2021 18:30:45 +0800 +Subject: ext4: correct the cache_nr in tracepoint ext4_es_shrink_exit + +From: Zhang Yi + +commit 4fb7c70a889ead2e91e184895ac6e5354b759135 upstream. + +The cache_cnt parameter of tracepoint ext4_es_shrink_exit means the +remaining cache count after shrink, but now it is the cache count before +shrink, fix it by read sbi->s_extent_cache_cnt again. + +Fixes: 1ab6c4997e04 ("fs: convert fs shrinkers to new scan/count API") +Cc: stable@vger.kernel.org # 3.12+ +Signed-off-by: Zhang Yi +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20210522103045.690103-3-yi.zhang@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/extents_status.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/ext4/extents_status.c ++++ b/fs/ext4/extents_status.c +@@ -1086,6 +1086,7 @@ static unsigned long ext4_es_scan(struct + + nr_shrunk = __es_shrink(sbi, nr_to_scan, NULL); + ++ ret = percpu_counter_read_positive(&sbi->s_es_stats.es_stats_shk_cnt); + trace_ext4_es_shrink_scan_exit(sbi->s_sb, nr_shrunk, ret); + return nr_shrunk; + } diff --git a/queue-4.14/ext4-fix-avefreec-in-find_group_orlov.patch b/queue-4.14/ext4-fix-avefreec-in-find_group_orlov.patch new file mode 100644 index 00000000000..f41566d4f33 --- /dev/null +++ b/queue-4.14/ext4-fix-avefreec-in-find_group_orlov.patch @@ -0,0 +1,64 @@ +From c89849cc0259f3d33624cc3bd127685c3c0fa25d Mon Sep 17 00:00:00 2001 +From: Pan Dong +Date: Tue, 25 May 2021 15:36:56 +0800 +Subject: ext4: fix avefreec in find_group_orlov + +From: Pan Dong + +commit c89849cc0259f3d33624cc3bd127685c3c0fa25d upstream. + +The avefreec should be average free clusters instead +of average free blocks, otherwize Orlov's allocator +will not work properly when bigalloc enabled. + +Cc: stable@kernel.org +Signed-off-by: Pan Dong +Link: https://lore.kernel.org/r/20210525073656.31594-1-pandong.peter@bytedance.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/ialloc.c | 11 +++++------ + 1 file changed, 5 insertions(+), 6 deletions(-) + +--- a/fs/ext4/ialloc.c ++++ b/fs/ext4/ialloc.c +@@ -407,7 +407,7 @@ static void get_orlov_stats(struct super + * + * We always try to spread first-level directories. + * +- * If there are blockgroups with both free inodes and free blocks counts ++ * If there are blockgroups with both free inodes and free clusters counts + * not worse than average we return one with smallest directory count. + * Otherwise we simply return a random group. + * +@@ -416,7 +416,7 @@ static void get_orlov_stats(struct super + * It's OK to put directory into a group unless + * it has too many directories already (max_dirs) or + * it has too few free inodes left (min_inodes) or +- * it has too few free blocks left (min_blocks) or ++ * it has too few free clusters left (min_clusters) or + * Parent's group is preferred, if it doesn't satisfy these + * conditions we search cyclically through the rest. If none + * of the groups look good we just look for a group with more +@@ -432,7 +432,7 @@ static int find_group_orlov(struct super + ext4_group_t real_ngroups = ext4_get_groups_count(sb); + int inodes_per_group = EXT4_INODES_PER_GROUP(sb); + unsigned int freei, avefreei, grp_free; +- ext4_fsblk_t freeb, avefreec; ++ ext4_fsblk_t freec, avefreec; + unsigned int ndirs; + int max_dirs, min_inodes; + ext4_grpblk_t min_clusters; +@@ -451,9 +451,8 @@ static int find_group_orlov(struct super + + freei = percpu_counter_read_positive(&sbi->s_freeinodes_counter); + avefreei = freei / ngroups; +- freeb = EXT4_C2B(sbi, +- percpu_counter_read_positive(&sbi->s_freeclusters_counter)); +- avefreec = freeb; ++ freec = percpu_counter_read_positive(&sbi->s_freeclusters_counter); ++ avefreec = freec; + do_div(avefreec, ngroups); + ndirs = percpu_counter_read_positive(&sbi->s_dirs_counter); + diff --git a/queue-4.14/ext4-fix-kernel-infoleak-via-ext4_extent_header.patch b/queue-4.14/ext4-fix-kernel-infoleak-via-ext4_extent_header.patch new file mode 100644 index 00000000000..94912c7e5df --- /dev/null +++ b/queue-4.14/ext4-fix-kernel-infoleak-via-ext4_extent_header.patch @@ -0,0 +1,51 @@ +From ce3aba43599f0b50adbebff133df8d08a3d5fffe Mon Sep 17 00:00:00 2001 +From: Anirudh Rayabharam +Date: Fri, 7 May 2021 00:26:54 +0530 +Subject: ext4: fix kernel infoleak via ext4_extent_header + +From: Anirudh Rayabharam + +commit ce3aba43599f0b50adbebff133df8d08a3d5fffe upstream. + +Initialize eh_generation of struct ext4_extent_header to prevent leaking +info to userspace. Fixes KMSAN kernel-infoleak bug reported by syzbot at: +http://syzkaller.appspot.com/bug?id=78e9ad0e6952a3ca16e8234724b2fa92d041b9b8 + +Cc: stable@kernel.org +Reported-by: syzbot+2dcfeaf8cb49b05e8f1a@syzkaller.appspotmail.com +Fixes: a86c61812637 ("[PATCH] ext3: add extent map support") +Signed-off-by: Anirudh Rayabharam +Link: https://lore.kernel.org/r/20210506185655.7118-1-mail@anirudhrb.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/extents.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/ext4/extents.c ++++ b/fs/ext4/extents.c +@@ -870,6 +870,7 @@ int ext4_ext_tree_init(handle_t *handle, + eh->eh_entries = 0; + eh->eh_magic = EXT4_EXT_MAGIC; + eh->eh_max = cpu_to_le16(ext4_ext_space_root(inode, 0)); ++ eh->eh_generation = 0; + ext4_mark_inode_dirty(handle, inode); + return 0; + } +@@ -1126,6 +1127,7 @@ static int ext4_ext_split(handle_t *hand + neh->eh_max = cpu_to_le16(ext4_ext_space_block(inode, 0)); + neh->eh_magic = EXT4_EXT_MAGIC; + neh->eh_depth = 0; ++ neh->eh_generation = 0; + + /* move remainder of path[depth] to the new leaf */ + if (unlikely(path[depth].p_hdr->eh_entries != +@@ -1203,6 +1205,7 @@ static int ext4_ext_split(handle_t *hand + neh->eh_magic = EXT4_EXT_MAGIC; + neh->eh_max = cpu_to_le16(ext4_ext_space_block_idx(inode, 0)); + neh->eh_depth = cpu_to_le16(depth - i); ++ neh->eh_generation = 0; + fidx = EXT_FIRST_INDEX(neh); + fidx->ei_block = border; + ext4_idx_store_pblock(fidx, oldblock); diff --git a/queue-4.14/ext4-remove-check-for-zero-nr_to_scan-in-ext4_es_scan.patch b/queue-4.14/ext4-remove-check-for-zero-nr_to_scan-in-ext4_es_scan.patch new file mode 100644 index 00000000000..94e211dacab --- /dev/null +++ b/queue-4.14/ext4-remove-check-for-zero-nr_to_scan-in-ext4_es_scan.patch @@ -0,0 +1,37 @@ +From e5e7010e5444d923e4091cafff61d05f2d19cada Mon Sep 17 00:00:00 2001 +From: Zhang Yi +Date: Sat, 22 May 2021 18:30:44 +0800 +Subject: ext4: remove check for zero nr_to_scan in ext4_es_scan() + +From: Zhang Yi + +commit e5e7010e5444d923e4091cafff61d05f2d19cada upstream. + +After converting fs shrinkers to new scan/count API, we are no longer +pass zero nr_to_scan parameter to detect the number of objects to free, +just remove this check. + +Fixes: 1ab6c4997e04 ("fs: convert fs shrinkers to new scan/count API") +Cc: stable@vger.kernel.org # 3.12+ +Signed-off-by: Zhang Yi +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20210522103045.690103-2-yi.zhang@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/extents_status.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/fs/ext4/extents_status.c ++++ b/fs/ext4/extents_status.c +@@ -1081,9 +1081,6 @@ static unsigned long ext4_es_scan(struct + ret = percpu_counter_read_positive(&sbi->s_es_stats.es_stats_shk_cnt); + trace_ext4_es_shrink_scan_enter(sbi->s_sb, nr_to_scan, ret); + +- if (!nr_to_scan) +- return ret; +- + nr_shrunk = __es_shrink(sbi, nr_to_scan, NULL); + + ret = percpu_counter_read_positive(&sbi->s_es_stats.es_stats_shk_cnt); diff --git a/queue-4.14/ext4-use-ext4_grp_locked_error-in-mb_find_extent.patch b/queue-4.14/ext4-use-ext4_grp_locked_error-in-mb_find_extent.patch new file mode 100644 index 00000000000..9a6996b6b99 --- /dev/null +++ b/queue-4.14/ext4-use-ext4_grp_locked_error-in-mb_find_extent.patch @@ -0,0 +1,48 @@ +From cd84bbbac12a173a381a64c6ec8b76a5277b87b5 Mon Sep 17 00:00:00 2001 +From: Stephen Brennan +Date: Wed, 23 Jun 2021 16:21:14 -0700 +Subject: ext4: use ext4_grp_locked_error in mb_find_extent + +From: Stephen Brennan + +commit cd84bbbac12a173a381a64c6ec8b76a5277b87b5 upstream. + +Commit 5d1b1b3f492f ("ext4: fix BUG when calling ext4_error with locked +block group") introduces ext4_grp_locked_error to handle unlocking a +group in error cases. Otherwise, there is a possibility of a sleep while +atomic. However, since 43c73221b3b1 ("ext4: replace BUG_ON with WARN_ON +in mb_find_extent()"), mb_find_extent() has contained a ext4_error() +call while a group spinlock is held. Replace this with +ext4_grp_locked_error. + +Fixes: 43c73221b3b1 ("ext4: replace BUG_ON with WARN_ON in mb_find_extent()") +Cc: # 4.14+ +Signed-off-by: Stephen Brennan +Reviewed-by: Lukas Czerner +Reviewed-by: Junxiao Bi +Link: https://lore.kernel.org/r/20210623232114.34457-1-stephen.s.brennan@oracle.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/mballoc.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/fs/ext4/mballoc.c ++++ b/fs/ext4/mballoc.c +@@ -1558,10 +1558,11 @@ static int mb_find_extent(struct ext4_bu + if (ex->fe_start + ex->fe_len > EXT4_CLUSTERS_PER_GROUP(e4b->bd_sb)) { + /* Should never happen! (but apparently sometimes does?!?) */ + WARN_ON(1); +- ext4_error(e4b->bd_sb, "corruption or bug in mb_find_extent " +- "block=%d, order=%d needed=%d ex=%u/%d/%d@%u", +- block, order, needed, ex->fe_group, ex->fe_start, +- ex->fe_len, ex->fe_logical); ++ ext4_grp_locked_error(e4b->bd_sb, e4b->bd_group, 0, 0, ++ "corruption or bug in mb_find_extent " ++ "block=%d, order=%d needed=%d ex=%u/%d/%d@%u", ++ block, order, needed, ex->fe_group, ex->fe_start, ++ ex->fe_len, ex->fe_logical); + ex->fe_len = 0; + ex->fe_start = 0; + ex->fe_group = 0; diff --git a/queue-4.14/fuse-check-connected-before-queueing-on-fpq-io.patch b/queue-4.14/fuse-check-connected-before-queueing-on-fpq-io.patch new file mode 100644 index 00000000000..84218ea9276 --- /dev/null +++ b/queue-4.14/fuse-check-connected-before-queueing-on-fpq-io.patch @@ -0,0 +1,58 @@ +From 80ef08670d4c28a06a3de954bd350368780bcfef Mon Sep 17 00:00:00 2001 +From: Miklos Szeredi +Date: Tue, 22 Jun 2021 09:15:35 +0200 +Subject: fuse: check connected before queueing on fpq->io + +From: Miklos Szeredi + +commit 80ef08670d4c28a06a3de954bd350368780bcfef upstream. + +A request could end up on the fpq->io list after fuse_abort_conn() has +reset fpq->connected and aborted requests on that list: + +Thread-1 Thread-2 +======== ======== +->fuse_simple_request() ->shutdown + ->__fuse_request_send() + ->queue_request() ->fuse_abort_conn() +->fuse_dev_do_read() ->acquire(fpq->lock) + ->wait_for(fpq->lock) ->set err to all req's in fpq->io + ->release(fpq->lock) + ->acquire(fpq->lock) + ->add req to fpq->io + +After the userspace copy is done the request will be ended, but +req->out.h.error will remain uninitialized. Also the copy might block +despite being already aborted. + +Fix both issues by not allowing the request to be queued on the fpq->io +list after fuse_abort_conn() has processed this list. + +Reported-by: Pradeep P V K +Fixes: fd22d62ed0c3 ("fuse: no fc->lock for iqueue parts") +Cc: # v4.2 +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman + +--- + fs/fuse/dev.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/fs/fuse/dev.c ++++ b/fs/fuse/dev.c +@@ -1304,6 +1304,15 @@ static ssize_t fuse_dev_do_read(struct f + goto restart; + } + spin_lock(&fpq->lock); ++ /* ++ * Must not put request on fpq->io queue after having been shut down by ++ * fuse_abort_conn() ++ */ ++ if (!fpq->connected) { ++ req->out.h.error = err = -ECONNABORTED; ++ goto out_end; ++ ++ } + list_add(&req->list, &fpq->io); + spin_unlock(&fpq->lock); + cs->req = req; diff --git a/queue-4.14/iio-ltr501-ltr501_read_ps-add-missing-endianness-conversion.patch b/queue-4.14/iio-ltr501-ltr501_read_ps-add-missing-endianness-conversion.patch new file mode 100644 index 00000000000..9fb42ee91a4 --- /dev/null +++ b/queue-4.14/iio-ltr501-ltr501_read_ps-add-missing-endianness-conversion.patch @@ -0,0 +1,51 @@ +From 71b33f6f93ef9462c84560e2236ed22209d26a58 Mon Sep 17 00:00:00 2001 +From: Oliver Lang +Date: Thu, 10 Jun 2021 15:46:18 +0200 +Subject: iio: ltr501: ltr501_read_ps(): add missing endianness conversion + +From: Oliver Lang + +commit 71b33f6f93ef9462c84560e2236ed22209d26a58 upstream. + +The PS ADC Channel data is spread over 2 registers in little-endian +form. This patch adds the missing endianness conversion. + +Fixes: 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver") +Signed-off-by: Oliver Lang +Reviewed-by: Andy Shevchenko +Signed-off-by: Marc Kleine-Budde +Tested-by: Nikita Travkin # ltr559 +Link: https://lore.kernel.org/r/20210610134619.2101372-4-mkl@pengutronix.de +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/light/ltr501.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/iio/light/ltr501.c ++++ b/drivers/iio/light/ltr501.c +@@ -411,18 +411,19 @@ static int ltr501_read_als(struct ltr501 + + static int ltr501_read_ps(struct ltr501_data *data) + { +- int ret, status; ++ __le16 status; ++ int ret; + + ret = ltr501_drdy(data, LTR501_STATUS_PS_RDY); + if (ret < 0) + return ret; + + ret = regmap_bulk_read(data->regmap, LTR501_PS_DATA, +- &status, 2); ++ &status, sizeof(status)); + if (ret < 0) + return ret; + +- return status; ++ return le16_to_cpu(status); + } + + static int ltr501_read_intr_prst(struct ltr501_data *data, diff --git a/queue-4.14/iio-ltr501-ltr559-fix-initialization-of-ltr501_als_contr.patch b/queue-4.14/iio-ltr501-ltr559-fix-initialization-of-ltr501_als_contr.patch new file mode 100644 index 00000000000..fe07617468d --- /dev/null +++ b/queue-4.14/iio-ltr501-ltr559-fix-initialization-of-ltr501_als_contr.patch @@ -0,0 +1,41 @@ +From 421a26f3d7a7c3ca43f3a9dc0f3cb0f562d5bd95 Mon Sep 17 00:00:00 2001 +From: Oliver Lang +Date: Thu, 10 Jun 2021 15:46:17 +0200 +Subject: iio: ltr501: ltr559: fix initialization of LTR501_ALS_CONTR + +From: Oliver Lang + +commit 421a26f3d7a7c3ca43f3a9dc0f3cb0f562d5bd95 upstream. + +The ltr559 chip uses only the lowest bit of the ALS_CONTR register to +configure between active and stand-by mode. In the original driver +BIT(1) is used, which does a software reset instead. + +This patch fixes the problem by using BIT(0) as als_mode_active for +the ltr559 chip. + +Fixes: 8592a7eefa54 ("iio: ltr501: Add support for ltr559 chip") +Signed-off-by: Oliver Lang +Reviewed-by: Andy Shevchenko +Signed-off-by: Marc Kleine-Budde +Tested-by: Nikita Travkin # ltr559 +Link: https://lore.kernel.org/r/20210610134619.2101372-3-mkl@pengutronix.de +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/light/ltr501.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/light/ltr501.c ++++ b/drivers/iio/light/ltr501.c +@@ -1214,7 +1214,7 @@ static struct ltr501_chip_info ltr501_ch + .als_gain_tbl_size = ARRAY_SIZE(ltr559_als_gain_tbl), + .ps_gain = ltr559_ps_gain_tbl, + .ps_gain_tbl_size = ARRAY_SIZE(ltr559_ps_gain_tbl), +- .als_mode_active = BIT(1), ++ .als_mode_active = BIT(0), + .als_gain_mask = BIT(2) | BIT(3) | BIT(4), + .als_gain_shift = 2, + .info = <r501_info, diff --git a/queue-4.14/iio-ltr501-mark-register-holding-upper-8-bits-of-als_data-0-1-and-ps_data-as-volatile-too.patch b/queue-4.14/iio-ltr501-mark-register-holding-upper-8-bits-of-als_data-0-1-and-ps_data-as-volatile-too.patch new file mode 100644 index 00000000000..a15ccc556af --- /dev/null +++ b/queue-4.14/iio-ltr501-mark-register-holding-upper-8-bits-of-als_data-0-1-and-ps_data-as-volatile-too.patch @@ -0,0 +1,68 @@ +From 2ac0b029a04b673ce83b5089368f467c5dca720c Mon Sep 17 00:00:00 2001 +From: Marc Kleine-Budde +Date: Thu, 10 Jun 2021 15:46:16 +0200 +Subject: iio: ltr501: mark register holding upper 8 bits of ALS_DATA{0,1} and PS_DATA as volatile, too + +From: Marc Kleine-Budde + +commit 2ac0b029a04b673ce83b5089368f467c5dca720c upstream. + +The regmap is configured for 8 bit registers, uses a RB-Tree cache and +marks several registers as volatile (i.e. do not cache). + +The ALS and PS data registers in the chip are 16 bit wide and spans +two regmap registers. In the current driver only the base register is +marked as volatile, resulting in the upper register only read once. + +Further the data sheet notes: + +| When the I2C read operation starts, all four ALS data registers are +| locked until the I2C read operation of register 0x8B is completed. + +Which results in the registers never update after the 2nd read. + +This patch fixes the problem by marking the upper 8 bits of the ALS +and PS registers as volatile, too. + +Fixes: 2f2c96338afc ("iio: ltr501: Add regmap support.") +Reported-by: Oliver Lang +Reviewed-by: Andy Shevchenko +Signed-off-by: Marc Kleine-Budde +Tested-by: Nikita Travkin # ltr559 +Link: https://lore.kernel.org/r/20210610134619.2101372-2-mkl@pengutronix.de +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/light/ltr501.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/iio/light/ltr501.c ++++ b/drivers/iio/light/ltr501.c +@@ -35,9 +35,12 @@ + #define LTR501_PART_ID 0x86 + #define LTR501_MANUFAC_ID 0x87 + #define LTR501_ALS_DATA1 0x88 /* 16-bit, little endian */ ++#define LTR501_ALS_DATA1_UPPER 0x89 /* upper 8 bits of LTR501_ALS_DATA1 */ + #define LTR501_ALS_DATA0 0x8a /* 16-bit, little endian */ ++#define LTR501_ALS_DATA0_UPPER 0x8b /* upper 8 bits of LTR501_ALS_DATA0 */ + #define LTR501_ALS_PS_STATUS 0x8c + #define LTR501_PS_DATA 0x8d /* 16-bit, little endian */ ++#define LTR501_PS_DATA_UPPER 0x8e /* upper 8 bits of LTR501_PS_DATA */ + #define LTR501_INTR 0x8f /* output mode, polarity, mode */ + #define LTR501_PS_THRESH_UP 0x90 /* 11 bit, ps upper threshold */ + #define LTR501_PS_THRESH_LOW 0x92 /* 11 bit, ps lower threshold */ +@@ -1360,9 +1363,12 @@ static bool ltr501_is_volatile_reg(struc + { + switch (reg) { + case LTR501_ALS_DATA1: ++ case LTR501_ALS_DATA1_UPPER: + case LTR501_ALS_DATA0: ++ case LTR501_ALS_DATA0_UPPER: + case LTR501_ALS_PS_STATUS: + case LTR501_PS_DATA: ++ case LTR501_PS_DATA_UPPER: + return true; + default: + return false; diff --git a/queue-4.14/rsi-assign-beacon-rate-settings-to-the-correct-rate_info-descriptor-field.patch b/queue-4.14/rsi-assign-beacon-rate-settings-to-the-correct-rate_info-descriptor-field.patch new file mode 100644 index 00000000000..4d8395b09b6 --- /dev/null +++ b/queue-4.14/rsi-assign-beacon-rate-settings-to-the-correct-rate_info-descriptor-field.patch @@ -0,0 +1,51 @@ +From b1c3a24897bd528f2f4fda9fea7da08a84ae25b6 Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Fri, 7 May 2021 23:31:05 +0200 +Subject: rsi: Assign beacon rate settings to the correct rate_info descriptor field + +From: Marek Vasut + +commit b1c3a24897bd528f2f4fda9fea7da08a84ae25b6 upstream. + +The RSI_RATE_x bits must be assigned to struct rsi_data_desc rate_info +field. The rest of the driver does it correctly, except this one place, +so fix it. This is also aligned with the RSI downstream vendor driver. +Without this patch, an AP operating at 5 GHz does not transmit any +beacons at all, this patch fixes that. + +Fixes: d26a9559403c ("rsi: add beacon changes for AP mode") +Signed-off-by: Marek Vasut +Cc: Amitkumar Karwar +Cc: Angus Ainslie +Cc: David S. Miller +Cc: Jakub Kicinski +Cc: Kalle Valo +Cc: Karun Eagalapati +Cc: Martin Kepplinger +Cc: Prameela Rani Garnepudi +Cc: Sebastian Krzyszkowiak +Cc: Siva Rebbagondla +Cc: netdev@vger.kernel.org +Cc: stable@vger.kernel.org +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20210507213105.140138-1-marex@denx.de +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/rsi/rsi_91x_hal.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/wireless/rsi/rsi_91x_hal.c ++++ b/drivers/net/wireless/rsi/rsi_91x_hal.c +@@ -386,9 +386,9 @@ int rsi_prepare_beacon(struct rsi_common + } + + if (common->band == NL80211_BAND_2GHZ) +- bcn_frm->bbp_info |= cpu_to_le16(RSI_RATE_1); ++ bcn_frm->rate_info |= cpu_to_le16(RSI_RATE_1); + else +- bcn_frm->bbp_info |= cpu_to_le16(RSI_RATE_6); ++ bcn_frm->rate_info |= cpu_to_le16(RSI_RATE_6); + + if (mac_bcn->data[tim_offset + 2] == 0) + bcn_frm->frame_info |= cpu_to_le16(RSI_DATA_DESC_DTIM_BEACON); diff --git a/queue-4.14/rtc-stm32-fix-unbalanced-clk_disable_unprepare-on-probe-error-path.patch b/queue-4.14/rtc-stm32-fix-unbalanced-clk_disable_unprepare-on-probe-error-path.patch new file mode 100644 index 00000000000..0661d80d3c4 --- /dev/null +++ b/queue-4.14/rtc-stm32-fix-unbalanced-clk_disable_unprepare-on-probe-error-path.patch @@ -0,0 +1,77 @@ +From 950ac33dbe6ff656a623d862022f0762ec061ba7 Mon Sep 17 00:00:00 2001 +From: Martin Fuzzey +Date: Mon, 7 Jun 2021 19:36:40 +0200 +Subject: rtc: stm32: Fix unbalanced clk_disable_unprepare() on probe error path + +From: Martin Fuzzey + +commit 950ac33dbe6ff656a623d862022f0762ec061ba7 upstream. + +The STM32MP1 RTC may have 2 clocks, the pclk and the rtc_ck. + +If clk_prepare_enable() fails for the second clock (rtc_ck) we must only +call clk_disable_unprepare() for the first clock (pclk) but currently we +call it on both leading to a WARN: + +[ 15.629568] WARNING: CPU: 0 PID: 146 at drivers/clk/clk.c:958 clk_core_disable+0xb0/0xc8 +[ 15.637620] ck_rtc already disabled +[ 15.663322] CPU: 0 PID: 146 Comm: systemd-udevd Not tainted 5.4.77-pknbsp-svn5759-atag-v5.4.77-204-gea4235203137-dirty #2413 +[ 15.674510] Hardware name: STM32 (Device Tree Support) +[ 15.679658] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) +[ 15.687371] [] (show_stack) from [] (dump_stack+0xc0/0xe0) +[ 15.694574] [] (dump_stack) from [] (__warn+0xc8/0xf0) +[ 15.701428] [] (__warn) from [] (warn_slowpath_fmt+0x60/0x94) +[ 15.708894] [] (warn_slowpath_fmt) from [] (clk_core_disable+0xb0/0xc8) +[ 15.717230] [] (clk_core_disable) from [] (clk_core_disable_lock+0x18/0x24) +[ 15.725924] [] (clk_core_disable_lock) from [] (stm32_rtc_probe+0x124/0x5e4 [rtc_stm32]) +[ 15.735739] [] (stm32_rtc_probe [rtc_stm32]) from [] (platform_drv_probe+0x48/0x98) +[ 15.745095] [] (platform_drv_probe) from [] (really_probe+0x1f0/0x458) +[ 15.753338] [] (really_probe) from [] (driver_probe_device+0x70/0x1c4) +[ 15.761584] [] (driver_probe_device) from [] (device_driver_attach+0x58/0x60) +[ 15.770439] [] (device_driver_attach) from [] (__driver_attach+0xcc/0x170) +[ 15.779032] [] (__driver_attach) from [] (bus_for_each_dev+0x58/0x7c) +[ 15.787191] [] (bus_for_each_dev) from [] (bus_add_driver+0xdc/0x1f8) +[ 15.795352] [] (bus_add_driver) from [] (driver_register+0x7c/0x110) +[ 15.803425] [] (driver_register) from [] (do_one_initcall+0x70/0x1b8) +[ 15.811588] [] (do_one_initcall) from [] (do_init_module+0x58/0x1f8) +[ 15.819660] [] (do_init_module) from [] (load_module+0x1e58/0x23c8) +[ 15.827646] [] (load_module) from [] (sys_finit_module+0xa0/0xd4) +[ 15.835459] [] (sys_finit_module) from [] (__sys_trace_return+0x0/0x20) + +Signed-off-by: Martin Fuzzey +Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver") +Cc: stable@vger.kernel.org +Reviewed-by: Nobuhiro Iwamatsu +Signed-off-by: Alexandre Belloni +Link: https://lore.kernel.org/r/1623087421-19722-1-git-send-email-martin.fuzzey@flowbird.group +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/rtc/rtc-stm32.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/rtc/rtc-stm32.c ++++ b/drivers/rtc/rtc-stm32.c +@@ -636,7 +636,7 @@ static int stm32_rtc_probe(struct platfo + */ + ret = stm32_rtc_init(pdev, rtc); + if (ret) +- goto err; ++ goto err_no_rtc_ck; + + rtc->irq_alarm = platform_get_irq(pdev, 0); + if (rtc->irq_alarm <= 0) { +@@ -680,10 +680,12 @@ static int stm32_rtc_probe(struct platfo + dev_warn(&pdev->dev, "Date/Time must be initialized\n"); + + return 0; ++ + err: ++ clk_disable_unprepare(rtc->rtc_ck); ++err_no_rtc_ck: + if (rtc->data->has_pclk) + clk_disable_unprepare(rtc->pclk); +- clk_disable_unprepare(rtc->rtc_ck); + + regmap_update_bits(rtc->dbp, PWR_CR, PWR_CR_DBP, 0); + diff --git a/queue-4.14/s390-cio-dont-call-css_wait_for_slow_path-inside-a-lock.patch b/queue-4.14/s390-cio-dont-call-css_wait_for_slow_path-inside-a-lock.patch new file mode 100644 index 00000000000..ab94761d66e --- /dev/null +++ b/queue-4.14/s390-cio-dont-call-css_wait_for_slow_path-inside-a-lock.patch @@ -0,0 +1,67 @@ +From c749d8c018daf5fba6dfac7b6c5c78b27efd7d65 Mon Sep 17 00:00:00 2001 +From: Vineeth Vijayan +Date: Wed, 9 Jun 2021 09:21:08 +0200 +Subject: s390/cio: dont call css_wait_for_slow_path() inside a lock + +From: Vineeth Vijayan + +commit c749d8c018daf5fba6dfac7b6c5c78b27efd7d65 upstream. + +Currently css_wait_for_slow_path() gets called inside the chp->lock. +The path-verification-loop of slowpath inside this lock could lead to +deadlock as reported by the lockdep validator. + +The ccw_device_get_chp_desc() during the instance of a device-set-online +would try to acquire the same 'chp->lock' to read the chp->desc. +The instance of this function can get called from multiple scenario, +like probing or setting-device online manually. This could, in some +corner-cases lead to the deadlock. + +lockdep validator reported this as, + + CPU0 CPU1 + ---- ---- + lock(&chp->lock); + lock(kn->active#43); + lock(&chp->lock); + lock((wq_completion)cio); + +The chp->lock was introduced to serialize the access of struct +channel_path. This lock is not needed for the css_wait_for_slow_path() +function, so invoke the slow-path function outside this lock. + +Fixes: b730f3a93395 ("[S390] cio: add lock to struct channel_path") +Cc: +Reviewed-by: Peter Oberparleiter +Signed-off-by: Vineeth Vijayan +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/s390/cio/chp.c | 3 +++ + drivers/s390/cio/chsc.c | 2 -- + 2 files changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/s390/cio/chp.c ++++ b/drivers/s390/cio/chp.c +@@ -254,6 +254,9 @@ static ssize_t chp_status_write(struct d + if (!num_args) + return count; + ++ /* Wait until previous actions have settled. */ ++ css_wait_for_slow_path(); ++ + if (!strncasecmp(cmd, "on", 2) || !strcmp(cmd, "1")) { + mutex_lock(&cp->lock); + error = s390_vary_chpid(cp->chpid, 1); +--- a/drivers/s390/cio/chsc.c ++++ b/drivers/s390/cio/chsc.c +@@ -769,8 +769,6 @@ int chsc_chp_vary(struct chp_id chpid, i + { + struct channel_path *chp = chpid_to_chp(chpid); + +- /* Wait until previous actions have settled. */ +- css_wait_for_slow_path(); + /* + * Redo PathVerification on the devices the chpid connects to + */ diff --git a/queue-4.14/seq_buf-make-trace_seq_putmem_hex-support-data-longer-than-8.patch b/queue-4.14/seq_buf-make-trace_seq_putmem_hex-support-data-longer-than-8.patch new file mode 100644 index 00000000000..9d40cfad4e9 --- /dev/null +++ b/queue-4.14/seq_buf-make-trace_seq_putmem_hex-support-data-longer-than-8.patch @@ -0,0 +1,45 @@ +From 6a2cbc58d6c9d90cd74288cc497c2b45815bc064 Mon Sep 17 00:00:00 2001 +From: Yun Zhou +Date: Sat, 26 Jun 2021 11:21:56 +0800 +Subject: seq_buf: Make trace_seq_putmem_hex() support data longer than 8 + +From: Yun Zhou + +commit 6a2cbc58d6c9d90cd74288cc497c2b45815bc064 upstream. + +Since the raw memory 'data' does not go forward, it will dump repeated +data if the data length is more than 8. If we want to dump longer data +blocks, we need to repeatedly call macro SEQ_PUT_HEX_FIELD. I think it +is a bit redundant, and multiple function calls also affect the performance. + +Link: https://lore.kernel.org/lkml/20210625122453.5e2fe304@oasis.local.home/ +Link: https://lkml.kernel.org/r/20210626032156.47889-2-yun.zhou@windriver.com + +Cc: stable@vger.kernel.org +Fixes: 6d2289f3faa7 ("tracing: Make trace_seq_putmem_hex() more robust") +Signed-off-by: Yun Zhou +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman + +--- + lib/seq_buf.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/lib/seq_buf.c ++++ b/lib/seq_buf.c +@@ -242,12 +242,14 @@ int seq_buf_putmem_hex(struct seq_buf *s + break; + + /* j increments twice per loop */ +- len -= j / 2; + hex[j++] = ' '; + + seq_buf_putmem(s, hex, j); + if (seq_buf_has_overflowed(s)) + return -1; ++ ++ len -= start_len; ++ data += start_len; + } + return 0; + } diff --git a/queue-4.14/serial-sh-sci-stop-dmaengine-transfer-in-sci_stop_tx.patch b/queue-4.14/serial-sh-sci-stop-dmaengine-transfer-in-sci_stop_tx.patch new file mode 100644 index 00000000000..b55f9a0d7bc --- /dev/null +++ b/queue-4.14/serial-sh-sci-stop-dmaengine-transfer-in-sci_stop_tx.patch @@ -0,0 +1,48 @@ +From 08a84410a04f05c7c1b8e833f552416d8eb9f6fe Mon Sep 17 00:00:00 2001 +From: Yoshihiro Shimoda +Date: Thu, 10 Jun 2021 20:08:06 +0900 +Subject: serial: sh-sci: Stop dmaengine transfer in sci_stop_tx() + +From: Yoshihiro Shimoda + +commit 08a84410a04f05c7c1b8e833f552416d8eb9f6fe upstream. + +Stop dmaengine transfer in sci_stop_tx(). Otherwise, the following +message is possible output when system enters suspend and while +transferring data, because clearing TIE bit in SCSCR is not able to +stop any dmaengine transfer. + + sh-sci e6550000.serial: ttySC1: Unable to drain transmitter + +Note that this driver has already used some #ifdef in the .c file +so that this patch also uses #ifdef to fix the issue. Otherwise, +build errors happens if the CONFIG_SERIAL_SH_SCI_DMA is disabled. + +Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.") +Cc: # v4.9+ +Signed-off-by: Yoshihiro Shimoda +Link: https://lore.kernel.org/r/20210610110806.277932-1-yoshihiro.shimoda.uh@renesas.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/serial/sh-sci.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/tty/serial/sh-sci.c ++++ b/drivers/tty/serial/sh-sci.c +@@ -581,6 +581,14 @@ static void sci_stop_tx(struct uart_port + ctrl &= ~SCSCR_TIE; + + serial_port_out(port, SCSCR, ctrl); ++ ++#ifdef CONFIG_SERIAL_SH_SCI_DMA ++ if (to_sci_port(port)->chan_tx && ++ !dma_submit_error(to_sci_port(port)->cookie_tx)) { ++ dmaengine_terminate_async(to_sci_port(port)->chan_tx); ++ to_sci_port(port)->cookie_tx = -EINVAL; ++ } ++#endif + } + + static void sci_start_rx(struct uart_port *port) diff --git a/queue-4.14/serial_cs-add-option-international-gsm-ready-56k-isdn-modem.patch b/queue-4.14/serial_cs-add-option-international-gsm-ready-56k-isdn-modem.patch new file mode 100644 index 00000000000..76b7d1ebf3d --- /dev/null +++ b/queue-4.14/serial_cs-add-option-international-gsm-ready-56k-isdn-modem.patch @@ -0,0 +1,31 @@ +From d495dd743d5ecd47288156e25c4d9163294a0992 Mon Sep 17 00:00:00 2001 +From: Ondrej Zary +Date: Fri, 11 Jun 2021 22:19:40 +0200 +Subject: serial_cs: Add Option International GSM-Ready 56K/ISDN modem + +From: Ondrej Zary + +commit d495dd743d5ecd47288156e25c4d9163294a0992 upstream. + +Add support for Option International GSM-Ready 56K/ISDN PCMCIA modem +card. + +Signed-off-by: Ondrej Zary +Cc: stable +Link: https://lore.kernel.org/r/20210611201940.23898-2-linux@zary.sk +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/serial/8250/serial_cs.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/tty/serial/8250/serial_cs.c ++++ b/drivers/tty/serial/8250/serial_cs.c +@@ -779,6 +779,7 @@ static const struct pcmcia_device_id ser + PCMCIA_DEVICE_PROD_ID12("Multi-Tech", "MT2834LT", 0x5f73be51, 0x4cd7c09e), + PCMCIA_DEVICE_PROD_ID12("OEM ", "C288MX ", 0xb572d360, 0xd2385b7a), + PCMCIA_DEVICE_PROD_ID12("Option International", "V34bis GSM/PSTN Data/Fax Modem", 0x9d7cd6f5, 0x5cb8bf41), ++ PCMCIA_DEVICE_PROD_ID12("Option International", "GSM-Ready 56K/ISDN", 0x9d7cd6f5, 0xb23844aa), + PCMCIA_DEVICE_PROD_ID12("PCMCIA ", "C336MX ", 0x99bcafe9, 0xaa25bcab), + PCMCIA_DEVICE_PROD_ID12("Quatech Inc", "PCMCIA Dual RS-232 Serial Port Card", 0xc4420b35, 0x92abc92f), + PCMCIA_DEVICE_PROD_ID12("Quatech Inc", "Dual RS-232 Serial Port PC Card", 0xc4420b35, 0x031a380d), diff --git a/queue-4.14/serial_cs-remove-wrong-globetrotter.cis-entry.patch b/queue-4.14/serial_cs-remove-wrong-globetrotter.cis-entry.patch new file mode 100644 index 00000000000..980f1d8b455 --- /dev/null +++ b/queue-4.14/serial_cs-remove-wrong-globetrotter.cis-entry.patch @@ -0,0 +1,51 @@ +From 11b1d881a90fc184cc7d06e9804eb288c24a2a0d Mon Sep 17 00:00:00 2001 +From: Ondrej Zary +Date: Fri, 11 Jun 2021 22:19:39 +0200 +Subject: serial_cs: remove wrong GLOBETROTTER.cis entry + +From: Ondrej Zary + +commit 11b1d881a90fc184cc7d06e9804eb288c24a2a0d upstream. + +The GLOBETROTTER.cis entry in serial_cs matches more devices than +intended and breaks them. Remove it. + +Example: # pccardctl info +PRODID_1="Option International +" +PRODID_2="GSM-Ready 56K/ISDN +" +PRODID_3="021 +" +PRODID_4="A +" +MANFID=0013,0000 +FUNCID=0 + +result: +pcmcia 0.0: Direct firmware load for cis/GLOBETROTTER.cis failed with error -2 + +The GLOBETROTTER.cis is nowhere to be found. There's GLOBETROTTER.cis.ihex at +https://netdev.vger.kernel.narkive.com/h4inqdxM/patch-axnet-cs-fix-phy-id-detection-for-bogus-asix-chip#post41 +It's from completely diffetent card: +vers_1 4.1, "Option International", "GSM/GPRS GlobeTrotter", "001", "A" + +Signed-off-by: Ondrej Zary +Cc: stable +Link: https://lore.kernel.org/r/20210611201940.23898-1-linux@zary.sk +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/serial/8250/serial_cs.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/tty/serial/8250/serial_cs.c ++++ b/drivers/tty/serial/8250/serial_cs.c +@@ -807,7 +807,6 @@ static const struct pcmcia_device_id ser + PCMCIA_DEVICE_CIS_PROD_ID12("ADVANTECH", "COMpad-32/85B-4", 0x96913a85, 0xcec8f102, "cis/COMpad4.cis"), + PCMCIA_DEVICE_CIS_PROD_ID123("ADVANTECH", "COMpad-32/85", "1.0", 0x96913a85, 0x8fbe92ae, 0x0877b627, "cis/COMpad2.cis"), + PCMCIA_DEVICE_CIS_PROD_ID2("RS-COM 2P", 0xad20b156, "cis/RS-COM-2P.cis"), +- PCMCIA_DEVICE_CIS_MANF_CARD(0x0013, 0x0000, "cis/GLOBETROTTER.cis"), + PCMCIA_DEVICE_PROD_ID12("ELAN DIGITAL SYSTEMS LTD, c1997.", "SERIAL CARD: SL100 1.00.", 0x19ca78af, 0xf964f42b), + PCMCIA_DEVICE_PROD_ID12("ELAN DIGITAL SYSTEMS LTD, c1997.", "SERIAL CARD: SL100", 0x19ca78af, 0x71d98e83), + PCMCIA_DEVICE_PROD_ID12("ELAN DIGITAL SYSTEMS LTD, c1997.", "SERIAL CARD: SL232 1.00.", 0x19ca78af, 0x69fb7490), diff --git a/queue-4.14/series b/queue-4.14/series index 86a8e74d5f3..860abafd6aa 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -7,3 +7,30 @@ usb-cdc-acm-blacklist-heimann-usb-appset-device.patch ntfs-fix-validity-check-for-file-name-attribute.patch iov_iter_fault_in_readable-should-do-nothing-in-xarray-case.patch input-joydev-prevent-use-of-not-validated-data-in-jsiocsbtnmap-ioctl.patch +arm-dts-at91-sama5d4-fix-pinctrl-muxing.patch +btrfs-send-fix-invalid-path-for-unlink-operations-after-parent-orphanization.patch +btrfs-clear-defrag-status-of-a-root-if-starting-transaction-fails.patch +ext4-cleanup-in-core-orphan-list-if-ext4_truncate-failed-to-get-a-transaction-handle.patch +ext4-fix-kernel-infoleak-via-ext4_extent_header.patch +ext4-correct-the-cache_nr-in-tracepoint-ext4_es_shrink_exit.patch +ext4-remove-check-for-zero-nr_to_scan-in-ext4_es_scan.patch +ext4-fix-avefreec-in-find_group_orlov.patch +ext4-use-ext4_grp_locked_error-in-mb_find_extent.patch +can-bcm-delay-release-of-struct-bcm_op-after-synchronize_rcu.patch +can-gw-synchronize-rcu-operations-before-removing-gw-job-entry.patch +can-peak_pciefd-pucan_handle_status-fix-a-potential-starvation-issue-in-tx-path.patch +sunrpc-fix-the-batch-tasks-count-wraparound.patch +sunrpc-should-wake-up-the-privileged-task-firstly.patch +s390-cio-dont-call-css_wait_for_slow_path-inside-a-lock.patch +rtc-stm32-fix-unbalanced-clk_disable_unprepare-on-probe-error-path.patch +iio-ltr501-mark-register-holding-upper-8-bits-of-als_data-0-1-and-ps_data-as-volatile-too.patch +iio-ltr501-ltr559-fix-initialization-of-ltr501_als_contr.patch +iio-ltr501-ltr501_read_ps-add-missing-endianness-conversion.patch +serial-sh-sci-stop-dmaengine-transfer-in-sci_stop_tx.patch +serial_cs-add-option-international-gsm-ready-56k-isdn-modem.patch +serial_cs-remove-wrong-globetrotter.cis-entry.patch +ath9k-fix-kernel-null-pointer-dereference-during-ath_reset_internal.patch +ssb-sdio-don-t-overwrite-const-buffer-if-block_write-fails.patch +rsi-assign-beacon-rate-settings-to-the-correct-rate_info-descriptor-field.patch +seq_buf-make-trace_seq_putmem_hex-support-data-longer-than-8.patch +fuse-check-connected-before-queueing-on-fpq-io.patch diff --git a/queue-4.14/ssb-sdio-don-t-overwrite-const-buffer-if-block_write-fails.patch b/queue-4.14/ssb-sdio-don-t-overwrite-const-buffer-if-block_write-fails.patch new file mode 100644 index 00000000000..e0216010d8e --- /dev/null +++ b/queue-4.14/ssb-sdio-don-t-overwrite-const-buffer-if-block_write-fails.patch @@ -0,0 +1,37 @@ +From 47ec636f7a25aa2549e198c48ecb6b1c25d05456 Mon Sep 17 00:00:00 2001 +From: Michael Buesch +Date: Sat, 15 May 2021 21:02:52 +0200 +Subject: ssb: sdio: Don't overwrite const buffer if block_write fails +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Michael Buesch + +commit 47ec636f7a25aa2549e198c48ecb6b1c25d05456 upstream. + +It doesn't make sense to clobber the const driver-side buffer, if a +write-to-device attempt failed. All other SSB variants (PCI, PCMCIA and SoC) +also don't corrupt the buffer on any failure in block_write. +Therefore, remove this memset from the SDIO variant. + +Signed-off-by: Michael Büsch +Cc: stable@vger.kernel.org +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20210515210252.318be2ba@wiggum +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ssb/sdio.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/ssb/sdio.c ++++ b/drivers/ssb/sdio.c +@@ -411,7 +411,6 @@ static void ssb_sdio_block_write(struct + sdio_claim_host(bus->host_sdio); + if (unlikely(ssb_sdio_switch_core(bus, dev))) { + error = -EIO; +- memset((void *)buffer, 0xff, count); + goto err_out; + } + offset |= bus->sdio_sbaddr & 0xffff; diff --git a/queue-4.14/sunrpc-fix-the-batch-tasks-count-wraparound.patch b/queue-4.14/sunrpc-fix-the-batch-tasks-count-wraparound.patch new file mode 100644 index 00000000000..face82a57ba --- /dev/null +++ b/queue-4.14/sunrpc-fix-the-batch-tasks-count-wraparound.patch @@ -0,0 +1,48 @@ +From fcb170a9d825d7db4a3fb870b0300f5a40a8d096 Mon Sep 17 00:00:00 2001 +From: Zhang Xiaoxu +Date: Sat, 26 Jun 2021 15:50:41 +0800 +Subject: SUNRPC: Fix the batch tasks count wraparound. + +From: Zhang Xiaoxu + +commit fcb170a9d825d7db4a3fb870b0300f5a40a8d096 upstream. + +The 'queue->nr' will wraparound from 0 to 255 when only current +priority queue has tasks. This maybe lead a deadlock same as commit +dfe1fe75e00e ("NFSv4: Fix deadlock between nfs4_evict_inode() +and nfs4_opendata_get_inode()"): + +Privileged delegreturn task is queued to privileged list because all +the slots are assigned. When non-privileged task complete and release +the slot, a non-privileged maybe picked out. It maybe allocate slot +failed when the session on draining. + +If the 'queue->nr' has wraparound to 255, and no enough slot to +service it, then the privileged delegreturn will lost to wake up. + +So we should avoid the wraparound on 'queue->nr'. + +Reported-by: Hulk Robot +Fixes: 5fcdfacc01f3 ("NFSv4: Return delegations synchronously in evict_inode") +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Cc: stable@vger.kernel.org +Signed-off-by: Zhang Xiaoxu +Signed-off-by: Trond Myklebust +Signed-off-by: Greg Kroah-Hartman + +--- + net/sunrpc/sched.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/sunrpc/sched.c ++++ b/net/sunrpc/sched.c +@@ -490,7 +490,8 @@ static struct rpc_task *__rpc_find_next_ + * Service a batch of tasks from a single owner. + */ + q = &queue->tasks[queue->priority]; +- if (!list_empty(q) && --queue->nr) { ++ if (!list_empty(q) && queue->nr) { ++ queue->nr--; + task = list_first_entry(q, struct rpc_task, u.tk_wait.list); + goto out; + } diff --git a/queue-4.14/sunrpc-should-wake-up-the-privileged-task-firstly.patch b/queue-4.14/sunrpc-should-wake-up-the-privileged-task-firstly.patch new file mode 100644 index 00000000000..321c7aa59ea --- /dev/null +++ b/queue-4.14/sunrpc-should-wake-up-the-privileged-task-firstly.patch @@ -0,0 +1,52 @@ +From 5483b904bf336948826594610af4c9bbb0d9e3aa Mon Sep 17 00:00:00 2001 +From: Zhang Xiaoxu +Date: Sat, 26 Jun 2021 15:50:42 +0800 +Subject: SUNRPC: Should wake up the privileged task firstly. + +From: Zhang Xiaoxu + +commit 5483b904bf336948826594610af4c9bbb0d9e3aa upstream. + +When find a task from wait queue to wake up, a non-privileged task may +be found out, rather than the privileged. This maybe lead a deadlock +same as commit dfe1fe75e00e ("NFSv4: Fix deadlock between nfs4_evict_inode() +and nfs4_opendata_get_inode()"): + +Privileged delegreturn task is queued to privileged list because all +the slots are assigned. If there has no enough slot to wake up the +non-privileged batch tasks(session less than 8 slot), then the privileged +delegreturn task maybe lost waked up because the found out task can't +get slot since the session is on draining. + +So we should treate the privileged task as the emergency task, and +execute it as for as we can. + +Reported-by: Hulk Robot +Fixes: 5fcdfacc01f3 ("NFSv4: Return delegations synchronously in evict_inode") +Cc: stable@vger.kernel.org +Signed-off-by: Zhang Xiaoxu +Signed-off-by: Trond Myklebust +Signed-off-by: Greg Kroah-Hartman + +--- + net/sunrpc/sched.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/net/sunrpc/sched.c ++++ b/net/sunrpc/sched.c +@@ -487,6 +487,15 @@ static struct rpc_task *__rpc_find_next_ + struct rpc_task *task; + + /* ++ * Service the privileged queue. ++ */ ++ q = &queue->tasks[RPC_NR_PRIORITY - 1]; ++ if (queue->maxpriority > RPC_PRIORITY_PRIVILEGED && !list_empty(q)) { ++ task = list_first_entry(q, struct rpc_task, u.tk_wait.list); ++ goto out; ++ } ++ ++ /* + * Service a batch of tasks from a single owner. + */ + q = &queue->tasks[queue->priority];