From: Greg Kroah-Hartman Date: Fri, 12 Mar 2021 10:16:00 +0000 (+0100) Subject: 5.11-stable patches X-Git-Tag: v4.4.262~116 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=b0a6d220195201e500f9ff0ffa87751152eea6c0;p=thirdparty%2Fkernel%2Fstable-queue.git 5.11-stable patches added patches: cifs-fix-credit-accounting-for-extra-channel.patch cifs-return-proper-error-code-in-statfs-2.patch docs-networking-drop-special-stable-handling.patch revert-mm-slub-consider-rest-of-partial-list-if-acquire_slab-fails.patch --- diff --git a/queue-5.11/cifs-fix-credit-accounting-for-extra-channel.patch b/queue-5.11/cifs-fix-credit-accounting-for-extra-channel.patch new file mode 100644 index 00000000000..5b3becd7e43 --- /dev/null +++ b/queue-5.11/cifs-fix-credit-accounting-for-extra-channel.patch @@ -0,0 +1,64 @@ +From a249cc8bc2e2fed680047d326eb9a50756724198 Mon Sep 17 00:00:00 2001 +From: Aurelien Aptel +Date: Thu, 4 Mar 2021 17:42:21 +0000 +Subject: cifs: fix credit accounting for extra channel + +From: Aurelien Aptel + +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 +CC: # v5.8+ +Reviewed-by: Shyam Prasad N +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-5.11/cifs-return-proper-error-code-in-statfs-2.patch b/queue-5.11/cifs-return-proper-error-code-in-statfs-2.patch new file mode 100644 index 00000000000..3aea9fde928 --- /dev/null +++ b/queue-5.11/cifs-return-proper-error-code-in-statfs-2.patch @@ -0,0 +1,35 @@ +From 14302ee3301b3a77b331cc14efb95bf7184c73cc Mon Sep 17 00:00:00 2001 +From: Paulo Alcantara +Date: Mon, 8 Mar 2021 12:00:49 -0300 +Subject: cifs: return proper error code in statfs(2) + +From: Paulo Alcantara + +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) +Reviewed-by: Aurelien Aptel +Reviewed-by: Ronnie Sahlberg +CC: +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.11/docs-networking-drop-special-stable-handling.patch b/queue-5.11/docs-networking-drop-special-stable-handling.patch new file mode 100644 index 00000000000..96e7517f9b6 --- /dev/null +++ b/queue-5.11/docs-networking-drop-special-stable-handling.patch @@ -0,0 +1,131 @@ +From dbbe7c962c3a8163bf724dbc3c9fdfc9b16d3117 Mon Sep 17 00:00:00 2001 +From: Jakub Kicinski +Date: Tue, 2 Mar 2021 18:46:43 -0800 +Subject: docs: networking: drop special stable handling + +From: Jakub Kicinski + +commit dbbe7c962c3a8163bf724dbc3c9fdfc9b16d3117 upstream. + +Leave it to Greg. + +Signed-off-by: Jakub Kicinski +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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 ` +-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 ` +-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 `, ++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 ` +- 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 `. +--- 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 ` + 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 diff --git a/queue-5.11/revert-mm-slub-consider-rest-of-partial-list-if-acquire_slab-fails.patch b/queue-5.11/revert-mm-slub-consider-rest-of-partial-list-if-acquire_slab-fails.patch new file mode 100644 index 00000000000..abd638b5b4c --- /dev/null +++ b/queue-5.11/revert-mm-slub-consider-rest-of-partial-list-if-acquire_slab-fails.patch @@ -0,0 +1,58 @@ +From 9b1ea29bc0d7b94d420f96a0f4121403efc3dd85 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +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 + +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 +Link: https://lore.kernel.org/lkml/20210301080404.GF12822@xsang-OptiPlex-9020/ +Cc: Jann Horn +Cc: David Rientjes +Cc: Joonsoo Kim +Acked-by: Christoph Lameter +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + 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) { diff --git a/queue-5.11/series b/queue-5.11/series index 44c61fcec86..97781ecc680 100644 --- a/queue-5.11/series +++ b/queue-5.11/series @@ -37,3 +37,7 @@ ibmvnic-remove-excessive-irqsave.patch mt76-dma-do-not-report-truncated-frames-to-mac80211.patch gpio-fix-gpio-device-list-corruption.patch mount-fix-mounting-of-detached-mounts-onto-targets-that-reside-on-shared-mounts.patch +cifs-fix-credit-accounting-for-extra-channel.patch +cifs-return-proper-error-code-in-statfs-2.patch +revert-mm-slub-consider-rest-of-partial-list-if-acquire_slab-fails.patch +docs-networking-drop-special-stable-handling.patch