Home Home > GIT Browse > openSUSE-15.0
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTakashi Iwai <tiwai@suse.de>2018-07-17 14:14:34 +0200
committerTakashi Iwai <tiwai@suse.de>2018-07-17 14:14:34 +0200
commit951943d1a018acdb76af150dcd4c967774606e0f (patch)
tree7e2dac89f374524ab3369c518b20899f1ef9b777
parentb80b594441271458017250c21a82848abb21a5b2 (diff)
parent0b375e495c825a6a662e7592ee441ea3ddbf45c8 (diff)
Merge branch 'SLE12-SP3' into openSUSE-42.3rpm-4.4.140-62
-rw-r--r--blacklist.conf3
-rw-r--r--patches.fixes/kmod-fix-wait-on-recursive-loop.patch109
-rw-r--r--patches.fixes/kmod-reduce-atomic-operations-on-kmod_concurrent-and.patch149
-rw-r--r--patches.fixes/kmod-throttle-kmod-thread-limit.patch104
-rw-r--r--patches.fixes/wait-add-wait_event_killable_timeout.patch135
-rw-r--r--series.conf4
6 files changed, 504 insertions, 0 deletions
diff --git a/blacklist.conf b/blacklist.conf
index e76550cf0b..8be3a78b7d 100644
--- a/blacklist.conf
+++ b/blacklist.conf
@@ -403,3 +403,6 @@ fc218544fbc800d1c91348ec834cacfb257348f7 # requires major changes to libceph fro
ab1068d6866e28bf6427ceaea681a381e5870a4a # iwlwifi: not applicable
dc82e52492f684dcd5ed9e4773e72dbf2203d75e # ALSA core: breaks kABI
92397a6c38d139d50fabbe9e2dc09b61d53b2377 # the backport of c043ec1ca5ba does not need this
+44ee54aabfdb3b35866ed909bde3ab01e9679385 # da9063_wdt: not cleanly applicable
+be9e9c2ad52baea131a5395b15f52ae4f86bfbe3 # da9063_wdt: not cleanly applicable
+e46bb55dbc94b06f5ee466e2f50723b56781e661 # da9063_wdt: not cleanly applicable
diff --git a/patches.fixes/kmod-fix-wait-on-recursive-loop.patch b/patches.fixes/kmod-fix-wait-on-recursive-loop.patch
new file mode 100644
index 0000000000..e903e56bc0
--- /dev/null
+++ b/patches.fixes/kmod-fix-wait-on-recursive-loop.patch
@@ -0,0 +1,109 @@
+From 2ba293c9e7db150943f06b12d3eb7213e7fae624 Mon Sep 17 00:00:00 2001
+From: "Luis R. Rodriguez" <mcgrof@kernel.org>
+Date: Fri, 18 Aug 2017 15:15:58 -0700
+Subject: [PATCH] kmod: fix wait on recursive loop
+Git-commit: 2ba293c9e7db150943f06b12d3eb7213e7fae624
+Patch-mainline: v4.13-rc6
+References: bsc#1099792
+
+Recursive loops with module loading were previously handled in kmod by
+restricting the number of modprobe calls to 50 and if that limit was
+breached request_module() would return an error and a user would see the
+following on their kernel dmesg:
+
+ request_module: runaway loop modprobe binfmt-464c
+ Starting init:/sbin/init exists but couldn't execute it (error -8)
+
+This issue could happen for instance when a 64-bit kernel boots a 32-bit
+userspace on some architectures and has no 32-bit binary format
+hanlders. This is visible, for instance, when a CONFIG_MODULES enabled
+64-bit MIPS kernel boots a into o32 root filesystem and the binfmt
+handler for o32 binaries is not built-in.
+
+After commit 6d7964a722af ("kmod: throttle kmod thread limit") we now
+don't have any visible signs of an error and the kernel just waits for
+the loop to end somehow.
+
+Although this *particular* recursive loop could also be addressed by
+doing a sanity check on search_binary_handler() and disallowing a
+modular binfmt to be required for modprobe, a generic solution for any
+recursive kernel kmod issues is still needed.
+
+This should catch these loops. We can investigate each loop and address
+each one separately as they come in, this however puts a stop gap for
+them as before.
+
+Link: http://lkml.kernel.org/r/20170809234635.13443-3-mcgrof@kernel.org
+Fixes: 6d7964a722af ("kmod: throttle kmod thread limit")
+Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
+Reported-by: Matt Redfearn <matt.redfearn@imgtec.com>
+Tested-by: Matt Redfearn <matt.redfearn@imgetc.com>
+Cc: "Eric W. Biederman" <ebiederm@xmission.com>
+Cc: Colin Ian King <colin.king@canonical.com>
+Cc: Dan Carpenter <dan.carpenter@oracle.com>
+Cc: Daniel Mentz <danielmentz@google.com>
+Cc: David Binderman <dcb314@hotmail.com>
+Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Jessica Yu <jeyu@redhat.com>
+Cc: Josh Poimboeuf <jpoimboe@redhat.com>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Michal Marek <mmarek@suse.com>
+Cc: Miroslav Benes <mbenes@suse.cz>
+Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Petr Mladek <pmladek@suse.com>
+Cc: Rusty Russell <rusty@rustcorp.com.au>
+Cc: Shuah Khan <shuah@kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Luis R. Chamberlain <mcgrof@suse.com>
+---
+ kernel/kmod.c | 25 +++++++++++++++++++++++--
+ 1 file changed, 23 insertions(+), 2 deletions(-)
+
+diff --git a/kernel/kmod.c b/kernel/kmod.c
+index 6d016c5d97c8..2f37acde640b 100644
+--- a/kernel/kmod.c
++++ b/kernel/kmod.c
+@@ -70,6 +70,18 @@ static DECLARE_RWSEM(umhelper_sem);
+ static atomic_t kmod_concurrent_max = ATOMIC_INIT(MAX_KMOD_CONCURRENT);
+ static DECLARE_WAIT_QUEUE_HEAD(kmod_wq);
+
++/*
++ * This is a restriction on having *all* MAX_KMOD_CONCURRENT threads
++ * running at the same time without returning. When this happens we
++ * believe you've somehow ended up with a recursive module dependency
++ * creating a loop.
++ *
++ * We have no option but to fail.
++ *
++ * Userspace should proactively try to detect and prevent these.
++ */
++#define MAX_KMOD_ALL_BUSY_TIMEOUT 5
++
+ /*
+ modprobe_path is set via /proc/sys.
+ */
+@@ -167,8 +179,17 @@ int __request_module(bool wait, const char *fmt, ...)
+ pr_warn_ratelimited("request_module: kmod_concurrent_max (%u) close to 0 (max_modprobes: %u), for module %s, throttling...",
+ atomic_read(&kmod_concurrent_max),
+ MAX_KMOD_CONCURRENT, module_name);
+- wait_event_interruptible(kmod_wq,
+- atomic_dec_if_positive(&kmod_concurrent_max) >= 0);
++ ret = wait_event_killable_timeout(kmod_wq,
++ atomic_dec_if_positive(&kmod_concurrent_max) >= 0,
++ MAX_KMOD_ALL_BUSY_TIMEOUT * HZ);
++ if (!ret) {
++ pr_warn_ratelimited("request_module: modprobe %s cannot be processed, kmod busy with %d threads for more than %d seconds now",
++ module_name, MAX_KMOD_CONCURRENT, MAX_KMOD_ALL_BUSY_TIMEOUT);
++ return -ETIME;
++ } else if (ret == -ERESTARTSYS) {
++ pr_warn_ratelimited("request_module: sigkill sent for modprobe %s, giving up", module_name);
++ return ret;
++ }
+ }
+
+ trace_module_request(module_name, wait, _RET_IP_);
+--
+2.16.3
+
diff --git a/patches.fixes/kmod-reduce-atomic-operations-on-kmod_concurrent-and.patch b/patches.fixes/kmod-reduce-atomic-operations-on-kmod_concurrent-and.patch
new file mode 100644
index 0000000000..a150c8e4f5
--- /dev/null
+++ b/patches.fixes/kmod-reduce-atomic-operations-on-kmod_concurrent-and.patch
@@ -0,0 +1,149 @@
+From 165d1cc0074b2f938586274776d029b9bce914c4 Mon Sep 17 00:00:00 2001
+From: "Luis R. Rodriguez" <mcgrof@kernel.org>
+Date: Fri, 23 Jun 2017 12:19:12 -0700
+Subject: [PATCH] kmod: reduce atomic operations on kmod_concurrent and
+ simplify
+Git-commit: 165d1cc0074b2f938586274776d029b9bce914c4
+Patch-mainline: v4.13-rc1
+References: bsc#1099792
+
+When checking if we want to allow a kmod thread to kick off we increment,
+then read to see if we should enable a thread. If we were over the allowed
+limit limit we decrement. Splitting the increment far apart from decrement
+means there could be a time where two increments happen potentially
+giving a false failure on a thread which should have been allowed.
+
+CPU1 CPU2
+atomic_inc()
+ atomic_inc()
+atomic_read()
+ atomic_read()
+atomic_dec()
+ atomic_dec()
+
+In this case a read on CPU1 gets the atomic_inc()'s and we could negate
+it from getting a kmod thread. We could try to prevent this with a lock
+or preemption but that is overkill. We can fix by reducing the number of
+atomic operations. We do this by inverting the logic of of the enabler,
+instead of incrementing kmod_concurrent as we get new kmod users, define the
+variable kmod_concurrent_max as the max number of currently allowed kmod
+users and as we get new kmod users just decrement it if its still positive.
+This combines the dec and read in one atomic operation.
+
+In this case we no longer get the same false failure:
+
+CPU1 CPU2
+atomic_dec_if_positive()
+ atomic_dec_if_positive()
+atomic_inc()
+ atomic_inc()
+
+The number of threads is computed at init, and since the current computation
+of kmod_concurrent includes the thread count we can avoid setting
+kmod_concurrent_max later in boot through an init call by simply sticking to
+50 as the kmod_concurrent_max. The assumption here is a system with modules
+must at least have ~16 MiB of RAM.
+
+Suggested-by: Petr Mladek <pmladek@suse.com>
+Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
+Reviewed-by: Petr Mladek <pmladek@suse.com>
+Signed-off-by: Jessica Yu <jeyu@kernel.org>
+Signed-off-by: Luis R. Chamberlain <mcgrof@suse.com>
+---
+ kernel/kmod.c | 40 ++++++++++++++++++----------------------
+ 1 file changed, 18 insertions(+), 22 deletions(-)
+
+diff --git a/kernel/kmod.c b/kernel/kmod.c
+index 563f97e2be36..ff68198fe83b 100644
+--- a/kernel/kmod.c
++++ b/kernel/kmod.c
+@@ -45,8 +45,6 @@
+
+ #include <trace/events/module.h>
+
+-extern int max_threads;
+-
+ #define CAP_BSET (void *)1
+ #define CAP_PI (void *)2
+
+@@ -56,6 +54,20 @@ static DEFINE_SPINLOCK(umh_sysctl_lock);
+ static DECLARE_RWSEM(umhelper_sem);
+
+ #ifdef CONFIG_MODULES
++/*
++ * Assuming:
++ *
++ * threads = div64_u64((u64) totalram_pages * (u64) PAGE_SIZE,
++ * (u64) THREAD_SIZE * 8UL);
++ *
++ * If you need less than 50 threads would mean we're dealing with systems
++ * smaller than 3200 pages. This assuems you are capable of having ~13M memory,
++ * and this would only be an be an upper limit, after which the OOM killer
++ * would take effect. Systems like these are very unlikely if modules are
++ * enabled.
++ */
++#define MAX_KMOD_CONCURRENT 50
++static atomic_t kmod_concurrent_max = ATOMIC_INIT(MAX_KMOD_CONCURRENT);
+
+ /*
+ modprobe_path is set via /proc/sys.
+@@ -127,10 +139,7 @@ int __request_module(bool wait, const char *fmt, ...)
+ {
+ va_list args;
+ char module_name[MODULE_NAME_LEN];
+- unsigned int max_modprobes;
+ int ret;
+- static atomic_t kmod_concurrent = ATOMIC_INIT(0);
+-#define MAX_KMOD_CONCURRENT 50 /* Completely arbitrary value - KAO */
+ static int kmod_loop_msg;
+
+ /*
+@@ -154,21 +163,7 @@ int __request_module(bool wait, const char *fmt, ...)
+ if (ret)
+ return ret;
+
+- /* If modprobe needs a service that is in a module, we get a recursive
+- * loop. Limit the number of running kmod threads to max_threads/2 or
+- * MAX_KMOD_CONCURRENT, whichever is the smaller. A cleaner method
+- * would be to run the parents of this process, counting how many times
+- * kmod was invoked. That would mean accessing the internals of the
+- * process tables to get the command line, proc_pid_cmdline is static
+- * and it is not worth changing the proc code just to handle this case.
+- * KAO.
+- *
+- * "trace the ppid" is simple, but will fail if someone's
+- * parent exits. I think this is as good as it gets. --RR
+- */
+- max_modprobes = min(max_threads/2, MAX_KMOD_CONCURRENT);
+- atomic_inc(&kmod_concurrent);
+- if (atomic_read(&kmod_concurrent) > max_modprobes) {
++ if (atomic_dec_if_positive(&kmod_concurrent_max) < 0) {
+ /* We may be blaming an innocent here, but unlikely */
+ if (kmod_loop_msg < 5) {
+ printk(KERN_ERR
+@@ -176,7 +171,6 @@ int __request_module(bool wait, const char *fmt, ...)
+ module_name);
+ kmod_loop_msg++;
+ }
+- atomic_dec(&kmod_concurrent);
+ return -ENOMEM;
+ }
+
+@@ -184,10 +178,12 @@ int __request_module(bool wait, const char *fmt, ...)
+
+ ret = call_modprobe(module_name, wait ? UMH_WAIT_PROC : UMH_WAIT_EXEC);
+
+- atomic_dec(&kmod_concurrent);
++ atomic_inc(&kmod_concurrent_max);
++
+ return ret;
+ }
+ EXPORT_SYMBOL(__request_module);
++
+ #endif /* CONFIG_MODULES */
+
+ static void call_usermodehelper_freeinfo(struct subprocess_info *info)
+--
+2.16.3
+
diff --git a/patches.fixes/kmod-throttle-kmod-thread-limit.patch b/patches.fixes/kmod-throttle-kmod-thread-limit.patch
new file mode 100644
index 0000000000..9cff4d0555
--- /dev/null
+++ b/patches.fixes/kmod-throttle-kmod-thread-limit.patch
@@ -0,0 +1,104 @@
+From 6d7964a722afc8e4f880b947f174009063028c99 Mon Sep 17 00:00:00 2001
+From: "Luis R. Rodriguez" <mcgrof@kernel.org>
+Date: Fri, 14 Jul 2017 14:50:11 -0700
+Subject: [PATCH] kmod: throttle kmod thread limit
+Git-commit: 6d7964a722afc8e4f880b947f174009063028c99
+Patch-mainline: v4.13-rc1
+References: bsc#1099792
+
+If we reach the limit of modprobe_limit threads running the next
+request_module() call will fail. The original reason for adding a kill
+was to do away with possible issues with in old circumstances which would
+create a recursive series of request_module() calls.
+
+We can do better than just be super aggressive and reject calls once we've
+reached the limit by simply making pending callers wait until the
+threshold has been reduced, and then throttling them in, one by one.
+
+This throttling enables requests over the kmod concurrent limit to be
+processed once a pending request completes. Only the first item queued up
+to wait is woken up. The assumption here is once a task is woken it will
+have no other option to also kick the queue to check if there are more
+pending tasks -- regardless of whether or not it was successful.
+
+By throttling and processing only max kmod concurrent tasks we ensure we
+avoid unexpected fatal request_module() calls, and we keep memory
+consumption on module loading to a minimum.
+
+With x86_64 qemu, with 4 cores, 4 GiB of RAM it takes the following run
+time to run both tests:
+
+time ./kmod.sh -t 0008
+real 0m16.366s
+user 0m0.883s
+sys 0m8.916s
+
+time ./kmod.sh -t 0009
+real 0m50.803s
+user 0m0.791s
+sys 0m9.852s
+
+Link: http://lkml.kernel.org/r/20170628223155.26472-4-mcgrof@kernel.org
+Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
+Reviewed-by: Petr Mladek <pmladek@suse.com>
+Cc: Jessica Yu <jeyu@redhat.com>
+Cc: Shuah Khan <shuah@kernel.org>
+Cc: Rusty Russell <rusty@rustcorp.com.au>
+Cc: Michal Marek <mmarek@suse.com>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Luis R. Chamberlain <mcgrof@suse.com>
+---
+ kernel/kmod.c | 16 +++++++---------
+ tools/testing/selftests/kmod/kmod.sh | 24 ++----------------------
+ 2 files changed, 9 insertions(+), 31 deletions(-)
+
+diff --git a/kernel/kmod.c b/kernel/kmod.c
+index ff68198fe83b..6d016c5d97c8 100644
+--- a/kernel/kmod.c
++++ b/kernel/kmod.c
+@@ -68,6 +68,7 @@ static DECLARE_RWSEM(umhelper_sem);
+ */
+ #define MAX_KMOD_CONCURRENT 50
+ static atomic_t kmod_concurrent_max = ATOMIC_INIT(MAX_KMOD_CONCURRENT);
++static DECLARE_WAIT_QUEUE_HEAD(kmod_wq);
+
+ /*
+ modprobe_path is set via /proc/sys.
+@@ -140,7 +141,6 @@ int __request_module(bool wait, const char *fmt, ...)
+ va_list args;
+ char module_name[MODULE_NAME_LEN];
+ int ret;
+- static int kmod_loop_msg;
+
+ /*
+ * We don't allow synchronous module loading from async. Module
+@@ -164,14 +164,11 @@ int __request_module(bool wait, const char *fmt, ...)
+ return ret;
+
+ if (atomic_dec_if_positive(&kmod_concurrent_max) < 0) {
+- /* We may be blaming an innocent here, but unlikely */
+- if (kmod_loop_msg < 5) {
+- printk(KERN_ERR
+- "request_module: runaway loop modprobe %s\n",
+- module_name);
+- kmod_loop_msg++;
+- }
+- return -ENOMEM;
++ pr_warn_ratelimited("request_module: kmod_concurrent_max (%u) close to 0 (max_modprobes: %u), for module %s, throttling...",
++ atomic_read(&kmod_concurrent_max),
++ MAX_KMOD_CONCURRENT, module_name);
++ wait_event_interruptible(kmod_wq,
++ atomic_dec_if_positive(&kmod_concurrent_max) >= 0);
+ }
+
+ trace_module_request(module_name, wait, _RET_IP_);
+@@ -179,6 +176,7 @@ int __request_module(bool wait, const char *fmt, ...)
+ ret = call_modprobe(module_name, wait ? UMH_WAIT_PROC : UMH_WAIT_EXEC);
+
+ atomic_inc(&kmod_concurrent_max);
++ wake_up(&kmod_wq);
+
+ return ret;
+ }
diff --git a/patches.fixes/wait-add-wait_event_killable_timeout.patch b/patches.fixes/wait-add-wait_event_killable_timeout.patch
new file mode 100644
index 0000000000..381e2ffd5d
--- /dev/null
+++ b/patches.fixes/wait-add-wait_event_killable_timeout.patch
@@ -0,0 +1,135 @@
+From 8ada92799ec4de00f4bc0f10b1ededa256c1ab22 Mon Sep 17 00:00:00 2001
+From: "Luis R. Rodriguez" <mcgrof@kernel.org>
+Date: Fri, 18 Aug 2017 15:15:55 -0700
+Subject: [PATCH] wait: add wait_event_killable_timeout()
+Git-commit: 8ada92799ec4de00f4bc0f10b1ededa256c1ab22
+Patch-mainline: v4.13-rc6
+References: bsc#1099792
+
+These are the few pending fixes I have queued up for v4.13-final. One
+is a a generic regression fix for recursive loops on kmod and the other
+one is a trivial print out correction.
+
+During the v4.13 development we assumed that recursive kmod loops were
+no longer possible. Clearly that is not true. The regression fix makes
+use of a new killable wait. We use a killable wait to be paranoid in
+how signals might be sent to modprobe and only accept a proper SIGKILL.
+The signal will only be available to userspace to issue *iff* a thread
+has already entered a wait state, and that happens only if we've already
+throttled after 50 kmod threads have been hit.
+
+Note that although it may seem excessive to trigger a failure afer 5
+seconds if all kmod thread remain busy, prior to the series of changes
+that went into v4.13 we would actually *always* fatally fail any request
+which came in if the limit was already reached. The new waiting
+implemented in v4.13 actually gives us *more* breathing room -- the wait
+for 5 seconds is a wait for *any* kmod thread to finish. We give up and
+fail *iff* no kmod thread has finished and they're *all* running
+straight for 5 consecutive seconds. If 50 kmod threads are running
+consecutively for 5 seconds something else must be really bad.
+
+Recursive loops with kmod are bad but they're also hard to implement
+properly as a selftest without currently fooling current userspace tools
+like kmod [1]. For instance kmod will complain when you run depmod if
+it finds a recursive loop with symbol dependency between modules as such
+this type of recursive loop cannot go upstream as the modules_install
+target will fail after running depmod.
+
+These tests already exist on userspace kmod upstream though (refer to
+the testsuite/module-playground/mod-loop-*.c files). The same is not
+true if request_module() is used though, or worst if aliases are used.
+
+Likewise the issue with 64-bit kernels booting 32-bit userspace without
+a binfmt handler built-in is also currently not detected and proactively
+avoided by userspace kmod tools, or kconfig for all architectures.
+Although we could complain in the kernel when some of these individual
+recursive issues creep up, proactively avoiding these situations in
+userspace at build time is what we should keep striving for.
+
+Lastly, since recursive loops could happen with kmod it may mean
+recursive loops may also be possible with other kernel usermode helpers,
+this should be investigated and long term if we can come up with a more
+sensible generic solution even better!
+
+[0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=20170809-kmod-for-v4.13-final
+[1] https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
+
+This patch (of 3):
+
+This wait is similar to wait_event_interruptible_timeout() but only
+accepts SIGKILL interrupt signal. Other signals are ignored.
+
+Link: http://lkml.kernel.org/r/20170809234635.13443-2-mcgrof@kernel.org
+Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
+Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Cc: Jessica Yu <jeyu@redhat.com>
+Cc: Rusty Russell <rusty@rustcorp.com.au>
+Cc: Michal Marek <mmarek@suse.com>
+Cc: Petr Mladek <pmladek@suse.com>
+Cc: Miroslav Benes <mbenes@suse.cz>
+Cc: Josh Poimboeuf <jpoimboe@redhat.com>
+Cc: "Eric W. Biederman" <ebiederm@xmission.com>
+Cc: Shuah Khan <shuah@kernel.org>
+Cc: Matt Redfearn <matt.redfearn@imgtec.com>
+Cc: Dan Carpenter <dan.carpenter@oracle.com>
+Cc: Colin Ian King <colin.king@canonical.com>
+Cc: Daniel Mentz <danielmentz@google.com>
+Cc: David Binderman <dcb314@hotmail.com>
+Cc: Matt Redfearn <matt.redfearn@imgetc.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Luis R. Chamberlain <mcgrof@suse.com>
+---
+ include/linux/wait.h | 36 ++++++++++++++++++++++++++++++++++++
+ 1 file changed, 36 insertions(+)
+
+diff --git a/include/linux/wait.h b/include/linux/wait.h
+index ae71a769b89e..b560bc0d6088 100644
+--- a/include/linux/wait.h
++++ b/include/linux/wait.h
+@@ -789,6 +789,42 @@ do { \
+ __ret; \
+ })
+
++#define __wait_event_killable_timeout(wq_head, condition, timeout) \
++ ___wait_event(wq_head, ___wait_cond_timeout(condition), \
++ TASK_KILLABLE, 0, timeout, \
++ __ret = schedule_timeout(__ret))
++
++/**
++ * wait_event_killable_timeout - sleep until a condition gets true or a timeout elapses
++ * @wq_head: the waitqueue to wait on
++ * @condition: a C expression for the event to wait for
++ * @timeout: timeout, in jiffies
++ *
++ * The process is put to sleep (TASK_KILLABLE) until the
++ * @condition evaluates to true or a kill signal is received.
++ * The @condition is checked each time the waitqueue @wq_head is woken up.
++ *
++ * wake_up() has to be called after changing any variable that could
++ * change the result of the wait condition.
++ *
++ * Returns:
++ * 0 if the @condition evaluated to %false after the @timeout elapsed,
++ * 1 if the @condition evaluated to %true after the @timeout elapsed,
++ * the remaining jiffies (at least 1) if the @condition evaluated
++ * to %true before the @timeout elapsed, or -%ERESTARTSYS if it was
++ * interrupted by a kill signal.
++ *
++ * Only kill signals interrupt this process.
++ */
++#define wait_event_killable_timeout(wq_head, condition, timeout) \
++({ \
++ long __ret = timeout; \
++ might_sleep(); \
++ if (!___wait_cond_timeout(condition)) \
++ __ret = __wait_event_killable_timeout(wq_head, \
++ condition, timeout); \
++ __ret; \
++})
+
+ #define __wait_event_lock_irq(wq, condition, lock, cmd) \
+ (void)___wait_event(wq, condition, TASK_UNINTERRUPTIBLE, 0, 0, \
diff --git a/series.conf b/series.conf
index ac30210111..e8ccb75432 100644
--- a/series.conf
+++ b/series.conf
@@ -15966,6 +15966,7 @@
patches.drivers/net-mlx5e-Fix-TX-carrier-errors-report-in-get-stats-.patch
patches.suse/0001-dm-convert-DM-printk-macros-to-pr_-level-macros.patch
patches.drivers/hns-0005-net-hns-Fix-a-skb-used-after-free-bug.patch
+ patches.fixes/kmod-reduce-atomic-operations-on-kmod_concurrent-and.patch
patches.drivers/net-mlx5e-Initialize-CEE-s-getpermhwaddr-address-buf.patch
patches.drivers/bnxt_en-Fix-race-conditions-in-.ndo_get_stats64.patch
patches.drivers/bnxt_en-Fix-bug-in-ethtool-L.patch
@@ -15973,6 +15974,7 @@
patches.fixes/net-hns-Bugfix-for-Tx-timeout-handling-in-hns-driver.patch
patches.suse/0001-mtd-partitions-add-helper-for-deleting-partition.patch
patches.suse/0001-mtd-partitions-remove-sysfs-files-when-deleting-all-.patch
+ patches.fixes/kmod-throttle-kmod-thread-limit.patch
patches.drivers/mlx5-Avoid-that-mlx5_ib_sg_to_klms-overflows-the-klm.patch
patches.drivers/IB-core-Add-ordered-workqueue-for-RoCE-GID-managemen.patch
patches.drivers/xgene-sp3-0024-xgene-Don-t-fail-probe-if-there-is-no-clk-resource-f.patch
@@ -16002,6 +16004,8 @@
patches.drivers/net-mlx4_core-Fixes-missing-capability-bit-in-flags2.patch
patches.drivers/ibmvnic-103-Initialize-SCRQ-s-during-login-renegotiation.patch
patches.drivers/xgene-sp3-0025-xgene-Always-get-clk-source-but-ignore-if-it-s-missi.patch
+ patches.fixes/wait-add-wait_event_killable_timeout.patch
+ patches.fixes/kmod-fix-wait-on-recursive-loop.patch
patches.drivers/net-mlx4_core-Enable-4K-UAR-if-SRIOV-module-paramete.patch
patches.drivers/IB-mlx5-Fix-Raw-Packet-QP-event-handler-assignment.patch
patches.suse/0001-dm-fix-printk-rate-limiting-code.patch