--- /dev/null
+From 9ffad9263b467efd8f8dc7ae1941a0a655a2bab2 Mon Sep 17 00:00:00 2001
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Date: Sun, 28 Jun 2020 21:06:38 -0400
+Subject: cifs: Fix the target file was deleted when rename failed.
+
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+
+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 <hulkci@huawei.com>
+Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From 005c34ae4b44f085120d7f371121ec7ded677761 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Sun, 21 Jun 2020 14:43:15 +0100
+Subject: irqchip/gic: Atomically update affinity
+
+From: Marc Zyngier <maz@kernel.org>
+
+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 <maz@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From fcec538ef8cca0ad0b84432235dccd9059c8e6f8 Mon Sep 17 00:00:00 2001
+From: Hauke Mehrtens <hauke@hauke-m.de>
+Date: Fri, 3 Jul 2020 00:53:34 +0200
+Subject: MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPen
+
+From: Hauke Mehrtens <hauke@hauke-m.de>
+
+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 <hauke@hauke-m.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
--- /dev/null
+From ad35f169db6cd5a4c5c0a5a42fb0cad3efeccb83 Mon Sep 17 00:00:00 2001
+From: Paul Aurich <paul@darkrain42.org>
+Date: Fri, 26 Jun 2020 12:58:07 -0700
+Subject: SMB3: Honor lease disabling for multiuser mounts
+
+From: Paul Aurich <paul@darkrain42.org>
+
+commit ad35f169db6cd5a4c5c0a5a42fb0cad3efeccb83 upstream.
+
+Fixes: 3e7a02d47872 ("smb3: allow disabling requesting leases")
+Signed-off-by: Paul Aurich <paul@darkrain42.org>
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 00dfbc2f9c61185a2e662f27c45a0bb29b2a134f Mon Sep 17 00:00:00 2001
+From: Paul Aurich <paul@darkrain42.org>
+Date: Fri, 26 Jun 2020 12:58:06 -0700
+Subject: SMB3: Honor persistent/resilient handle flags for multiuser mounts
+
+From: Paul Aurich <paul@darkrain42.org>
+
+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 <paul@darkrain42.org>
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From cc15461c73d7d044d56c47e869a215e49bd429c8 Mon Sep 17 00:00:00 2001
+From: Paul Aurich <paul@darkrain42.org>
+Date: Fri, 26 Jun 2020 12:58:05 -0700
+Subject: SMB3: Honor 'seal' flag for multiuser mounts
+
+From: Paul Aurich <paul@darkrain42.org>
+
+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 <paul@darkrain42.org>
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) {
projects / thirdparty / kernel / stable-queue.git / commitdiff
