From 1c4c96aaab90402f6acb709895d89a2acaf82340 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 7 Jul 2020 15:47:16 +0200 Subject: [PATCH] 4.19-stable patches added patches: cifs-fix-the-target-file-was-deleted-when-rename-failed.patch irqchip-gic-atomically-update-affinity.patch mips-add-missing-ehb-in-mtc0-mfc0-sequence-for-dspen.patch smb3-honor-lease-disabling-for-multiuser-mounts.patch smb3-honor-persistent-resilient-handle-flags-for-multiuser-mounts.patch smb3-honor-seal-flag-for-multiuser-mounts.patch --- ...-file-was-deleted-when-rename-failed.patch | 56 +++++++++++++++ ...qchip-gic-atomically-update-affinity.patch | 61 +++++++++++++++++ ...-ehb-in-mtc0-mfc0-sequence-for-dspen.patch | 68 +++++++++++++++++++ queue-4.19/series | 6 ++ ...lease-disabling-for-multiuser-mounts.patch | 30 ++++++++ ...nt-handle-flags-for-multiuser-mounts.patch | 36 ++++++++++ ...honor-seal-flag-for-multiuser-mounts.patch | 35 ++++++++++ 7 files changed, 292 insertions(+) create mode 100644 queue-4.19/cifs-fix-the-target-file-was-deleted-when-rename-failed.patch create mode 100644 queue-4.19/irqchip-gic-atomically-update-affinity.patch create mode 100644 queue-4.19/mips-add-missing-ehb-in-mtc0-mfc0-sequence-for-dspen.patch create mode 100644 queue-4.19/smb3-honor-lease-disabling-for-multiuser-mounts.patch create mode 100644 queue-4.19/smb3-honor-persistent-resilient-handle-flags-for-multiuser-mounts.patch create mode 100644 queue-4.19/smb3-honor-seal-flag-for-multiuser-mounts.patch diff --git a/queue-4.19/cifs-fix-the-target-file-was-deleted-when-rename-failed.patch b/queue-4.19/cifs-fix-the-target-file-was-deleted-when-rename-failed.patch new file mode 100644 index 00000000000..da1a0aabe70 --- /dev/null +++ b/queue-4.19/cifs-fix-the-target-file-was-deleted-when-rename-failed.patch @@ -0,0 +1,56 @@ +From 9ffad9263b467efd8f8dc7ae1941a0a655a2bab2 Mon Sep 17 00:00:00 2001 +From: Zhang Xiaoxu +Date: Sun, 28 Jun 2020 21:06:38 -0400 +Subject: cifs: Fix the target file was deleted when rename failed. + +From: Zhang Xiaoxu + +commit 9ffad9263b467efd8f8dc7ae1941a0a655a2bab2 upstream. + +When xfstest generic/035, we found the target file was deleted +if the rename return -EACESS. + +In cifs_rename2, we unlink the positive target dentry if rename +failed with EACESS or EEXIST, even if the target dentry is positived +before rename. Then the existing file was deleted. + +We should just delete the target file which created during the +rename. + +Reported-by: Hulk Robot +Signed-off-by: Zhang Xiaoxu +Cc: stable@vger.kernel.org +Signed-off-by: Steve French +Reviewed-by: Aurelien Aptel +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/inode.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +--- a/fs/cifs/inode.c ++++ b/fs/cifs/inode.c +@@ -1783,6 +1783,7 @@ cifs_rename2(struct inode *source_dir, s + FILE_UNIX_BASIC_INFO *info_buf_target; + unsigned int xid; + int rc, tmprc; ++ bool new_target = d_really_is_negative(target_dentry); + + if (flags & ~RENAME_NOREPLACE) + return -EINVAL; +@@ -1859,8 +1860,13 @@ cifs_rename2(struct inode *source_dir, s + */ + + unlink_target: +- /* Try unlinking the target dentry if it's not negative */ +- if (d_really_is_positive(target_dentry) && (rc == -EACCES || rc == -EEXIST)) { ++ /* ++ * If the target dentry was created during the rename, try ++ * unlinking it if it's not negative ++ */ ++ if (new_target && ++ d_really_is_positive(target_dentry) && ++ (rc == -EACCES || rc == -EEXIST)) { + if (d_is_dir(target_dentry)) + tmprc = cifs_rmdir(target_dir, target_dentry); + else diff --git a/queue-4.19/irqchip-gic-atomically-update-affinity.patch b/queue-4.19/irqchip-gic-atomically-update-affinity.patch new file mode 100644 index 00000000000..6e8dd9b6c14 --- /dev/null +++ b/queue-4.19/irqchip-gic-atomically-update-affinity.patch @@ -0,0 +1,61 @@ +From 005c34ae4b44f085120d7f371121ec7ded677761 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Sun, 21 Jun 2020 14:43:15 +0100 +Subject: irqchip/gic: Atomically update affinity + +From: Marc Zyngier + +commit 005c34ae4b44f085120d7f371121ec7ded677761 upstream. + +The GIC driver uses a RMW sequence to update the affinity, and +relies on the gic_lock_irqsave/gic_unlock_irqrestore sequences +to update it atomically. + +But these sequences only expand into anything meaningful if +the BL_SWITCHER option is selected, which almost never happens. + +It also turns out that using a RMW and locks is just as silly, +as the GIC distributor supports byte accesses for the GICD_TARGETRn +registers, which when used make the update atomic by definition. + +Drop the terminally broken code and replace it by a byte write. + +Fixes: 04c8b0f82c7d ("irqchip/gic: Make locking a BL_SWITCHER only feature") +Cc: stable@vger.kernel.org +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/irqchip/irq-gic.c | 14 +++----------- + 1 file changed, 3 insertions(+), 11 deletions(-) + +--- a/drivers/irqchip/irq-gic.c ++++ b/drivers/irqchip/irq-gic.c +@@ -324,10 +324,8 @@ static int gic_irq_set_vcpu_affinity(str + static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val, + bool force) + { +- void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + (gic_irq(d) & ~3); +- unsigned int cpu, shift = (gic_irq(d) % 4) * 8; +- u32 val, mask, bit; +- unsigned long flags; ++ void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + gic_irq(d); ++ unsigned int cpu; + + if (!force) + cpu = cpumask_any_and(mask_val, cpu_online_mask); +@@ -337,13 +335,7 @@ static int gic_set_affinity(struct irq_d + if (cpu >= NR_GIC_CPU_IF || cpu >= nr_cpu_ids) + return -EINVAL; + +- gic_lock_irqsave(flags); +- mask = 0xff << shift; +- bit = gic_cpu_map[cpu] << shift; +- val = readl_relaxed(reg) & ~mask; +- writel_relaxed(val | bit, reg); +- gic_unlock_irqrestore(flags); +- ++ writeb_relaxed(gic_cpu_map[cpu], reg); + irq_data_update_effective_affinity(d, cpumask_of(cpu)); + + return IRQ_SET_MASK_OK_DONE; diff --git a/queue-4.19/mips-add-missing-ehb-in-mtc0-mfc0-sequence-for-dspen.patch b/queue-4.19/mips-add-missing-ehb-in-mtc0-mfc0-sequence-for-dspen.patch new file mode 100644 index 00000000000..7463c11e406 --- /dev/null +++ b/queue-4.19/mips-add-missing-ehb-in-mtc0-mfc0-sequence-for-dspen.patch @@ -0,0 +1,68 @@ +From fcec538ef8cca0ad0b84432235dccd9059c8e6f8 Mon Sep 17 00:00:00 2001 +From: Hauke Mehrtens +Date: Fri, 3 Jul 2020 00:53:34 +0200 +Subject: MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPen + +From: Hauke Mehrtens + +commit fcec538ef8cca0ad0b84432235dccd9059c8e6f8 upstream. + +This resolves the hazard between the mtc0 in the change_c0_status() and +the mfc0 in configure_exception_vector(). Without resolving this hazard +configure_exception_vector() could read an old value and would restore +this old value again. This would revert the changes change_c0_status() +did. I checked this by printing out the read_c0_status() at the end of +per_cpu_trap_init() and the ST0_MX is not set without this patch. + +The hazard is documented in the MIPS Architecture Reference Manual Vol. +III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev +6.03 table 8.1 which includes: + + Producer | Consumer | Hazard + ----------|----------|---------------------------- + mtc0 | mfc0 | any coprocessor 0 register + +I saw this hazard on an Atheros AR9344 rev 2 SoC with a MIPS 74Kc CPU. +There the change_c0_status() function would activate the DSPen by +setting ST0_MX in the c0_status register. This was reverted and then the +system got a DSP exception when the DSP registers were saved in +save_dsp() in the first process switch. The crash looks like this: + +[ 0.089999] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) +[ 0.097796] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) +[ 0.107070] Kernel panic - not syncing: Unexpected DSP exception +[ 0.113470] Rebooting in 1 seconds.. + +We saw this problem in OpenWrt only on the MIPS 74Kc based Atheros SoCs, +not on the 24Kc based SoCs. We only saw it with kernel 5.4 not with +kernel 4.19, in addition we had to use GCC 8.4 or 9.X, with GCC 8.3 it +did not happen. + +In the kernel I bisected this problem to commit 9012d011660e ("compiler: +allow all arches to enable CONFIG_OPTIMIZE_INLINING"), but when this was +reverted it also happened after commit 172dcd935c34b ("MIPS: Always +allocate exception vector for MIPSr2+"). + +Commit 0b24cae4d535 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.") +does similar changes to a different file. I am not sure if there are +more places affected by this problem. + +Signed-off-by: Hauke Mehrtens +Cc: +Signed-off-by: Thomas Bogendoerfer +Signed-off-by: Greg Kroah-Hartman + +--- + arch/mips/kernel/traps.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/mips/kernel/traps.c ++++ b/arch/mips/kernel/traps.c +@@ -2096,6 +2096,7 @@ static void configure_status(void) + + change_c0_status(ST0_CU|ST0_MX|ST0_RE|ST0_FR|ST0_BEV|ST0_TS|ST0_KX|ST0_SX|ST0_UX, + status_set); ++ back_to_back_c0_hazard(); + } + + unsigned int hwrena; diff --git a/queue-4.19/series b/queue-4.19/series index 4b2f7dc0c30..f768d81c5d3 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -26,3 +26,9 @@ i2c-algo-pca-add-0x78-as-scl-stuck-low-status-for-pc.patch i2c-mlxcpld-check-correct-size-of-maximum-recv_len-p.patch nfsd-apply-umask-on-fs-without-acl-support.patch revert-alsa-usb-audio-improve-frames-size-computation.patch +smb3-honor-seal-flag-for-multiuser-mounts.patch +smb3-honor-persistent-resilient-handle-flags-for-multiuser-mounts.patch +smb3-honor-lease-disabling-for-multiuser-mounts.patch +cifs-fix-the-target-file-was-deleted-when-rename-failed.patch +mips-add-missing-ehb-in-mtc0-mfc0-sequence-for-dspen.patch +irqchip-gic-atomically-update-affinity.patch diff --git a/queue-4.19/smb3-honor-lease-disabling-for-multiuser-mounts.patch b/queue-4.19/smb3-honor-lease-disabling-for-multiuser-mounts.patch new file mode 100644 index 00000000000..fedbbe69748 --- /dev/null +++ b/queue-4.19/smb3-honor-lease-disabling-for-multiuser-mounts.patch @@ -0,0 +1,30 @@ +From ad35f169db6cd5a4c5c0a5a42fb0cad3efeccb83 Mon Sep 17 00:00:00 2001 +From: Paul Aurich +Date: Fri, 26 Jun 2020 12:58:07 -0700 +Subject: SMB3: Honor lease disabling for multiuser mounts + +From: Paul Aurich + +commit ad35f169db6cd5a4c5c0a5a42fb0cad3efeccb83 upstream. + +Fixes: 3e7a02d47872 ("smb3: allow disabling requesting leases") +Signed-off-by: Paul Aurich +CC: Stable +Signed-off-by: Steve French +Reviewed-by: Aurelien Aptel +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/connect.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/cifs/connect.c ++++ b/fs/cifs/connect.c +@@ -4601,6 +4601,7 @@ cifs_construct_tcon(struct cifs_sb_info + vol_info->nocase = master_tcon->nocase; + vol_info->nohandlecache = master_tcon->nohandlecache; + vol_info->local_lease = master_tcon->local_lease; ++ vol_info->no_lease = master_tcon->no_lease; + vol_info->resilient = master_tcon->use_resilient; + vol_info->persistent = master_tcon->use_persistent; + vol_info->no_linux_ext = !master_tcon->unix_ext; diff --git a/queue-4.19/smb3-honor-persistent-resilient-handle-flags-for-multiuser-mounts.patch b/queue-4.19/smb3-honor-persistent-resilient-handle-flags-for-multiuser-mounts.patch new file mode 100644 index 00000000000..990e3831516 --- /dev/null +++ b/queue-4.19/smb3-honor-persistent-resilient-handle-flags-for-multiuser-mounts.patch @@ -0,0 +1,36 @@ +From 00dfbc2f9c61185a2e662f27c45a0bb29b2a134f Mon Sep 17 00:00:00 2001 +From: Paul Aurich +Date: Fri, 26 Jun 2020 12:58:06 -0700 +Subject: SMB3: Honor persistent/resilient handle flags for multiuser mounts + +From: Paul Aurich + +commit 00dfbc2f9c61185a2e662f27c45a0bb29b2a134f upstream. + +Without this: + +- persistent handles will only be enabled for per-user tcons if the + server advertises the 'Continuous Availabity' capability +- resilient handles would never be enabled for per-user tcons + +Signed-off-by: Paul Aurich +CC: Stable +Signed-off-by: Steve French +Reviewed-by: Aurelien Aptel +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/connect.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/cifs/connect.c ++++ b/fs/cifs/connect.c +@@ -4601,6 +4601,8 @@ cifs_construct_tcon(struct cifs_sb_info + vol_info->nocase = master_tcon->nocase; + vol_info->nohandlecache = master_tcon->nohandlecache; + vol_info->local_lease = master_tcon->local_lease; ++ vol_info->resilient = master_tcon->use_resilient; ++ vol_info->persistent = master_tcon->use_persistent; + vol_info->no_linux_ext = !master_tcon->unix_ext; + vol_info->linux_ext = master_tcon->posix_extensions; + vol_info->sectype = master_tcon->ses->sectype; diff --git a/queue-4.19/smb3-honor-seal-flag-for-multiuser-mounts.patch b/queue-4.19/smb3-honor-seal-flag-for-multiuser-mounts.patch new file mode 100644 index 00000000000..290f3af9ee0 --- /dev/null +++ b/queue-4.19/smb3-honor-seal-flag-for-multiuser-mounts.patch @@ -0,0 +1,35 @@ +From cc15461c73d7d044d56c47e869a215e49bd429c8 Mon Sep 17 00:00:00 2001 +From: Paul Aurich +Date: Fri, 26 Jun 2020 12:58:05 -0700 +Subject: SMB3: Honor 'seal' flag for multiuser mounts + +From: Paul Aurich + +commit cc15461c73d7d044d56c47e869a215e49bd429c8 upstream. + +Ensure multiuser SMB3 mounts use encryption for all users' tcons if the +mount options are configured to require encryption. Without this, only +the primary tcon and IPC tcons are guaranteed to be encrypted. Per-user +tcons would only be encrypted if the server was configured to require +encryption. + +Signed-off-by: Paul Aurich +CC: Stable +Signed-off-by: Steve French +Reviewed-by: Aurelien Aptel +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/connect.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/cifs/connect.c ++++ b/fs/cifs/connect.c +@@ -4605,6 +4605,7 @@ cifs_construct_tcon(struct cifs_sb_info + vol_info->linux_ext = master_tcon->posix_extensions; + vol_info->sectype = master_tcon->ses->sectype; + vol_info->sign = master_tcon->ses->sign; ++ vol_info->seal = master_tcon->seal; + + rc = cifs_set_vol_auth(vol_info, master_tcon->ses); + if (rc) { -- 2.47.3