--- /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
+@@ -286,7 +286,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 | 78 ++------------------------
+ Documentation/process/stable-kernel-rules.rst | 6 --
+ Documentation/process/submitting-patches.rst | 5 -
+ 3 files changed, 7 insertions(+), 82 deletions(-)
+
+--- a/Documentation/networking/netdev-FAQ.rst
++++ b/Documentation/networking/netdev-FAQ.rst
+@@ -144,77 +144,13 @@ Please send incremental versions on top
+ the patches the way they would look like if your latest patch series was to be
+ merged.
+
+-Q: How can I tell what patches are queued up for backporting to the various stable releases?
+---------------------------------------------------------------------------------------------
+-A: 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$
+-
+-Q: I see a network patch and I think it should be backported to stable.
+------------------------------------------------------------------------
+-Q: Should I request it via stable@vger.kernel.org like the references in
+-the kernel's Documentation/process/stable-kernel-rules.rst file say?
+-A: 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.
+-
+-Q: I have created a network patch and I think it should be backported to stable.
+---------------------------------------------------------------------------------
+-Q: Should I add a Cc: stable@vger.kernel.org like the references in the
+-kernel's Documentation/ directory say?
+-A: 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.
+-
+-Q: Are all networking bug fixes backported to all stable releases?
+-------------------------------------------------------------------
+-A: 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.
++Q: Are there special rules regarding stable submissions on netdev?
++---------------------------------------------------------------
++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!
+
+ Q: 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 ee2e3f50629f17b0752b55b2566c15ce8dafb557 Mon Sep 17 00:00:00 2001
+From: Christian Brauner <christian.brauner@ubuntu.com>
+Date: Sat, 6 Mar 2021 11:10:10 +0100
+Subject: mount: fix mounting of detached mounts onto targets that reside on shared mounts
+
+From: Christian Brauner <christian.brauner@ubuntu.com>
+
+commit ee2e3f50629f17b0752b55b2566c15ce8dafb557 upstream.
+
+Creating a series of detached mounts, attaching them to the filesystem,
+and unmounting them can be used to trigger an integer overflow in
+ns->mounts causing the kernel to block any new mounts in count_mounts()
+and returning ENOSPC because it falsely assumes that the maximum number
+of mounts in the mount namespace has been reached, i.e. it thinks it
+can't fit the new mounts into the mount namespace anymore.
+
+Depending on the number of mounts in your system, this can be reproduced
+on any kernel that supportes open_tree() and move_mount() by compiling
+and running the following program:
+
+ /* SPDX-License-Identifier: LGPL-2.1+ */
+
+ #define _GNU_SOURCE
+ #include <errno.h>
+ #include <fcntl.h>
+ #include <getopt.h>
+ #include <limits.h>
+ #include <stdbool.h>
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <string.h>
+ #include <sys/mount.h>
+ #include <sys/stat.h>
+ #include <sys/syscall.h>
+ #include <sys/types.h>
+ #include <unistd.h>
+
+ /* open_tree() */
+ #ifndef OPEN_TREE_CLONE
+ #define OPEN_TREE_CLONE 1
+ #endif
+
+ #ifndef OPEN_TREE_CLOEXEC
+ #define OPEN_TREE_CLOEXEC O_CLOEXEC
+ #endif
+
+ #ifndef __NR_open_tree
+ #if defined __alpha__
+ #define __NR_open_tree 538
+ #elif defined _MIPS_SIM
+ #if _MIPS_SIM == _MIPS_SIM_ABI32 /* o32 */
+ #define __NR_open_tree 4428
+ #endif
+ #if _MIPS_SIM == _MIPS_SIM_NABI32 /* n32 */
+ #define __NR_open_tree 6428
+ #endif
+ #if _MIPS_SIM == _MIPS_SIM_ABI64 /* n64 */
+ #define __NR_open_tree 5428
+ #endif
+ #elif defined __ia64__
+ #define __NR_open_tree (428 + 1024)
+ #else
+ #define __NR_open_tree 428
+ #endif
+ #endif
+
+ /* move_mount() */
+ #ifndef MOVE_MOUNT_F_EMPTY_PATH
+ #define MOVE_MOUNT_F_EMPTY_PATH 0x00000004 /* Empty from path permitted */
+ #endif
+
+ #ifndef __NR_move_mount
+ #if defined __alpha__
+ #define __NR_move_mount 539
+ #elif defined _MIPS_SIM
+ #if _MIPS_SIM == _MIPS_SIM_ABI32 /* o32 */
+ #define __NR_move_mount 4429
+ #endif
+ #if _MIPS_SIM == _MIPS_SIM_NABI32 /* n32 */
+ #define __NR_move_mount 6429
+ #endif
+ #if _MIPS_SIM == _MIPS_SIM_ABI64 /* n64 */
+ #define __NR_move_mount 5429
+ #endif
+ #elif defined __ia64__
+ #define __NR_move_mount (428 + 1024)
+ #else
+ #define __NR_move_mount 429
+ #endif
+ #endif
+
+ static inline int sys_open_tree(int dfd, const char *filename, unsigned int flags)
+ {
+ return syscall(__NR_open_tree, dfd, filename, flags);
+ }
+
+ static inline int sys_move_mount(int from_dfd, const char *from_pathname, int to_dfd,
+ const char *to_pathname, unsigned int flags)
+ {
+ return syscall(__NR_move_mount, from_dfd, from_pathname, to_dfd, to_pathname, flags);
+ }
+
+ static bool is_shared_mountpoint(const char *path)
+ {
+ bool shared = false;
+ FILE *f = NULL;
+ char *line = NULL;
+ int i;
+ size_t len = 0;
+
+ f = fopen("/proc/self/mountinfo", "re");
+ if (!f)
+ return 0;
+
+ while (getline(&line, &len, f) > 0) {
+ char *slider1, *slider2;
+
+ for (slider1 = line, i = 0; slider1 && i < 4; i++)
+ slider1 = strchr(slider1 + 1, ' ');
+
+ if (!slider1)
+ continue;
+
+ slider2 = strchr(slider1 + 1, ' ');
+ if (!slider2)
+ continue;
+
+ *slider2 = '\0';
+ if (strcmp(slider1 + 1, path) == 0) {
+ /* This is the path. Is it shared? */
+ slider1 = strchr(slider2 + 1, ' ');
+ if (slider1 && strstr(slider1, "shared:")) {
+ shared = true;
+ break;
+ }
+ }
+ }
+ fclose(f);
+ free(line);
+
+ return shared;
+ }
+
+ static void usage(void)
+ {
+ const char *text = "mount-new [--recursive] <base-dir>\n";
+ fprintf(stderr, "%s", text);
+ _exit(EXIT_SUCCESS);
+ }
+
+ #define exit_usage(format, ...) \
+ ({ \
+ fprintf(stderr, format "\n", ##__VA_ARGS__); \
+ usage(); \
+ })
+
+ #define exit_log(format, ...) \
+ ({ \
+ fprintf(stderr, format "\n", ##__VA_ARGS__); \
+ exit(EXIT_FAILURE); \
+ })
+
+ static const struct option longopts[] = {
+ {"help", no_argument, 0, 'a'},
+ { NULL, no_argument, 0, 0 },
+ };
+
+ int main(int argc, char *argv[])
+ {
+ int exit_code = EXIT_SUCCESS, index = 0;
+ int dfd, fd_tree, new_argc, ret;
+ char *base_dir;
+ char *const *new_argv;
+ char target[PATH_MAX];
+
+ while ((ret = getopt_long_only(argc, argv, "", longopts, &index)) != -1) {
+ switch (ret) {
+ case 'a':
+ /* fallthrough */
+ default:
+ usage();
+ }
+ }
+
+ new_argv = &argv[optind];
+ new_argc = argc - optind;
+ if (new_argc < 1)
+ exit_usage("Missing base directory\n");
+ base_dir = new_argv[0];
+
+ if (*base_dir != '/')
+ exit_log("Please specify an absolute path");
+
+ /* Ensure that target is a shared mountpoint. */
+ if (!is_shared_mountpoint(base_dir))
+ exit_log("Please ensure that \"%s\" is a shared mountpoint", base_dir);
+
+ dfd = open(base_dir, O_RDONLY | O_DIRECTORY | O_CLOEXEC);
+ if (dfd < 0)
+ exit_log("%m - Failed to open base directory \"%s\"", base_dir);
+
+ ret = mkdirat(dfd, "detached-move-mount", 0755);
+ if (ret < 0)
+ exit_log("%m - Failed to create required temporary directories");
+
+ ret = snprintf(target, sizeof(target), "%s/detached-move-mount", base_dir);
+ if (ret < 0 || (size_t)ret >= sizeof(target))
+ exit_log("%m - Failed to assemble target path");
+
+ /*
+ * Having a mount table with 10000 mounts is already quite excessive
+ * and shoult account even for weird test systems.
+ */
+ for (size_t i = 0; i < 10000; i++) {
+ fd_tree = sys_open_tree(dfd, "detached-move-mount",
+ OPEN_TREE_CLONE |
+ OPEN_TREE_CLOEXEC |
+ AT_EMPTY_PATH);
+ if (fd_tree < 0) {
+ fprintf(stderr, "%m - Failed to open %d(detached-move-mount)", dfd);
+ exit_code = EXIT_FAILURE;
+ break;
+ }
+
+ ret = sys_move_mount(fd_tree, "", dfd, "detached-move-mount", MOVE_MOUNT_F_EMPTY_PATH);
+ if (ret < 0) {
+ if (errno == ENOSPC)
+ fprintf(stderr, "%m - Buggy mount counting");
+ else
+ fprintf(stderr, "%m - Failed to attach mount to %d(detached-move-mount)", dfd);
+ exit_code = EXIT_FAILURE;
+ break;
+ }
+ close(fd_tree);
+
+ ret = umount2(target, MNT_DETACH);
+ if (ret < 0) {
+ fprintf(stderr, "%m - Failed to unmount %s", target);
+ exit_code = EXIT_FAILURE;
+ break;
+ }
+ }
+
+ (void)unlinkat(dfd, "detached-move-mount", AT_REMOVEDIR);
+ close(dfd);
+
+ exit(exit_code);
+ }
+
+and wait for the kernel to refuse any new mounts by returning ENOSPC.
+How many iterations are needed depends on the number of mounts in your
+system. Assuming you have something like 50 mounts on a standard system
+it should be almost instantaneous.
+
+The root cause of this is that detached mounts aren't handled correctly
+when source and target mount are identical and reside on a shared mount
+causing a broken mount tree where the detached source itself is
+propagated which propagation prevents for regular bind-mounts and new
+mounts. This ultimately leads to a miscalculation of the number of
+mounts in the mount namespace.
+
+Detached mounts created via
+open_tree(fd, path, OPEN_TREE_CLONE)
+are essentially like an unattached new mount, or an unattached
+bind-mount. They can then later on be attached to the filesystem via
+move_mount() which calls into attach_recursive_mount(). Part of
+attaching it to the filesystem is making sure that mounts get correctly
+propagated in case the destination mountpoint is MS_SHARED, i.e. is a
+shared mountpoint. This is done by calling into propagate_mnt() which
+walks the list of peers calling propagate_one() on each mount in this
+list making sure it receives the propagation event.
+The propagate_one() functions thereby skips both new mounts and bind
+mounts to not propagate them "into themselves". Both are identified by
+checking whether the mount is already attached to any mount namespace in
+mnt->mnt_ns. The is what the IS_MNT_NEW() helper is responsible for.
+
+However, detached mounts have an anonymous mount namespace attached to
+them stashed in mnt->mnt_ns which means that IS_MNT_NEW() doesn't
+realize they need to be skipped causing the mount to propagate "into
+itself" breaking the mount table and causing a disconnect between the
+number of mounts recorded as being beneath or reachable from the target
+mountpoint and the number of mounts actually recorded/counted in
+ns->mounts ultimately causing an overflow which in turn prevents any new
+mounts via the ENOSPC issue.
+
+So teach propagation to handle detached mounts by making it aware of
+them. I've been tracking this issue down for the last couple of days and
+then verifying that the fix is correct by
+unmounting everything in my current mount table leaving only /proc and
+/sys mounted and running the reproducer above overnight verifying the
+number of mounts counted in ns->mounts. With this fix the counts are
+correct and the ENOSPC issue can't be reproduced.
+
+This change will only have an effect on mounts created with the new
+mount API since detached mounts cannot be created with the old mount API
+so regressions are extremely unlikely.
+
+Link: https://lore.kernel.org/r/20210306101010.243666-1-christian.brauner@ubuntu.com
+Fixes: 2db154b3ea8e ("vfs: syscall: Add move_mount(2) to move mounts around")
+Cc: David Howells <dhowells@redhat.com>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: linux-fsdevel@vger.kernel.org
+Cc: <stable@vger.kernel.org>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/pnode.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/pnode.h
++++ b/fs/pnode.h
+@@ -12,7 +12,7 @@
+
+ #define IS_MNT_SHARED(m) ((m)->mnt.mnt_flags & MNT_SHARED)
+ #define IS_MNT_SLAVE(m) ((m)->mnt_master)
+-#define IS_MNT_NEW(m) (!(m)->mnt_ns)
++#define IS_MNT_NEW(m) (!(m)->mnt_ns || is_anon_ns((m)->mnt_ns))
+ #define CLEAR_MNT_SHARED(m) ((m)->mnt.mnt_flags &= ~MNT_SHARED)
+ #define IS_MNT_UNBINDABLE(m) ((m)->mnt.mnt_flags & MNT_UNBINDABLE)
+ #define IS_MNT_MARKED(m) ((m)->mnt.mnt_flags & MNT_MARKED)
--- /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
+@@ -1971,7 +1971,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) {
mt76-dma-do-not-report-truncated-frames-to-mac80211.patch
gpio-fix-gpio-device-list-corruption.patch
powerpc-603-fix-protection-of-user-pages-mapped-with-prot_none.patch
+mount-fix-mounting-of-detached-mounts-onto-targets-that-reside-on-shared-mounts.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
projects / thirdparty / kernel / stable-queue.git / commitdiff
