--- /dev/null
+From 14302ee3301b3a77b331cc14efb95bf7184c73cc Mon Sep 17 00:00:00 2001
+From: Paulo Alcantara <pc@cjr.nz>
+Date: Mon, 8 Mar 2021 12:00:49 -0300
+Subject: cifs: return proper error code in statfs(2)
+
+From: Paulo Alcantara <pc@cjr.nz>
+
+commit 14302ee3301b3a77b331cc14efb95bf7184c73cc upstream.
+
+In cifs_statfs(), if server->ops->queryfs is not NULL, then we should
+use its return value rather than always returning 0. Instead, use rc
+variable as it is properly set to 0 in case there is no
+server->ops->queryfs.
+
+Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
+CC: <stable@vger.kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/cifsfs.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/cifs/cifsfs.c
++++ b/fs/cifs/cifsfs.c
+@@ -208,7 +208,7 @@ cifs_statfs(struct dentry *dentry, struc
+ rc = server->ops->queryfs(xid, tcon, buf);
+
+ free_xid(xid);
+- return 0;
++ return rc;
+ }
+
+ static long cifs_fallocate(struct file *file, int mode, loff_t off, loff_t len)
--- /dev/null
+From 9b1ea29bc0d7b94d420f96a0f4121403efc3dd85 Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Wed, 10 Mar 2021 10:18:04 -0800
+Subject: Revert "mm, slub: consider rest of partial list if acquire_slab() fails"
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit 9b1ea29bc0d7b94d420f96a0f4121403efc3dd85 upstream.
+
+This reverts commit 8ff60eb052eeba95cfb3efe16b08c9199f8121cf.
+
+The kernel test robot reports a huge performance regression due to the
+commit, and the reason seems fairly straightforward: when there is
+contention on the page list (which is what causes acquire_slab() to
+fail), we do _not_ want to just loop and try again, because that will
+transfer the contention to the 'n->list_lock' spinlock we hold, and
+just make things even worse.
+
+This is admittedly likely a problem only on big machines - the kernel
+test robot report comes from a 96-thread dual socket Intel Xeon Gold
+6252 setup, but the regression there really is quite noticeable:
+
+ -47.9% regression of stress-ng.rawpkt.ops_per_sec
+
+and the commit that was marked as being fixed (7ced37197196: "slub:
+Acquire_slab() avoid loop") actually did the loop exit early very
+intentionally (the hint being that "avoid loop" part of that commit
+message), exactly to avoid this issue.
+
+The correct thing to do may be to pick some kind of reasonable middle
+ground: instead of breaking out of the loop on the very first sign of
+contention, or trying over and over and over again, the right thing may
+be to re-try _once_, and then give up on the second failure (or pick
+your favorite value for "once"..).
+
+Reported-by: kernel test robot <oliver.sang@intel.com>
+Link: https://lore.kernel.org/lkml/20210301080404.GF12822@xsang-OptiPlex-9020/
+Cc: Jann Horn <jannh@google.com>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Acked-by: Christoph Lameter <cl@linux.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/slub.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/slub.c
++++ b/mm/slub.c
+@@ -1833,7 +1833,7 @@ static void *get_partial_node(struct kme
+
+ t = acquire_slab(s, n, page, object == NULL, &objects);
+ if (!t)
+- continue; /* cmpxchg raced */
++ break;
+
+ available += objects;
+ if (!object) {