]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.19-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 16 Sep 2021 13:34:42 +0000 (15:34 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 16 Sep 2021 13:34:42 +0000 (15:34 +0200)
added patches:
cpufreq-powernv-fix-init_chip_info-initialization-in-numa-off.patch
drm-amdgpu-fix-bug_on-assert.patch
memcg-enable-accounting-for-pids-in-nested-pid-namespaces.patch
mm-hugetlb-initialize-hugetlb_usage-in-mm_init.patch
ovl-fix-bug_on-in-may_delete-when-called-from-ovl_cleanup.patch
parisc-fix-crash-with-signals-and-alloca.patch
platform-chrome-cros_ec_proto-send-command-again-when-timeout-occurs.patch
scsi-buslogic-fix-missing-pr_cont-use.patch
scsi-qla2xxx-sync-queue-idx-with-queue_pair_map-idx.patch

queue-4.19/cpufreq-powernv-fix-init_chip_info-initialization-in-numa-off.patch [new file with mode: 0644]
queue-4.19/drm-amdgpu-fix-bug_on-assert.patch [new file with mode: 0644]
queue-4.19/memcg-enable-accounting-for-pids-in-nested-pid-namespaces.patch [new file with mode: 0644]
queue-4.19/mm-hugetlb-initialize-hugetlb_usage-in-mm_init.patch [new file with mode: 0644]
queue-4.19/ovl-fix-bug_on-in-may_delete-when-called-from-ovl_cleanup.patch [new file with mode: 0644]
queue-4.19/parisc-fix-crash-with-signals-and-alloca.patch [new file with mode: 0644]
queue-4.19/platform-chrome-cros_ec_proto-send-command-again-when-timeout-occurs.patch [new file with mode: 0644]
queue-4.19/scsi-buslogic-fix-missing-pr_cont-use.patch [new file with mode: 0644]
queue-4.19/scsi-qla2xxx-sync-queue-idx-with-queue_pair_map-idx.patch [new file with mode: 0644]
queue-4.19/series

diff --git a/queue-4.19/cpufreq-powernv-fix-init_chip_info-initialization-in-numa-off.patch b/queue-4.19/cpufreq-powernv-fix-init_chip_info-initialization-in-numa-off.patch
new file mode 100644 (file)
index 0000000..e0b6062
--- /dev/null
@@ -0,0 +1,89 @@
+From f34ee9cb2c5ac5af426fee6fa4591a34d187e696 Mon Sep 17 00:00:00 2001
+From: "Pratik R. Sampat" <psampat@linux.ibm.com>
+Date: Wed, 28 Jul 2021 17:35:00 +0530
+Subject: cpufreq: powernv: Fix init_chip_info initialization in numa=off
+
+From: Pratik R. Sampat <psampat@linux.ibm.com>
+
+commit f34ee9cb2c5ac5af426fee6fa4591a34d187e696 upstream.
+
+In the numa=off kernel command-line configuration init_chip_info() loops
+around the number of chips and attempts to copy the cpumask of that node
+which is NULL for all iterations after the first chip.
+
+Hence, store the cpu mask for each chip instead of derving cpumask from
+node while populating the "chips" struct array and copy that to the
+chips[i].mask
+
+Fixes: 053819e0bf84 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level")
+Cc: stable@vger.kernel.org # v4.3+
+Reported-by: Shirisha Ganta <shirisha.ganta1@ibm.com>
+Signed-off-by: Pratik R. Sampat <psampat@linux.ibm.com>
+Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
+[mpe: Rename goto label to out_free_chip_cpu_mask]
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20210728120500.87549-2-psampat@linux.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpufreq/powernv-cpufreq.c |   16 ++++++++++++++--
+ 1 file changed, 14 insertions(+), 2 deletions(-)
+
+--- a/drivers/cpufreq/powernv-cpufreq.c
++++ b/drivers/cpufreq/powernv-cpufreq.c
+@@ -46,6 +46,7 @@
+ #define MAX_PSTATE_SHIFT      32
+ #define LPSTATE_SHIFT         48
+ #define GPSTATE_SHIFT         56
++#define MAX_NR_CHIPS          32
+ #define MAX_RAMP_DOWN_TIME                            5120
+ /*
+@@ -1051,12 +1052,20 @@ static int init_chip_info(void)
+       unsigned int *chip;
+       unsigned int cpu, i;
+       unsigned int prev_chip_id = UINT_MAX;
++      cpumask_t *chip_cpu_mask;
+       int ret = 0;
+       chip = kcalloc(num_possible_cpus(), sizeof(*chip), GFP_KERNEL);
+       if (!chip)
+               return -ENOMEM;
++      /* Allocate a chip cpu mask large enough to fit mask for all chips */
++      chip_cpu_mask = kcalloc(MAX_NR_CHIPS, sizeof(cpumask_t), GFP_KERNEL);
++      if (!chip_cpu_mask) {
++              ret = -ENOMEM;
++              goto free_and_return;
++      }
++
+       for_each_possible_cpu(cpu) {
+               unsigned int id = cpu_to_chip_id(cpu);
+@@ -1064,22 +1073,25 @@ static int init_chip_info(void)
+                       prev_chip_id = id;
+                       chip[nr_chips++] = id;
+               }
++              cpumask_set_cpu(cpu, &chip_cpu_mask[nr_chips-1]);
+       }
+       chips = kcalloc(nr_chips, sizeof(struct chip), GFP_KERNEL);
+       if (!chips) {
+               ret = -ENOMEM;
+-              goto free_and_return;
++              goto out_free_chip_cpu_mask;
+       }
+       for (i = 0; i < nr_chips; i++) {
+               chips[i].id = chip[i];
+-              cpumask_copy(&chips[i].mask, cpumask_of_node(chip[i]));
++              cpumask_copy(&chips[i].mask, &chip_cpu_mask[i]);
+               INIT_WORK(&chips[i].throttle, powernv_cpufreq_work_fn);
+               for_each_cpu(cpu, &chips[i].mask)
+                       per_cpu(chip_info, cpu) =  &chips[i];
+       }
++out_free_chip_cpu_mask:
++      kfree(chip_cpu_mask);
+ free_and_return:
+       kfree(chip);
+       return ret;
diff --git a/queue-4.19/drm-amdgpu-fix-bug_on-assert.patch b/queue-4.19/drm-amdgpu-fix-bug_on-assert.patch
new file mode 100644 (file)
index 0000000..31a19b0
--- /dev/null
@@ -0,0 +1,35 @@
+From ea7acd7c5967542353430947f3faf699e70602e5 Mon Sep 17 00:00:00 2001
+From: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
+Date: Tue, 22 Jun 2021 12:23:38 -0400
+Subject: drm/amdgpu: Fix BUG_ON assert
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
+
+commit ea7acd7c5967542353430947f3faf699e70602e5 upstream.
+
+With added CPU domain to placement you can have
+now 3 placemnts at once.
+
+CC: stable@kernel.org
+Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210622162339.761651-5-andrey.grodzovsky@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+@@ -216,7 +216,7 @@ void amdgpu_bo_placement_from_domain(str
+               c++;
+       }
+-      BUG_ON(c >= AMDGPU_BO_MAX_PLACEMENTS);
++      BUG_ON(c > AMDGPU_BO_MAX_PLACEMENTS);
+       placement->num_placement = c;
+       placement->placement = places;
diff --git a/queue-4.19/memcg-enable-accounting-for-pids-in-nested-pid-namespaces.patch b/queue-4.19/memcg-enable-accounting-for-pids-in-nested-pid-namespaces.patch
new file mode 100644 (file)
index 0000000..4841081
--- /dev/null
@@ -0,0 +1,62 @@
+From fab827dbee8c2e06ca4ba000fa6c48bcf9054aba Mon Sep 17 00:00:00 2001
+From: Vasily Averin <vvs@virtuozzo.com>
+Date: Thu, 2 Sep 2021 14:54:57 -0700
+Subject: memcg: enable accounting for pids in nested pid namespaces
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Vasily Averin <vvs@virtuozzo.com>
+
+commit fab827dbee8c2e06ca4ba000fa6c48bcf9054aba upstream.
+
+Commit 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg")
+enabled memcg accounting for pids allocated from init_pid_ns.pid_cachep,
+but forgot to adjust the setting for nested pid namespaces.  As a result,
+pid memory is not accounted exactly where it is really needed, inside
+memcg-limited containers with their own pid namespaces.
+
+Pid was one the first kernel objects enabled for memcg accounting.
+init_pid_ns.pid_cachep marked by SLAB_ACCOUNT and we can expect that any
+new pids in the system are memcg-accounted.
+
+Though recently I've noticed that it is wrong.  nested pid namespaces
+creates own slab caches for pid objects, nested pids have increased size
+because contain id both for all parent and for own pid namespaces.  The
+problem is that these slab caches are _NOT_ marked by SLAB_ACCOUNT, as a
+result any pids allocated in nested pid namespaces are not
+memcg-accounted.
+
+Pid struct in nested pid namespace consumes up to 500 bytes memory, 100000
+such objects gives us up to ~50Mb unaccounted memory, this allow container
+to exceed assigned memcg limits.
+
+Link: https://lkml.kernel.org/r/8b6de616-fd1a-02c6-cbdb-976ecdcfa604@virtuozzo.com
+Fixes: 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg")
+Cc: stable@vger.kernel.org
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Reviewed-by: Michal Koutný <mkoutny@suse.com>
+Reviewed-by: Shakeel Butt <shakeelb@google.com>
+Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
+Acked-by: Roman Gushchin <guro@fb.com>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/pid_namespace.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/kernel/pid_namespace.c
++++ b/kernel/pid_namespace.c
+@@ -52,7 +52,8 @@ static struct kmem_cache *create_pid_cac
+       mutex_lock(&pid_caches_mutex);
+       /* Name collision forces to do allocation under mutex. */
+       if (!*pkc)
+-              *pkc = kmem_cache_create(name, len, 0, SLAB_HWCACHE_ALIGN, 0);
++              *pkc = kmem_cache_create(name, len, 0,
++                                       SLAB_HWCACHE_ALIGN | SLAB_ACCOUNT, 0);
+       mutex_unlock(&pid_caches_mutex);
+       /* current can fail, but someone else can succeed. */
+       return READ_ONCE(*pkc);
diff --git a/queue-4.19/mm-hugetlb-initialize-hugetlb_usage-in-mm_init.patch b/queue-4.19/mm-hugetlb-initialize-hugetlb_usage-in-mm_init.patch
new file mode 100644 (file)
index 0000000..133b12d
--- /dev/null
@@ -0,0 +1,73 @@
+From 13db8c50477d83ad3e3b9b0ae247e5cd833a7ae4 Mon Sep 17 00:00:00 2001
+From: Liu Zixian <liuzixian4@huawei.com>
+Date: Wed, 8 Sep 2021 18:10:05 -0700
+Subject: mm/hugetlb: initialize hugetlb_usage in mm_init
+
+From: Liu Zixian <liuzixian4@huawei.com>
+
+commit 13db8c50477d83ad3e3b9b0ae247e5cd833a7ae4 upstream.
+
+After fork, the child process will get incorrect (2x) hugetlb_usage.  If
+a process uses 5 2MB hugetlb pages in an anonymous mapping,
+
+       HugetlbPages:      10240 kB
+
+and then forks, the child will show,
+
+       HugetlbPages:      20480 kB
+
+The reason for double the amount is because hugetlb_usage will be copied
+from the parent and then increased when we copy page tables from parent
+to child.  Child will have 2x actual usage.
+
+Fix this by adding hugetlb_count_init in mm_init.
+
+Link: https://lkml.kernel.org/r/20210826071742.877-1-liuzixian4@huawei.com
+Fixes: 5d317b2b6536 ("mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status")
+Signed-off-by: Liu Zixian <liuzixian4@huawei.com>
+Reviewed-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
+Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/hugetlb.h |    9 +++++++++
+ kernel/fork.c           |    1 +
+ 2 files changed, 10 insertions(+)
+
+--- a/include/linux/hugetlb.h
++++ b/include/linux/hugetlb.h
+@@ -513,6 +513,11 @@ static inline spinlock_t *huge_pte_lockp
+ void hugetlb_report_usage(struct seq_file *m, struct mm_struct *mm);
++static inline void hugetlb_count_init(struct mm_struct *mm)
++{
++      atomic_long_set(&mm->hugetlb_usage, 0);
++}
++
+ static inline void hugetlb_count_add(long l, struct mm_struct *mm)
+ {
+       atomic_long_add(l, &mm->hugetlb_usage);
+@@ -593,6 +598,10 @@ static inline spinlock_t *huge_pte_lockp
+       return &mm->page_table_lock;
+ }
++static inline void hugetlb_count_init(struct mm_struct *mm)
++{
++}
++
+ static inline void hugetlb_report_usage(struct seq_file *f, struct mm_struct *m)
+ {
+ }
+--- a/kernel/fork.c
++++ b/kernel/fork.c
+@@ -964,6 +964,7 @@ static struct mm_struct *mm_init(struct
+       mm->pmd_huge_pte = NULL;
+ #endif
+       mm_init_uprobes_state(mm);
++      hugetlb_count_init(mm);
+       if (current->mm) {
+               mm->flags = current->mm->flags & MMF_INIT_MASK;
diff --git a/queue-4.19/ovl-fix-bug_on-in-may_delete-when-called-from-ovl_cleanup.patch b/queue-4.19/ovl-fix-bug_on-in-may_delete-when-called-from-ovl_cleanup.patch
new file mode 100644 (file)
index 0000000..1b7edc9
--- /dev/null
@@ -0,0 +1,39 @@
+From 52d5a0c6bd8a89f460243ed937856354f8f253a3 Mon Sep 17 00:00:00 2001
+From: chenying <chenying.kernel@bytedance.com>
+Date: Mon, 16 Aug 2021 18:02:56 +0800
+Subject: ovl: fix BUG_ON() in may_delete() when called from ovl_cleanup()
+
+From: chenying <chenying.kernel@bytedance.com>
+
+commit 52d5a0c6bd8a89f460243ed937856354f8f253a3 upstream.
+
+If function ovl_instantiate() returns an error, ovl_cleanup will be called
+and try to remove newdentry from wdir, but the newdentry has been moved to
+udir at this time.  This will causes BUG_ON(victim->d_parent->d_inode !=
+dir) in fs/namei.c:may_delete.
+
+Signed-off-by: chenying <chenying.kernel@bytedance.com>
+Fixes: 01b39dcc9568 ("ovl: use inode_insert5() to hash a newly created inode")
+Link: https://lore.kernel.org/linux-unionfs/e6496a94-a161-dc04-c38a-d2544633acb4@bytedance.com/
+Cc: <stable@vger.kernel.org> # v4.18
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/overlayfs/dir.c |    6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/fs/overlayfs/dir.c
++++ b/fs/overlayfs/dir.c
+@@ -517,8 +517,10 @@ static int ovl_create_over_whiteout(stru
+                       goto out_cleanup;
+       }
+       err = ovl_instantiate(dentry, inode, newdentry, hardlink);
+-      if (err)
+-              goto out_cleanup;
++      if (err) {
++              ovl_cleanup(udir, newdentry);
++              dput(newdentry);
++      }
+ out_dput:
+       dput(upper);
+ out_unlock:
diff --git a/queue-4.19/parisc-fix-crash-with-signals-and-alloca.patch b/queue-4.19/parisc-fix-crash-with-signals-and-alloca.patch
new file mode 100644 (file)
index 0000000..0f1e8d1
--- /dev/null
@@ -0,0 +1,84 @@
+From 030f653078316a9cc9ca6bd1b0234dcf858be35d Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Mon, 30 Aug 2021 05:42:27 -0400
+Subject: parisc: fix crash with signals and alloca
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 030f653078316a9cc9ca6bd1b0234dcf858be35d upstream.
+
+I was debugging some crashes on parisc and I found out that there is a
+crash possibility if a function using alloca is interrupted by a signal.
+The reason for the crash is that the gcc alloca implementation leaves
+garbage in the upper 32 bits of the sp register. This normally doesn't
+matter (the upper bits are ignored because the PSW W-bit is clear),
+however the signal delivery routine in the kernel uses full 64 bits of sp
+and it fails with -EFAULT if the upper 32 bits are not zero.
+
+I created this program that demonstrates the problem:
+
+#include <stdlib.h>
+#include <unistd.h>
+#include <signal.h>
+#include <alloca.h>
+
+static __attribute__((noinline,noclone)) void aa(int *size)
+{
+       void * volatile p = alloca(-*size);
+       while (1) ;
+}
+
+static void handler(int sig)
+{
+       write(1, "signal delivered\n", 17);
+       _exit(0);
+}
+
+int main(void)
+{
+       int size = -0x100;
+       signal(SIGALRM, handler);
+       alarm(1);
+       aa(&size);
+}
+
+If you compile it with optimizations, it will crash.
+The "aa" function has this disassembly:
+
+000106a0 <aa>:
+   106a0:       08 03 02 41     copy r3,r1
+   106a4:       08 1e 02 43     copy sp,r3
+   106a8:       6f c1 00 80     stw,ma r1,40(sp)
+   106ac:       37 dc 3f c1     ldo -20(sp),ret0
+   106b0:       0c 7c 12 90     stw ret0,8(r3)
+   106b4:       0f 40 10 9c     ldw 0(r26),ret0                ; ret0 = 0x00000000FFFFFF00
+   106b8:       97 9c 00 7e     subi 3f,ret0,ret0      ; ret0 = 0xFFFFFFFF0000013F
+   106bc:       d7 80 1c 1a     depwi 0,31,6,ret0      ; ret0 = 0xFFFFFFFF00000100
+   106c0:       0b 9e 0a 1e     add,l sp,ret0,sp       ;   sp = 0xFFFFFFFFxxxxxxxx
+   106c4:       e8 1f 1f f7     b,l,n 106c4 <aa+0x24>,r0
+
+This patch fixes the bug by truncating the "usp" variable to 32 bits.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/kernel/signal.c |    6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/arch/parisc/kernel/signal.c
++++ b/arch/parisc/kernel/signal.c
+@@ -239,6 +239,12 @@ setup_rt_frame(struct ksignal *ksig, sig
+ #endif
+       
+       usp = (regs->gr[30] & ~(0x01UL));
++#ifdef CONFIG_64BIT
++      if (is_compat_task()) {
++              /* The gcc alloca implementation leaves garbage in the upper 32 bits of sp */
++              usp = (compat_uint_t)usp;
++      }
++#endif
+       /*FIXME: frame_size parameter is unused, remove it. */
+       frame = get_sigframe(&ksig->ka, usp, sizeof(*frame));
diff --git a/queue-4.19/platform-chrome-cros_ec_proto-send-command-again-when-timeout-occurs.patch b/queue-4.19/platform-chrome-cros_ec_proto-send-command-again-when-timeout-occurs.patch
new file mode 100644 (file)
index 0000000..78b7290
--- /dev/null
@@ -0,0 +1,41 @@
+From 3abc16af57c9939724df92fcbda296b25cc95168 Mon Sep 17 00:00:00 2001
+From: Patryk Duda <pdk@semihalf.com>
+Date: Tue, 18 May 2021 16:07:58 +0200
+Subject: platform/chrome: cros_ec_proto: Send command again when timeout occurs
+
+From: Patryk Duda <pdk@semihalf.com>
+
+commit 3abc16af57c9939724df92fcbda296b25cc95168 upstream.
+
+Sometimes kernel is trying to probe Fingerprint MCU (FPMCU) when it
+hasn't initialized SPI yet. This can happen because FPMCU is restarted
+during system boot and kernel can send message in short window
+eg. between sysjump to RW and SPI initialization.
+
+Cc: <stable@vger.kernel.org> # 4.4+
+Signed-off-by: Patryk Duda <pdk@semihalf.com>
+Link: https://lore.kernel.org/r/20210518140758.29318-1-pdk@semihalf.com
+Signed-off-by: Benson Leung <bleung@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/chrome/cros_ec_proto.c |    9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/platform/chrome/cros_ec_proto.c
++++ b/drivers/platform/chrome/cros_ec_proto.c
+@@ -219,6 +219,15 @@ static int cros_ec_host_command_proto_qu
+       msg->insize = sizeof(struct ec_response_get_protocol_info);
+       ret = send_command(ec_dev, msg);
++      /*
++       * Send command once again when timeout occurred.
++       * Fingerprint MCU (FPMCU) is restarted during system boot which
++       * introduces small window in which FPMCU won't respond for any
++       * messages sent by kernel. There is no need to wait before next
++       * attempt because we waited at least EC_MSG_DEADLINE_MS.
++       */
++      if (ret == -ETIMEDOUT)
++              ret = send_command(ec_dev, msg);
+       if (ret < 0) {
+               dev_dbg(ec_dev->dev,
diff --git a/queue-4.19/scsi-buslogic-fix-missing-pr_cont-use.patch b/queue-4.19/scsi-buslogic-fix-missing-pr_cont-use.patch
new file mode 100644 (file)
index 0000000..ea19c28
--- /dev/null
@@ -0,0 +1,108 @@
+From 44d01fc86d952f5a8b8b32bdb4841504d5833d95 Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Tue, 20 Apr 2021 20:01:47 +0200
+Subject: scsi: BusLogic: Fix missing pr_cont() use
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit 44d01fc86d952f5a8b8b32bdb4841504d5833d95 upstream.
+
+Update BusLogic driver's messaging system to use pr_cont() for continuation
+lines, bringing messy output:
+
+pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17
+scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 *****
+scsi: Copyright 1995-1998 by Leonard N. Zubkoff <lnz@dandelion.com>
+scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter
+scsi0:   Firmware Version: 5.07B, I/O Address: 0x7000, IRQ Channel: 17/Level
+scsi0:   PCI Bus: 0, Device: 19, Address:
+0xE0012000,
+Host Adapter SCSI ID: 7
+scsi0:   Parity Checking: Enabled, Extended Translation: Enabled
+scsi0:   Synchronous Negotiation: Ultra, Wide Negotiation: Enabled
+scsi0:   Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled
+scsi0:   Scatter/Gather Limit: 128 of 8192 segments, Mailboxes: 211
+scsi0:   Driver Queue Depth: 211, Host Adapter Queue Depth: 192
+scsi0:   Tagged Queue Depth:
+Automatic
+, Untagged Queue Depth: 3
+scsi0:   SCSI Bus Termination: Both Enabled
+, SCAM: Disabled
+
+scsi0: *** BusLogic BT-958 Initialized Successfully ***
+scsi host0: BusLogic BT-958
+
+back to order:
+
+pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17
+scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 *****
+scsi: Copyright 1995-1998 by Leonard N. Zubkoff <lnz@dandelion.com>
+scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter
+scsi0:   Firmware Version: 5.07B, I/O Address: 0x7000, IRQ Channel: 17/Level
+scsi0:   PCI Bus: 0, Device: 19, Address: 0xE0012000, Host Adapter SCSI ID: 7
+scsi0:   Parity Checking: Enabled, Extended Translation: Enabled
+scsi0:   Synchronous Negotiation: Ultra, Wide Negotiation: Enabled
+scsi0:   Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled
+scsi0:   Scatter/Gather Limit: 128 of 8192 segments, Mailboxes: 211
+scsi0:   Driver Queue Depth: 211, Host Adapter Queue Depth: 192
+scsi0:   Tagged Queue Depth: Automatic, Untagged Queue Depth: 3
+scsi0:   SCSI Bus Termination: Both Enabled, SCAM: Disabled
+scsi0: *** BusLogic BT-958 Initialized Successfully ***
+scsi host0: BusLogic BT-958
+
+Also diagnostic output such as with the BusLogic=TraceConfiguration
+parameter is affected and becomes vertical and therefore hard to read.
+This has now been corrected, e.g.:
+
+pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17
+blogic_cmd(86) Status = 30:  4 ==>  4: FF 05 93 00
+blogic_cmd(95) Status = 28: (Modify I/O Address)
+blogic_cmd(91) Status = 30:  1 ==>  1: 01
+blogic_cmd(04) Status = 30:  4 ==>  4: 41 41 35 30
+blogic_cmd(8D) Status = 30: 14 ==> 14: 45 DC 00 20 00 00 00 00 00 40 30 37 42 1D
+scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 *****
+scsi: Copyright 1995-1998 by Leonard N. Zubkoff <lnz@dandelion.com>
+blogic_cmd(04) Status = 30:  4 ==>  4: 41 41 35 30
+blogic_cmd(0B) Status = 30:  3 ==>  3: 00 08 07
+blogic_cmd(0D) Status = 30: 34 ==> 34: 03 01 07 04 00 00 00 00 00 00 00 00 00 00 00 00 FF 42 44 46 FF 00 00 00 00 00 00 00 00 00 FF 00 FF 00
+blogic_cmd(8D) Status = 30: 14 ==> 14: 45 DC 00 20 00 00 00 00 00 40 30 37 42 1D
+blogic_cmd(84) Status = 30:  1 ==>  1: 37
+blogic_cmd(8B) Status = 30:  5 ==>  5: 39 35 38 20 20
+blogic_cmd(85) Status = 30:  1 ==>  1: 42
+blogic_cmd(86) Status = 30:  4 ==>  4: FF 05 93 00
+blogic_cmd(91) Status = 30: 64 ==> 64: 41 46 3E 20 39 35 38 20 20 00 C4 00 04 01 07 2F 07 04 35 FF FF FF FF FF FF FF FF FF FF 01 00 FE FF 08 FF FF 00 00 00 00 00 00 00 01 00 01 00 00 FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 FC
+scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter
+
+etc.
+
+Link: https://lore.kernel.org/r/alpine.DEB.2.21.2104201940430.44318@angie.orcam.me.uk
+Fixes: 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines")
+Cc: stable@vger.kernel.org # v4.9+
+Acked-by: Khalid Aziz <khalid@gonehiking.org>
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/BusLogic.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/BusLogic.c
++++ b/drivers/scsi/BusLogic.c
+@@ -3605,7 +3605,7 @@ static void blogic_msg(enum blogic_msgle
+                       if (buf[0] != '\n' || len > 1)
+                               printk("%sscsi%d: %s", blogic_msglevelmap[msglevel], adapter->host_no, buf);
+               } else
+-                      printk("%s", buf);
++                      pr_cont("%s", buf);
+       } else {
+               if (begin) {
+                       if (adapter != NULL && adapter->adapter_initd)
+@@ -3613,7 +3613,7 @@ static void blogic_msg(enum blogic_msgle
+                       else
+                               printk("%s%s", blogic_msglevelmap[msglevel], buf);
+               } else
+-                      printk("%s", buf);
++                      pr_cont("%s", buf);
+       }
+       begin = (buf[len - 1] == '\n');
+ }
diff --git a/queue-4.19/scsi-qla2xxx-sync-queue-idx-with-queue_pair_map-idx.patch b/queue-4.19/scsi-qla2xxx-sync-queue-idx-with-queue_pair_map-idx.patch
new file mode 100644 (file)
index 0000000..f75afff
--- /dev/null
@@ -0,0 +1,98 @@
+From c8fadf019964d0eb1da410ba8b629494d3339db9 Mon Sep 17 00:00:00 2001
+From: Saurav Kashyap <skashyap@marvell.com>
+Date: Mon, 9 Aug 2021 21:37:19 -0700
+Subject: scsi: qla2xxx: Sync queue idx with queue_pair_map idx
+
+From: Saurav Kashyap <skashyap@marvell.com>
+
+commit c8fadf019964d0eb1da410ba8b629494d3339db9 upstream.
+
+The first invocation of function find_first_zero_bit will return 0 and
+queue_id gets set to 0.
+
+An index of queue_pair_map also gets set to 0.
+
+       qpair_id = find_first_zero_bit(ha->qpair_qid_map, ha->max_qpairs);
+
+        set_bit(qpair_id, ha->qpair_qid_map);
+        ha->queue_pair_map[qpair_id] = qpair;
+
+In the alloc_queue callback driver checks the map, if queue is already
+allocated:
+
+       ha->queue_pair_map[qidx]
+
+This works fine as long as max_qpairs is greater than nvme_max_hw_queues(8)
+since the size of the queue_pair_map is equal to max_qpair. In case nr_cpus
+is less than 8, max_qpairs is less than 8. This creates wrong value
+returned as qpair.
+
+[ 1572.353669] qla2xxx [0000:24:00.3]-2121:6: Returning existing qpair of 4e00000000000000 for idx=2
+[ 1572.354458] general protection fault: 0000 [#1] SMP PTI
+[ 1572.354461] CPU: 1 PID: 44 Comm: kworker/1:1H Kdump: loaded Tainted: G          IOE    --------- -  - 4.18.0-304.el8.x86_64 #1
+[ 1572.354462] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 03/01/2013
+[ 1572.354467] Workqueue: kblockd blk_mq_run_work_fn
+[ 1572.354485] RIP: 0010:qla_nvme_post_cmd+0x92/0x760 [qla2xxx]
+[ 1572.354486] Code: 84 24 5c 01 00 00 00 00 b8 0a 74 1e 66 83 79 48 00 0f 85 a8 03 00 00 48 8b 44 24 08 48 89 ee 4c 89 e7 8b 50 24 e8 5e 8e 00 00 <f0> 41 ff 47 04 0f ae f0 41 f6 47 24 04 74 19 f0 41 ff 4f 04 b8 f0
+[ 1572.354487] RSP: 0018:ffff9c81c645fc90 EFLAGS: 00010246
+[ 1572.354489] RAX: 0000000000000001 RBX: ffff8ea3e5070138 RCX: 0000000000000001
+[ 1572.354490] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8ea4c866b800
+[ 1572.354491] RBP: ffff8ea4c866b800 R08: 0000000000005010 R09: ffff8ea4c866b800
+[ 1572.354492] R10: 0000000000000001 R11: 000000069d1ca3ff R12: ffff8ea4bc460000
+[ 1572.354493] R13: ffff8ea3e50702b0 R14: ffff8ea4c4c16a58 R15: 4e00000000000000
+[ 1572.354494] FS:  0000000000000000(0000) GS:ffff8ea4dfd00000(0000) knlGS:0000000000000000
+[ 1572.354495] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 1572.354496] CR2: 000055884504fa58 CR3: 00000005a1410001 CR4: 00000000000606e0
+[ 1572.354497] Call Trace:
+[ 1572.354503]  ? check_preempt_curr+0x62/0x90
+[ 1572.354506]  ? dma_direct_map_sg+0x72/0x1f0
+[ 1572.354509]  ? nvme_fc_start_fcp_op.part.32+0x175/0x460 [nvme_fc]
+[ 1572.354511]  ? blk_mq_dispatch_rq_list+0x11c/0x730
+[ 1572.354515]  ? __switch_to_asm+0x35/0x70
+[ 1572.354516]  ? __switch_to_asm+0x41/0x70
+[ 1572.354518]  ? __switch_to_asm+0x35/0x70
+[ 1572.354519]  ? __switch_to_asm+0x41/0x70
+[ 1572.354521]  ? __switch_to_asm+0x35/0x70
+[ 1572.354522]  ? __switch_to_asm+0x41/0x70
+[ 1572.354523]  ? __switch_to_asm+0x35/0x70
+[ 1572.354525]  ? entry_SYSCALL_64_after_hwframe+0xb9/0xca
+[ 1572.354527]  ? __switch_to_asm+0x41/0x70
+[ 1572.354529]  ? __blk_mq_sched_dispatch_requests+0xc6/0x170
+[ 1572.354531]  ? blk_mq_sched_dispatch_requests+0x30/0x60
+[ 1572.354532]  ? __blk_mq_run_hw_queue+0x51/0xd0
+[ 1572.354535]  ? process_one_work+0x1a7/0x360
+[ 1572.354537]  ? create_worker+0x1a0/0x1a0
+[ 1572.354538]  ? worker_thread+0x30/0x390
+[ 1572.354540]  ? create_worker+0x1a0/0x1a0
+[ 1572.354541]  ? kthread+0x116/0x130
+[ 1572.354543]  ? kthread_flush_work_fn+0x10/0x10
+[ 1572.354545]  ? ret_from_fork+0x35/0x40
+
+Fix is to use index 0 for admin and first IO queue.
+
+Link: https://lore.kernel.org/r/20210810043720.1137-14-njavali@marvell.com
+Fixes: e84067d74301 ("scsi: qla2xxx: Add FC-NVMe F/W initialization and transport registration")
+Cc: stable@vger.kernel.org
+Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
+Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
+Signed-off-by: Nilesh Javali <njavali@marvell.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/qla2xxx/qla_nvme.c |    5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/qla2xxx/qla_nvme.c
++++ b/drivers/scsi/qla2xxx/qla_nvme.c
+@@ -88,8 +88,9 @@ static int qla_nvme_alloc_queue(struct n
+       struct qla_hw_data *ha;
+       struct qla_qpair *qpair;
+-      if (!qidx)
+-              qidx++;
++      /* Map admin queue and 1st IO queue to index 0 */
++      if (qidx)
++              qidx--;
+       vha = (struct scsi_qla_host *)lport->private;
+       ha = vha->hw;
index 6f38f5d2299bd6c1aeb7da3c1ddc3bec2a684462..ba6fc6e22d183d7a4a2615a93c0785bf3aeb87b9 100644 (file)
@@ -239,3 +239,12 @@ ath9k-fix-oob-read-ar9300_eeprom_restore_internal.patch
 ath9k-fix-sleeping-in-atomic-context.patch
 net-fix-null-pointer-reference-in-cipso_v4_doi_free.patch
 net-w5100-check-return-value-after-calling-platform_.patch
+parisc-fix-crash-with-signals-and-alloca.patch
+ovl-fix-bug_on-in-may_delete-when-called-from-ovl_cleanup.patch
+scsi-buslogic-fix-missing-pr_cont-use.patch
+scsi-qla2xxx-sync-queue-idx-with-queue_pair_map-idx.patch
+cpufreq-powernv-fix-init_chip_info-initialization-in-numa-off.patch
+mm-hugetlb-initialize-hugetlb_usage-in-mm_init.patch
+memcg-enable-accounting-for-pids-in-nested-pid-namespaces.patch
+platform-chrome-cros_ec_proto-send-command-again-when-timeout-occurs.patch
+drm-amdgpu-fix-bug_on-assert.patch