From 76f42f1f492e1541241bb5ff83cb40c4813fbfe9 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 14 Feb 2022 08:14:12 +0100 Subject: [PATCH] 5.16-stable patches added patches: makefile.extrawarn-move-wunaligned-access-to-w-1.patch sched-fair-fix-fault-in-reweight_entity.patch scsi-lpfc-reduce-log-messages-seen-after-firmware-download.patch scsi-lpfc-remove-nvme-support-if-kernel-has-nvme_fc-disabled.patch x86-sgx-silence-softlockup-detection-when-releasing-large-enclaves.patch --- ...rawarn-move-wunaligned-access-to-w-1.patch | 43 ++++++++ ...ed-fair-fix-fault-in-reweight_entity.patch | 100 ++++++++++++++++++ ...essages-seen-after-firmware-download.patch | 62 +++++++++++ ...pport-if-kernel-has-nvme_fc-disabled.patch | 68 ++++++++++++ queue-5.16/series | 5 + ...ection-when-releasing-large-enclaves.patch | 48 +++++++++ 6 files changed, 326 insertions(+) create mode 100644 queue-5.16/makefile.extrawarn-move-wunaligned-access-to-w-1.patch create mode 100644 queue-5.16/sched-fair-fix-fault-in-reweight_entity.patch create mode 100644 queue-5.16/scsi-lpfc-reduce-log-messages-seen-after-firmware-download.patch create mode 100644 queue-5.16/scsi-lpfc-remove-nvme-support-if-kernel-has-nvme_fc-disabled.patch create mode 100644 queue-5.16/x86-sgx-silence-softlockup-detection-when-releasing-large-enclaves.patch diff --git a/queue-5.16/makefile.extrawarn-move-wunaligned-access-to-w-1.patch b/queue-5.16/makefile.extrawarn-move-wunaligned-access-to-w-1.patch new file mode 100644 index 00000000000..e4702b0f317 --- /dev/null +++ b/queue-5.16/makefile.extrawarn-move-wunaligned-access-to-w-1.patch @@ -0,0 +1,43 @@ +From 1cf5f151d25fcca94689efd91afa0253621fb33a Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +Date: Wed, 2 Feb 2022 16:05:16 -0700 +Subject: Makefile.extrawarn: Move -Wunaligned-access to W=1 + +From: Nathan Chancellor + +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 +Reviewed-by: Nick Desaulniers +Signed-off-by: Masahiro Yamada +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-5.16/sched-fair-fix-fault-in-reweight_entity.patch b/queue-5.16/sched-fair-fix-fault-in-reweight_entity.patch new file mode 100644 index 00000000000..f3f2a0240ba --- /dev/null +++ b/queue-5.16/sched-fair-fix-fault-in-reweight_entity.patch @@ -0,0 +1,100 @@ +From 13765de8148f71fa795e0a6607de37c49ea5915a Mon Sep 17 00:00:00 2001 +From: Tadeusz Struk +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 + +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 +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Dietmar Eggemann +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20220203161846.1160750-1-tadeusz.struk@linaro.org +Signed-off-by: Greg Kroah-Hartman +--- + 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: diff --git a/queue-5.16/scsi-lpfc-reduce-log-messages-seen-after-firmware-download.patch b/queue-5.16/scsi-lpfc-reduce-log-messages-seen-after-firmware-download.patch new file mode 100644 index 00000000000..a72dbe615f5 --- /dev/null +++ b/queue-5.16/scsi-lpfc-reduce-log-messages-seen-after-firmware-download.patch @@ -0,0 +1,62 @@ +From 5852ed2a6a39c862c8a3fdf646e1f4e01b91d710 Mon Sep 17 00:00:00 2001 +From: James Smart +Date: Mon, 7 Feb 2022 10:04:42 -0800 +Subject: scsi: lpfc: Reduce log messages seen after firmware download + +From: James Smart + +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 +Signed-off-by: James Smart +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + 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, " diff --git a/queue-5.16/scsi-lpfc-remove-nvme-support-if-kernel-has-nvme_fc-disabled.patch b/queue-5.16/scsi-lpfc-remove-nvme-support-if-kernel-has-nvme_fc-disabled.patch new file mode 100644 index 00000000000..839587ee533 --- /dev/null +++ b/queue-5.16/scsi-lpfc-remove-nvme-support-if-kernel-has-nvme_fc-disabled.patch @@ -0,0 +1,68 @@ +From c80b27cfd93ba9f5161383f798414609e84729f3 Mon Sep 17 00:00:00 2001 +From: James Smart +Date: Mon, 7 Feb 2022 10:05:16 -0800 +Subject: scsi: lpfc: Remove NVMe support if kernel has NVME_FC disabled + +From: James Smart + +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 +Signed-off-by: James Smart +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + 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"); + + /* diff --git a/queue-5.16/series b/queue-5.16/series index 006a43e0404..ce888cff68d 100644 --- a/queue-5.16/series +++ b/queue-5.16/series @@ -190,3 +190,8 @@ signal-handler_exit-should-clear-signal_unkillable.patch 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 diff --git a/queue-5.16/x86-sgx-silence-softlockup-detection-when-releasing-large-enclaves.patch b/queue-5.16/x86-sgx-silence-softlockup-detection-when-releasing-large-enclaves.patch new file mode 100644 index 00000000000..09acc326e08 --- /dev/null +++ b/queue-5.16/x86-sgx-silence-softlockup-detection-when-releasing-large-enclaves.patch @@ -0,0 +1,48 @@ +From 8795359e35bc33bf86b6d0765aa7f37431db3b9c Mon Sep 17 00:00:00 2001 +From: Reinette Chatre +Date: Tue, 8 Feb 2022 10:48:07 -0800 +Subject: x86/sgx: Silence softlockup detection when releasing large enclaves + +From: Reinette Chatre + +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 +Signed-off-by: Reinette Chatre +Signed-off-by: Dave Hansen +Reviewed-by: Jarkko Sakkinen +Acked-by: Dave Hansen +Tested-by: Jarkko Sakkinen (kselftest as sanity check) +Link: https://lkml.kernel.org/r/ced01cac1e75f900251b0a4ae1150aa8ebd295ec.1644345232.git.reinette.chatre@intel.com +Signed-off-by: Greg Kroah-Hartman +--- + 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); -- 2.47.3