--- /dev/null
+From 1cf5f151d25fcca94689efd91afa0253621fb33a Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Wed, 2 Feb 2022 16:05:16 -0700
+Subject: Makefile.extrawarn: Move -Wunaligned-access to W=1
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+commit 1cf5f151d25fcca94689efd91afa0253621fb33a upstream.
+
+-Wunaligned-access is a new warning in clang that is default enabled for
+arm and arm64 under certain circumstances within the clang frontend (see
+LLVM commit below). On v5.17-rc2, an ARCH=arm allmodconfig build shows
+1284 total/70 unique instances of this warning (most of the instances
+are in header files), which is quite noisy.
+
+To keep a normal build green through CONFIG_WERROR, only show this
+warning with W=1, which will allow automated build systems to catch new
+instances of the warning so that the total number can be driven down to
+zero eventually since catching unaligned accesses at compile time would
+be generally useful.
+
+Cc: stable@vger.kernel.org
+Link: https://github.com/llvm/llvm-project/commit/35737df4dcd28534bd3090157c224c19b501278a
+Link: https://github.com/ClangBuiltLinux/linux/issues/1569
+Link: https://github.com/ClangBuiltLinux/linux/issues/1576
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
+Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ scripts/Makefile.extrawarn | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/scripts/Makefile.extrawarn
++++ b/scripts/Makefile.extrawarn
+@@ -51,6 +51,7 @@ KBUILD_CFLAGS += -Wno-sign-compare
+ KBUILD_CFLAGS += -Wno-format-zero-length
+ KBUILD_CFLAGS += $(call cc-disable-warning, pointer-to-enum-cast)
+ KBUILD_CFLAGS += -Wno-tautological-constant-out-of-range-compare
++KBUILD_CFLAGS += $(call cc-disable-warning, unaligned-access)
+ endif
+
+ endif
--- /dev/null
+From 13765de8148f71fa795e0a6607de37c49ea5915a Mon Sep 17 00:00:00 2001
+From: Tadeusz Struk <tadeusz.struk@linaro.org>
+Date: Thu, 3 Feb 2022 08:18:46 -0800
+Subject: sched/fair: Fix fault in reweight_entity
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Tadeusz Struk <tadeusz.struk@linaro.org>
+
+commit 13765de8148f71fa795e0a6607de37c49ea5915a upstream.
+
+Syzbot found a GPF in reweight_entity. This has been bisected to
+commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid
+sched_task_group")
+
+There is a race between sched_post_fork() and setpriority(PRIO_PGRP)
+within a thread group that causes a null-ptr-deref in
+reweight_entity() in CFS. The scenario is that the main process spawns
+number of new threads, which then call setpriority(PRIO_PGRP, 0, -20),
+wait, and exit. For each of the new threads the copy_process() gets
+invoked, which adds the new task_struct and calls sched_post_fork()
+for it.
+
+In the above scenario there is a possibility that
+setpriority(PRIO_PGRP) and set_one_prio() will be called for a thread
+in the group that is just being created by copy_process(), and for
+which the sched_post_fork() has not been executed yet. This will
+trigger a null pointer dereference in reweight_entity(), as it will
+try to access the run queue pointer, which hasn't been set.
+
+Before the mentioned change the cfs_rq pointer for the task has been
+set in sched_fork(), which is called much earlier in copy_process(),
+before the new task is added to the thread_group. Now it is done in
+the sched_post_fork(), which is called after that. To fix the issue
+the remove the update_load param from the update_load param() function
+and call reweight_task() only if the task flag doesn't have the
+TASK_NEW flag set.
+
+Fixes: 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid sched_task_group")
+Reported-by: syzbot+af7a719bc92395ee41b3@syzkaller.appspotmail.com
+Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20220203161846.1160750-1-tadeusz.struk@linaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/sched/core.c | 11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+--- a/kernel/sched/core.c
++++ b/kernel/sched/core.c
+@@ -1203,8 +1203,9 @@ int tg_nop(struct task_group *tg, void *
+ }
+ #endif
+
+-static void set_load_weight(struct task_struct *p, bool update_load)
++static void set_load_weight(struct task_struct *p)
+ {
++ bool update_load = !(READ_ONCE(p->__state) & TASK_NEW);
+ int prio = p->static_prio - MAX_RT_PRIO;
+ struct load_weight *load = &p->se.load;
+
+@@ -4392,7 +4393,7 @@ int sched_fork(unsigned long clone_flags
+ p->static_prio = NICE_TO_PRIO(0);
+
+ p->prio = p->normal_prio = p->static_prio;
+- set_load_weight(p, false);
++ set_load_weight(p);
+
+ /*
+ * We don't need the reset flag anymore after the fork. It has
+@@ -6879,7 +6880,7 @@ void set_user_nice(struct task_struct *p
+ put_prev_task(rq, p);
+
+ p->static_prio = NICE_TO_PRIO(nice);
+- set_load_weight(p, true);
++ set_load_weight(p);
+ old_prio = p->prio;
+ p->prio = effective_prio(p);
+
+@@ -7170,7 +7171,7 @@ static void __setscheduler_params(struct
+ */
+ p->rt_priority = attr->sched_priority;
+ p->normal_prio = normal_prio(p);
+- set_load_weight(p, true);
++ set_load_weight(p);
+ }
+
+ /*
+@@ -9409,7 +9410,7 @@ void __init sched_init(void)
+ #endif
+ }
+
+- set_load_weight(&init_task, false);
++ set_load_weight(&init_task);
+
+ /*
+ * The boot idle thread does lazy MMU switching as well:
--- /dev/null
+From 5852ed2a6a39c862c8a3fdf646e1f4e01b91d710 Mon Sep 17 00:00:00 2001
+From: James Smart <jsmart2021@gmail.com>
+Date: Mon, 7 Feb 2022 10:04:42 -0800
+Subject: scsi: lpfc: Reduce log messages seen after firmware download
+
+From: James Smart <jsmart2021@gmail.com>
+
+commit 5852ed2a6a39c862c8a3fdf646e1f4e01b91d710 upstream.
+
+Messages around firmware download were incorrectly tagged as being related
+to discovery trace events. Thus, firmware download status ended up dumping
+the trace log as well as the firmware update message. As there were a
+couple of log messages in this state, the trace log was dumped multiple
+times.
+
+Resolve this by converting from trace events to SLI events.
+
+Link: https://lore.kernel.org/r/20220207180442.72836-1-jsmart2021@gmail.com
+Reviewed-by: Ewan D. Milne <emilne@redhat.com>
+Signed-off-by: James Smart <jsmart2021@gmail.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/lpfc/lpfc_init.c | 2 +-
+ drivers/scsi/lpfc/lpfc_sli.c | 8 +++++++-
+ 2 files changed, 8 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/lpfc/lpfc_init.c
++++ b/drivers/scsi/lpfc/lpfc_init.c
+@@ -2104,7 +2104,7 @@ lpfc_handle_eratt_s4(struct lpfc_hba *ph
+ }
+ if (reg_err1 == SLIPORT_ERR1_REG_ERR_CODE_2 &&
+ reg_err2 == SLIPORT_ERR2_REG_FW_RESTART) {
+- lpfc_printf_log(phba, KERN_ERR, LOG_TRACE_EVENT,
++ lpfc_printf_log(phba, KERN_ERR, LOG_SLI,
+ "3143 Port Down: Firmware Update "
+ "Detected\n");
+ en_rn_msg = false;
+--- a/drivers/scsi/lpfc/lpfc_sli.c
++++ b/drivers/scsi/lpfc/lpfc_sli.c
+@@ -13365,6 +13365,7 @@ lpfc_sli4_eratt_read(struct lpfc_hba *ph
+ uint32_t uerr_sta_hi, uerr_sta_lo;
+ uint32_t if_type, portsmphr;
+ struct lpfc_register portstat_reg;
++ u32 logmask;
+
+ /*
+ * For now, use the SLI4 device internal unrecoverable error
+@@ -13415,7 +13416,12 @@ lpfc_sli4_eratt_read(struct lpfc_hba *ph
+ readl(phba->sli4_hba.u.if_type2.ERR1regaddr);
+ phba->work_status[1] =
+ readl(phba->sli4_hba.u.if_type2.ERR2regaddr);
+- lpfc_printf_log(phba, KERN_ERR, LOG_TRACE_EVENT,
++ logmask = LOG_TRACE_EVENT;
++ if (phba->work_status[0] ==
++ SLIPORT_ERR1_REG_ERR_CODE_2 &&
++ phba->work_status[1] == SLIPORT_ERR2_REG_FW_RESTART)
++ logmask = LOG_SLI;
++ lpfc_printf_log(phba, KERN_ERR, logmask,
+ "2885 Port Status Event: "
+ "port status reg 0x%x, "
+ "port smphr reg 0x%x, "
--- /dev/null
+From c80b27cfd93ba9f5161383f798414609e84729f3 Mon Sep 17 00:00:00 2001
+From: James Smart <jsmart2021@gmail.com>
+Date: Mon, 7 Feb 2022 10:05:16 -0800
+Subject: scsi: lpfc: Remove NVMe support if kernel has NVME_FC disabled
+
+From: James Smart <jsmart2021@gmail.com>
+
+commit c80b27cfd93ba9f5161383f798414609e84729f3 upstream.
+
+The driver is initiating NVMe PRLIs to determine device NVMe support. This
+should not be occurring if CONFIG_NVME_FC support is disabled.
+
+Correct this by changing the default value for FC4 support. Currently it
+defaults to FCP and NVMe. With change, when NVME_FC support is not enabled
+in the kernel, the default value is just FCP.
+
+Link: https://lore.kernel.org/r/20220207180516.73052-1-jsmart2021@gmail.com
+Reviewed-by: Ewan D. Milne <emilne@redhat.com>
+Signed-off-by: James Smart <jsmart2021@gmail.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/lpfc/lpfc.h | 13 ++++++++++---
+ drivers/scsi/lpfc/lpfc_attr.c | 4 ++--
+ 2 files changed, 12 insertions(+), 5 deletions(-)
+
+--- a/drivers/scsi/lpfc/lpfc.h
++++ b/drivers/scsi/lpfc/lpfc.h
+@@ -1165,6 +1165,16 @@ struct lpfc_hba {
+ uint32_t cfg_hostmem_hgp;
+ uint32_t cfg_log_verbose;
+ uint32_t cfg_enable_fc4_type;
++#define LPFC_ENABLE_FCP 1
++#define LPFC_ENABLE_NVME 2
++#define LPFC_ENABLE_BOTH 3
++#if (IS_ENABLED(CONFIG_NVME_FC))
++#define LPFC_MAX_ENBL_FC4_TYPE LPFC_ENABLE_BOTH
++#define LPFC_DEF_ENBL_FC4_TYPE LPFC_ENABLE_BOTH
++#else
++#define LPFC_MAX_ENBL_FC4_TYPE LPFC_ENABLE_FCP
++#define LPFC_DEF_ENBL_FC4_TYPE LPFC_ENABLE_FCP
++#endif
+ uint32_t cfg_aer_support;
+ uint32_t cfg_sriov_nr_virtfn;
+ uint32_t cfg_request_firmware_upgrade;
+@@ -1186,9 +1196,6 @@ struct lpfc_hba {
+ uint32_t cfg_ras_fwlog_func;
+ uint32_t cfg_enable_bbcr; /* Enable BB Credit Recovery */
+ uint32_t cfg_enable_dpp; /* Enable Direct Packet Push */
+-#define LPFC_ENABLE_FCP 1
+-#define LPFC_ENABLE_NVME 2
+-#define LPFC_ENABLE_BOTH 3
+ uint32_t cfg_enable_pbde;
+ uint32_t cfg_enable_mi;
+ struct nvmet_fc_target_port *targetport;
+--- a/drivers/scsi/lpfc/lpfc_attr.c
++++ b/drivers/scsi/lpfc/lpfc_attr.c
+@@ -3978,8 +3978,8 @@ LPFC_ATTR_R(nvmet_mrq_post,
+ * 3 - register both FCP and NVME
+ * Supported values are [1,3]. Default value is 3
+ */
+-LPFC_ATTR_R(enable_fc4_type, LPFC_ENABLE_BOTH,
+- LPFC_ENABLE_FCP, LPFC_ENABLE_BOTH,
++LPFC_ATTR_R(enable_fc4_type, LPFC_DEF_ENBL_FC4_TYPE,
++ LPFC_ENABLE_FCP, LPFC_MAX_ENBL_FC4_TYPE,
+ "Enable FC4 Protocol support - FCP / NVME");
+
+ /*
s390-cio-verify-the-driver-availability-for-path_event-call.patch
bus-mhi-pci_generic-add-mru_default-for-foxconn-sdx55.patch
bus-mhi-pci_generic-add-mru_default-for-cinterion-mv31-w.patch
+x86-sgx-silence-softlockup-detection-when-releasing-large-enclaves.patch
+sched-fair-fix-fault-in-reweight_entity.patch
+makefile.extrawarn-move-wunaligned-access-to-w-1.patch
+scsi-lpfc-remove-nvme-support-if-kernel-has-nvme_fc-disabled.patch
+scsi-lpfc-reduce-log-messages-seen-after-firmware-download.patch
--- /dev/null
+From 8795359e35bc33bf86b6d0765aa7f37431db3b9c Mon Sep 17 00:00:00 2001
+From: Reinette Chatre <reinette.chatre@intel.com>
+Date: Tue, 8 Feb 2022 10:48:07 -0800
+Subject: x86/sgx: Silence softlockup detection when releasing large enclaves
+
+From: Reinette Chatre <reinette.chatre@intel.com>
+
+commit 8795359e35bc33bf86b6d0765aa7f37431db3b9c upstream.
+
+Vijay reported that the "unclobbered_vdso_oversubscribed" selftest
+triggers the softlockup detector.
+
+Actual SGX systems have 128GB of enclave memory or more. The
+"unclobbered_vdso_oversubscribed" selftest creates one enclave which
+consumes all of the enclave memory on the system. Tearing down such a
+large enclave takes around a minute, most of it in the loop where
+the EREMOVE instruction is applied to each individual 4k enclave page.
+
+Spending one minute in a loop triggers the softlockup detector.
+
+Add a cond_resched() to give other tasks a chance to run and placate
+the softlockup detector.
+
+Cc: stable@vger.kernel.org
+Fixes: 1728ab54b4be ("x86/sgx: Add a page reclaimer")
+Reported-by: Vijay Dhanraj <vijay.dhanraj@intel.com>
+Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
+Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
+Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
+Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
+Tested-by: Jarkko Sakkinen <jarkko@kernel.org> (kselftest as sanity check)
+Link: https://lkml.kernel.org/r/ced01cac1e75f900251b0a4ae1150aa8ebd295ec.1644345232.git.reinette.chatre@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/sgx/encl.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/kernel/cpu/sgx/encl.c
++++ b/arch/x86/kernel/cpu/sgx/encl.c
+@@ -410,6 +410,8 @@ void sgx_encl_release(struct kref *ref)
+ }
+
+ kfree(entry);
++ /* Invoke scheduler to prevent soft lockups. */
++ cond_resched();
+ }
+
+ xa_destroy(&encl->page_array);
projects / thirdparty / kernel / stable-queue.git / commitdiff
