--- /dev/null
+From a249cc8bc2e2fed680047d326eb9a50756724198 Mon Sep 17 00:00:00 2001
+From: Aurelien Aptel <aaptel@suse.com>
+Date: Thu, 4 Mar 2021 17:42:21 +0000
+Subject: cifs: fix credit accounting for extra channel
+
+From: Aurelien Aptel <aaptel@suse.com>
+
+commit a249cc8bc2e2fed680047d326eb9a50756724198 upstream.
+
+With multichannel, operations like the queries
+from "ls -lR" can cause all credits to be used and
+errors to be returned since max_credits was not
+being set correctly on the secondary channels and
+thus the client was requesting 0 credits incorrectly
+in some cases (which can lead to not having
+enough credits to perform any operation on that
+channel).
+
+Signed-off-by: Aurelien Aptel <aaptel@suse.com>
+CC: <stable@vger.kernel.org> # v5.8+
+Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/connect.c | 10 +++++-----
+ fs/cifs/sess.c | 1 +
+ 2 files changed, 6 insertions(+), 5 deletions(-)
+
+--- a/fs/cifs/connect.c
++++ b/fs/cifs/connect.c
+@@ -1405,6 +1405,11 @@ smbd_connected:
+ tcp_ses->min_offload = ctx->min_offload;
+ tcp_ses->tcpStatus = CifsNeedNegotiate;
+
++ if ((ctx->max_credits < 20) || (ctx->max_credits > 60000))
++ tcp_ses->max_credits = SMB2_MAX_CREDITS_AVAILABLE;
++ else
++ tcp_ses->max_credits = ctx->max_credits;
++
+ tcp_ses->nr_targets = 1;
+ tcp_ses->ignore_signature = ctx->ignore_signature;
+ /* thread spawned, put it on the list */
+@@ -2806,11 +2811,6 @@ static int mount_get_conns(struct smb3_f
+
+ *nserver = server;
+
+- if ((ctx->max_credits < 20) || (ctx->max_credits > 60000))
+- server->max_credits = SMB2_MAX_CREDITS_AVAILABLE;
+- else
+- server->max_credits = ctx->max_credits;
+-
+ /* get a reference to a SMB session */
+ ses = cifs_get_smb_ses(server, ctx);
+ if (IS_ERR(ses)) {
+--- a/fs/cifs/sess.c
++++ b/fs/cifs/sess.c
+@@ -230,6 +230,7 @@ cifs_ses_add_channel(struct cifs_sb_info
+ ctx.noautotune = ses->server->noautotune;
+ ctx.sockopt_tcp_nodelay = ses->server->tcp_nodelay;
+ ctx.echo_interval = ses->server->echo_interval / HZ;
++ ctx.max_credits = ses->server->max_credits;
+
+ /*
+ * This will be used for encoding/decoding user/domain/pw
--- /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
+@@ -290,7 +290,7 @@ cifs_statfs(struct dentry *dentry, struc
+ rc = server->ops->queryfs(xid, tcon, cifs_sb, 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 dbbe7c962c3a8163bf724dbc3c9fdfc9b16d3117 Mon Sep 17 00:00:00 2001
+From: Jakub Kicinski <kuba@kernel.org>
+Date: Tue, 2 Mar 2021 18:46:43 -0800
+Subject: docs: networking: drop special stable handling
+
+From: Jakub Kicinski <kuba@kernel.org>
+
+commit dbbe7c962c3a8163bf724dbc3c9fdfc9b16d3117 upstream.
+
+Leave it to Greg.
+
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/networking/netdev-FAQ.rst | 72 ++------------------------
+ Documentation/process/stable-kernel-rules.rst | 6 --
+ Documentation/process/submitting-patches.rst | 5 -
+ 3 files changed, 6 insertions(+), 77 deletions(-)
+
+--- a/Documentation/networking/netdev-FAQ.rst
++++ b/Documentation/networking/netdev-FAQ.rst
+@@ -142,73 +142,13 @@ Please send incremental versions on top
+ the patches the way they would look like if your latest patch series was to be
+ merged.
+
+-How can I tell what patches are queued up for backporting to the various stable releases?
+------------------------------------------------------------------------------------------
+-Normally Greg Kroah-Hartman collects stable commits himself, but for
+-networking, Dave collects up patches he deems critical for the
+-networking subsystem, and then hands them off to Greg.
+-
+-There is a patchworks queue that you can see here:
+-
+- https://patchwork.kernel.org/bundle/netdev/stable/?state=*
+-
+-It contains the patches which Dave has selected, but not yet handed off
+-to Greg. If Greg already has the patch, then it will be here:
+-
+- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
+-
+-A quick way to find whether the patch is in this stable-queue is to
+-simply clone the repo, and then git grep the mainline commit ID, e.g.
+-::
+-
+- stable-queue$ git grep -l 284041ef21fdf2e
+- releases/3.0.84/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
+- releases/3.4.51/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
+- releases/3.9.8/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
+- stable/stable-queue$
+-
+-I see a network patch and I think it should be backported to stable. Should I request it via stable@vger.kernel.org like the references in the kernel's Documentation/process/stable-kernel-rules.rst file say?
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+-No, not for networking. Check the stable queues as per above first
+-to see if it is already queued. If not, then send a mail to netdev,
+-listing the upstream commit ID and why you think it should be a stable
+-candidate.
+-
+-Before you jump to go do the above, do note that the normal stable rules
+-in :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+-still apply. So you need to explicitly indicate why it is a critical
+-fix and exactly what users are impacted. In addition, you need to
+-convince yourself that you *really* think it has been overlooked,
+-vs. having been considered and rejected.
+-
+-Generally speaking, the longer it has had a chance to "soak" in
+-mainline, the better the odds that it is an OK candidate for stable. So
+-scrambling to request a commit be added the day after it appears should
+-be avoided.
+-
+-I have created a network patch and I think it should be backported to stable. Should I add a Cc: stable@vger.kernel.org like the references in the kernel's Documentation/ directory say?
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+-No. See above answer. In short, if you think it really belongs in
+-stable, then ensure you write a decent commit log that describes who
+-gets impacted by the bug fix and how it manifests itself, and when the
+-bug was introduced. If you do that properly, then the commit will get
+-handled appropriately and most likely get put in the patchworks stable
+-queue if it really warrants it.
+-
+-If you think there is some valid information relating to it being in
+-stable that does *not* belong in the commit log, then use the three dash
+-marker line as described in
+-:ref:`Documentation/process/submitting-patches.rst <the_canonical_patch_format>`
+-to temporarily embed that information into the patch that you send.
+-
+-Are all networking bug fixes backported to all stable releases?
++Are there special rules regarding stable submissions on netdev?
+ ---------------------------------------------------------------
+-Due to capacity, Dave could only take care of the backports for the
+-last two stable releases. For earlier stable releases, each stable
+-branch maintainer is supposed to take care of them. If you find any
+-patch is missing from an earlier stable branch, please notify
+-stable@vger.kernel.org with either a commit ID or a formal patch
+-backported, and CC Dave and other relevant networking developers.
++While it used to be the case that netdev submissions were not supposed
++to carry explicit ``CC: stable@vger.kernel.org`` tags that is no longer
++the case today. Please follow the standard stable rules in
++:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`,
++and make sure you include appropriate Fixes tags!
+
+ Is the comment style convention different for the networking content?
+ ---------------------------------------------------------------------
+--- a/Documentation/process/stable-kernel-rules.rst
++++ b/Documentation/process/stable-kernel-rules.rst
+@@ -35,12 +35,6 @@ Rules on what kind of patches are accept
+ Procedure for submitting patches to the -stable tree
+ ----------------------------------------------------
+
+- - If the patch covers files in net/ or drivers/net please follow netdev stable
+- submission guidelines as described in
+- :ref:`Documentation/networking/netdev-FAQ.rst <netdev-FAQ>`
+- after first checking the stable networking queue at
+- https://patchwork.kernel.org/bundle/netdev/stable/?state=*
+- to ensure the requested patch is not already queued up.
+ - Security patches should not be handled (solely) by the -stable review
+ process but should follow the procedures in
+ :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`.
+--- a/Documentation/process/submitting-patches.rst
++++ b/Documentation/process/submitting-patches.rst
+@@ -250,11 +250,6 @@ should also read
+ :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+ in addition to this file.
+
+-Note, however, that some subsystem maintainers want to come to their own
+-conclusions on which patches should go to the stable trees. The networking
+-maintainer, in particular, would rather not see individual developers
+-adding lines like the above to their patches.
+-
+ If changes affect userland-kernel interfaces, please send the MAN-PAGES
+ maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at
+ least a notification of the change, so that some information makes its way
--- /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
+@@ -1973,7 +1973,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) {
projects / thirdparty / kernel / stable-queue.git / commitdiff
