]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.4-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 11 Jul 2021 13:14:00 +0000 (15:14 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 11 Jul 2021 13:14:00 +0000 (15:14 +0200)
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
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
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
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_cs-add-option-international-gsm-ready-56k-isdn-modem.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

18 files changed:
queue-4.4/arm-dts-at91-sama5d4-fix-pinctrl-muxing.patch [new file with mode: 0644]
queue-4.4/ath9k-fix-kernel-null-pointer-dereference-during-ath_reset_internal.patch [new file with mode: 0644]
queue-4.4/btrfs-clear-defrag-status-of-a-root-if-starting-transaction-fails.patch [new file with mode: 0644]
queue-4.4/ext4-correct-the-cache_nr-in-tracepoint-ext4_es_shrink_exit.patch [new file with mode: 0644]
queue-4.4/ext4-fix-avefreec-in-find_group_orlov.patch [new file with mode: 0644]
queue-4.4/ext4-fix-kernel-infoleak-via-ext4_extent_header.patch [new file with mode: 0644]
queue-4.4/ext4-remove-check-for-zero-nr_to_scan-in-ext4_es_scan.patch [new file with mode: 0644]
queue-4.4/fuse-check-connected-before-queueing-on-fpq-io.patch [new file with mode: 0644]
queue-4.4/iio-ltr501-ltr501_read_ps-add-missing-endianness-conversion.patch [new file with mode: 0644]
queue-4.4/iio-ltr501-ltr559-fix-initialization-of-ltr501_als_contr.patch [new file with mode: 0644]
queue-4.4/iio-ltr501-mark-register-holding-upper-8-bits-of-als_data-0-1-and-ps_data-as-volatile-too.patch [new file with mode: 0644]
queue-4.4/s390-cio-dont-call-css_wait_for_slow_path-inside-a-lock.patch [new file with mode: 0644]
queue-4.4/seq_buf-make-trace_seq_putmem_hex-support-data-longer-than-8.patch [new file with mode: 0644]
queue-4.4/serial_cs-add-option-international-gsm-ready-56k-isdn-modem.patch [new file with mode: 0644]
queue-4.4/series
queue-4.4/ssb-sdio-don-t-overwrite-const-buffer-if-block_write-fails.patch [new file with mode: 0644]
queue-4.4/sunrpc-fix-the-batch-tasks-count-wraparound.patch [new file with mode: 0644]
queue-4.4/sunrpc-should-wake-up-the-privileged-task-firstly.patch [new file with mode: 0644]

diff --git a/queue-4.4/arm-dts-at91-sama5d4-fix-pinctrl-muxing.patch b/queue-4.4/arm-dts-at91-sama5d4-fix-pinctrl-muxing.patch
new file mode 100644 (file)
index 0000000..3a179de
--- /dev/null
@@ -0,0 +1,35 @@
+From 253adffb0e98eaf6da2e7cf73ae68695e21f2f3c Mon Sep 17 00:00:00 2001
+From: Ludovic Desroches <ludovic.desroches@microchip.com>
+Date: Fri, 25 Oct 2019 10:42:10 +0200
+Subject: ARM: dts: at91: sama5d4: fix pinctrl muxing
+
+From: Ludovic Desroches <ludovic.desroches@microchip.com>
+
+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 <ludovic.desroches@microchip.com>
+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 <claudiu.beznea@microchip.com>
+Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
+Link: https://lore.kernel.org/r/20191025084210.14726-1-ludovic.desroches@microchip.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -1363,7 +1363,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.4/ath9k-fix-kernel-null-pointer-dereference-during-ath_reset_internal.patch b/queue-4.4/ath9k-fix-kernel-null-pointer-dereference-during-ath_reset_internal.patch
new file mode 100644 (file)
index 0000000..4de6c1e
--- /dev/null
@@ -0,0 +1,117 @@
+From fb312ac5ccb007e843f982b38d4d6886ba4b32f2 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali@kernel.org>
+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 <pali@kernel.org>
+
+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 <pali@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20210402122653.24014-1-pali@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -302,6 +302,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.4/btrfs-clear-defrag-status-of-a-root-if-starting-transaction-fails.patch b/queue-4.4/btrfs-clear-defrag-status-of-a-root-if-starting-transaction-fails.patch
new file mode 100644 (file)
index 0000000..b68aa96
--- /dev/null
@@ -0,0 +1,41 @@
+From 6819703f5a365c95488b07066a8744841bf14231 Mon Sep 17 00:00:00 2001
+From: David Sterba <dsterba@suse.com>
+Date: Tue, 7 Jul 2020 18:30:06 +0200
+Subject: btrfs: clear defrag status of a root if starting transaction fails
+
+From: David Sterba <dsterba@suse.com>
+
+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 <wqu@suse.com>
+Reviewed-by: Anand Jain <anand.jain@oracle.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/transaction.c |    6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/transaction.c
++++ b/fs/btrfs/transaction.c
+@@ -1264,8 +1264,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.4/ext4-correct-the-cache_nr-in-tracepoint-ext4_es_shrink_exit.patch b/queue-4.4/ext4-correct-the-cache_nr-in-tracepoint-ext4_es_shrink_exit.patch
new file mode 100644 (file)
index 0000000..c26f04c
--- /dev/null
@@ -0,0 +1,35 @@
+From 4fb7c70a889ead2e91e184895ac6e5354b759135 Mon Sep 17 00:00:00 2001
+From: Zhang Yi <yi.zhang@huawei.com>
+Date: Sat, 22 May 2021 18:30:45 +0800
+Subject: ext4: correct the cache_nr in tracepoint ext4_es_shrink_exit
+
+From: Zhang Yi <yi.zhang@huawei.com>
+
+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 <yi.zhang@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20210522103045.690103-3-yi.zhang@huawei.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/extents_status.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ext4/extents_status.c
++++ b/fs/ext4/extents_status.c
+@@ -1085,6 +1085,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.4/ext4-fix-avefreec-in-find_group_orlov.patch b/queue-4.4/ext4-fix-avefreec-in-find_group_orlov.patch
new file mode 100644 (file)
index 0000000..0313215
--- /dev/null
@@ -0,0 +1,64 @@
+From c89849cc0259f3d33624cc3bd127685c3c0fa25d Mon Sep 17 00:00:00 2001
+From: Pan Dong <pandong.peter@bytedance.com>
+Date: Tue, 25 May 2021 15:36:56 +0800
+Subject: ext4: fix avefreec in find_group_orlov
+
+From: Pan Dong <pandong.peter@bytedance.com>
+
+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 <pandong.peter@bytedance.com>
+Link: https://lore.kernel.org/r/20210525073656.31594-1-pandong.peter@bytedance.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/ialloc.c |   11 +++++------
+ 1 file changed, 5 insertions(+), 6 deletions(-)
+
+--- a/fs/ext4/ialloc.c
++++ b/fs/ext4/ialloc.c
+@@ -405,7 +405,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.
+  *
+@@ -414,7 +414,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
+@@ -430,7 +430,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;
+@@ -449,9 +449,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.4/ext4-fix-kernel-infoleak-via-ext4_extent_header.patch b/queue-4.4/ext4-fix-kernel-infoleak-via-ext4_extent_header.patch
new file mode 100644 (file)
index 0000000..9af0120
--- /dev/null
@@ -0,0 +1,51 @@
+From ce3aba43599f0b50adbebff133df8d08a3d5fffe Mon Sep 17 00:00:00 2001
+From: Anirudh Rayabharam <mail@anirudhrb.com>
+Date: Fri, 7 May 2021 00:26:54 +0530
+Subject: ext4: fix kernel infoleak via ext4_extent_header
+
+From: Anirudh Rayabharam <mail@anirudhrb.com>
+
+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 <mail@anirudhrb.com>
+Link: https://lore.kernel.org/r/20210506185655.7118-1-mail@anirudhrb.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/extents.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/ext4/extents.c
++++ b/fs/ext4/extents.c
+@@ -865,6 +865,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;
+ }
+@@ -1128,6 +1129,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 !=
+@@ -1205,6 +1207,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.4/ext4-remove-check-for-zero-nr_to_scan-in-ext4_es_scan.patch b/queue-4.4/ext4-remove-check-for-zero-nr_to_scan-in-ext4_es_scan.patch
new file mode 100644 (file)
index 0000000..846860d
--- /dev/null
@@ -0,0 +1,37 @@
+From e5e7010e5444d923e4091cafff61d05f2d19cada Mon Sep 17 00:00:00 2001
+From: Zhang Yi <yi.zhang@huawei.com>
+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 <yi.zhang@huawei.com>
+
+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 <yi.zhang@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20210522103045.690103-2-yi.zhang@huawei.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/extents_status.c |    3 ---
+ 1 file changed, 3 deletions(-)
+
+--- a/fs/ext4/extents_status.c
++++ b/fs/ext4/extents_status.c
+@@ -1080,9 +1080,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.4/fuse-check-connected-before-queueing-on-fpq-io.patch b/queue-4.4/fuse-check-connected-before-queueing-on-fpq-io.patch
new file mode 100644 (file)
index 0000000..aa242a4
--- /dev/null
@@ -0,0 +1,58 @@
+From 80ef08670d4c28a06a3de954bd350368780bcfef Mon Sep 17 00:00:00 2001
+From: Miklos Szeredi <mszeredi@redhat.com>
+Date: Tue, 22 Jun 2021 09:15:35 +0200
+Subject: fuse: check connected before queueing on fpq->io
+
+From: Miklos Szeredi <mszeredi@redhat.com>
+
+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 <pragalla@codeaurora.org>
+Fixes: fd22d62ed0c3 ("fuse: no fc->lock for iqueue parts")
+Cc: <stable@vger.kernel.org> # v4.2
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/fuse/dev.c |    9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/fs/fuse/dev.c
++++ b/fs/fuse/dev.c
+@@ -1315,6 +1315,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.4/iio-ltr501-ltr501_read_ps-add-missing-endianness-conversion.patch b/queue-4.4/iio-ltr501-ltr501_read_ps-add-missing-endianness-conversion.patch
new file mode 100644 (file)
index 0000000..9fb42ee
--- /dev/null
@@ -0,0 +1,51 @@
+From 71b33f6f93ef9462c84560e2236ed22209d26a58 Mon Sep 17 00:00:00 2001
+From: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
+Date: Thu, 10 Jun 2021 15:46:18 +0200
+Subject: iio: ltr501: ltr501_read_ps(): add missing endianness conversion
+
+From: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
+
+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 <Oliver.Lang@gossenmetrawatt.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559
+Link: https://lore.kernel.org/r/20210610134619.2101372-4-mkl@pengutronix.de
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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.4/iio-ltr501-ltr559-fix-initialization-of-ltr501_als_contr.patch b/queue-4.4/iio-ltr501-ltr559-fix-initialization-of-ltr501_als_contr.patch
new file mode 100644 (file)
index 0000000..cda7505
--- /dev/null
@@ -0,0 +1,41 @@
+From 421a26f3d7a7c3ca43f3a9dc0f3cb0f562d5bd95 Mon Sep 17 00:00:00 2001
+From: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
+Date: Thu, 10 Jun 2021 15:46:17 +0200
+Subject: iio: ltr501: ltr559: fix initialization of LTR501_ALS_CONTR
+
+From: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
+
+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 <Oliver.Lang@gossenmetrawatt.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559
+Link: https://lore.kernel.org/r/20210610134619.2101372-3-mkl@pengutronix.de
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -1183,7 +1183,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 = &ltr501_info,
diff --git a/queue-4.4/iio-ltr501-mark-register-holding-upper-8-bits-of-als_data-0-1-and-ps_data-as-volatile-too.patch b/queue-4.4/iio-ltr501-mark-register-holding-upper-8-bits-of-als_data-0-1-and-ps_data-as-volatile-too.patch
new file mode 100644 (file)
index 0000000..e31797d
--- /dev/null
@@ -0,0 +1,68 @@
+From 2ac0b029a04b673ce83b5089368f467c5dca720c Mon Sep 17 00:00:00 2001
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+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 <mkl@pengutronix.de>
+
+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 <Oliver.Lang@gossenmetrawatt.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559
+Link: https://lore.kernel.org/r/20210610134619.2101372-2-mkl@pengutronix.de
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 */
+@@ -1328,9 +1331,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.4/s390-cio-dont-call-css_wait_for_slow_path-inside-a-lock.patch b/queue-4.4/s390-cio-dont-call-css_wait_for_slow_path-inside-a-lock.patch
new file mode 100644 (file)
index 0000000..464f96e
--- /dev/null
@@ -0,0 +1,67 @@
+From c749d8c018daf5fba6dfac7b6c5c78b27efd7d65 Mon Sep 17 00:00:00 2001
+From: Vineeth Vijayan <vneethv@linux.ibm.com>
+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 <vneethv@linux.ibm.com>
+
+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: <stable@vger.kernel.org>
+Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
+Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -257,6 +257,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.4/seq_buf-make-trace_seq_putmem_hex-support-data-longer-than-8.patch b/queue-4.4/seq_buf-make-trace_seq_putmem_hex-support-data-longer-than-8.patch
new file mode 100644 (file)
index 0000000..a50277a
--- /dev/null
@@ -0,0 +1,45 @@
+From 6a2cbc58d6c9d90cd74288cc497c2b45815bc064 Mon Sep 17 00:00:00 2001
+From: Yun Zhou <yun.zhou@windriver.com>
+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 <yun.zhou@windriver.com>
+
+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 <yun.zhou@windriver.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ lib/seq_buf.c |    4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/lib/seq_buf.c
++++ b/lib/seq_buf.c
+@@ -241,12 +241,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.4/serial_cs-add-option-international-gsm-ready-56k-isdn-modem.patch b/queue-4.4/serial_cs-add-option-international-gsm-ready-56k-isdn-modem.patch
new file mode 100644 (file)
index 0000000..5acd714
--- /dev/null
@@ -0,0 +1,31 @@
+From d495dd743d5ecd47288156e25c4d9163294a0992 Mon Sep 17 00:00:00 2001
+From: Ondrej Zary <linux@zary.sk>
+Date: Fri, 11 Jun 2021 22:19:40 +0200
+Subject: serial_cs: Add Option International GSM-Ready 56K/ISDN modem
+
+From: Ondrej Zary <linux@zary.sk>
+
+commit d495dd743d5ecd47288156e25c4d9163294a0992 upstream.
+
+Add support for Option International GSM-Ready 56K/ISDN PCMCIA modem
+card.
+
+Signed-off-by: Ondrej Zary <linux@zary.sk>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210611201940.23898-2-linux@zary.sk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -771,6 +771,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),
index 86a8e74d5f3dc8b85f1e7f6dd41fcedd849edd29..d747071b72e303bd6d9552b33635dbb2356f2a83 100644 (file)
@@ -7,3 +7,20 @@ 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-clear-defrag-status-of-a-root-if-starting-transaction-fails.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
+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
+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_cs-add-option-international-gsm-ready-56k-isdn-modem.patch
+ath9k-fix-kernel-null-pointer-dereference-during-ath_reset_internal.patch
+ssb-sdio-don-t-overwrite-const-buffer-if-block_write-fails.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.4/ssb-sdio-don-t-overwrite-const-buffer-if-block_write-fails.patch b/queue-4.4/ssb-sdio-don-t-overwrite-const-buffer-if-block_write-fails.patch
new file mode 100644 (file)
index 0000000..e021601
--- /dev/null
@@ -0,0 +1,37 @@
+From 47ec636f7a25aa2549e198c48ecb6b1c25d05456 Mon Sep 17 00:00:00 2001
+From: Michael Buesch <m@bues.ch>
+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 <m@bues.ch>
+
+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 <m@bues.ch>
+Cc: stable@vger.kernel.org
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20210515210252.318be2ba@wiggum
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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.4/sunrpc-fix-the-batch-tasks-count-wraparound.patch b/queue-4.4/sunrpc-fix-the-batch-tasks-count-wraparound.patch
new file mode 100644 (file)
index 0000000..881a738
--- /dev/null
@@ -0,0 +1,48 @@
+From fcb170a9d825d7db4a3fb870b0300f5a40a8d096 Mon Sep 17 00:00:00 2001
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Date: Sat, 26 Jun 2021 15:50:41 +0800
+Subject: SUNRPC: Fix the batch tasks count wraparound.
+
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+
+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 <hulkci@huawei.com>
+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 <zhangxiaoxu5@huawei.com>
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/sunrpc/sched.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/sunrpc/sched.c
++++ b/net/sunrpc/sched.c
+@@ -476,7 +476,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.4/sunrpc-should-wake-up-the-privileged-task-firstly.patch b/queue-4.4/sunrpc-should-wake-up-the-privileged-task-firstly.patch
new file mode 100644 (file)
index 0000000..968868a
--- /dev/null
@@ -0,0 +1,52 @@
+From 5483b904bf336948826594610af4c9bbb0d9e3aa Mon Sep 17 00:00:00 2001
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Date: Sat, 26 Jun 2021 15:50:42 +0800
+Subject: SUNRPC: Should wake up the privileged task firstly.
+
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+
+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 <hulkci@huawei.com>
+Fixes: 5fcdfacc01f3 ("NFSv4: Return delegations synchronously in evict_inode")
+Cc: stable@vger.kernel.org
+Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/sunrpc/sched.c |    9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/net/sunrpc/sched.c
++++ b/net/sunrpc/sched.c
+@@ -473,6 +473,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];