From: Greg Kroah-Hartman Date: Tue, 15 Oct 2019 04:28:27 +0000 (+0200) Subject: 4.4-stable patches X-Git-Tag: v4.4.197~35 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=a74e58c14f946a8c9fb644549f3fcc53119628a8;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: cifs-force-reval-dentry-if-lookup_reval-flag-is-set.patch cifs-gracefully-handle-queryinfo-errors-during-open.patch iio-light-opt3001-fix-mutex-unlock-race.patch kernel-sysctl.c-do-not-override-max_threads-provided-by-userspace.patch perf-llvm-don-t-access-out-of-scope-array.patch --- diff --git a/queue-4.4/cifs-force-reval-dentry-if-lookup_reval-flag-is-set.patch b/queue-4.4/cifs-force-reval-dentry-if-lookup_reval-flag-is-set.patch new file mode 100644 index 00000000000..d345c2766eb --- /dev/null +++ b/queue-4.4/cifs-force-reval-dentry-if-lookup_reval-flag-is-set.patch @@ -0,0 +1,53 @@ +From 0b3d0ef9840f7be202393ca9116b857f6f793715 Mon Sep 17 00:00:00 2001 +From: Pavel Shilovsky +Date: Mon, 30 Sep 2019 10:06:20 -0700 +Subject: CIFS: Force reval dentry if LOOKUP_REVAL flag is set + +From: Pavel Shilovsky + +commit 0b3d0ef9840f7be202393ca9116b857f6f793715 upstream. + +Mark inode for force revalidation if LOOKUP_REVAL flag is set. +This tells the client to actually send a QueryInfo request to +the server to obtain the latest metadata in case a directory +or a file were changed remotely. Only do that if the client +doesn't have a lease for the file to avoid unneeded round +trips to the server. + +Cc: +Signed-off-by: Pavel Shilovsky +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/dir.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/fs/cifs/dir.c ++++ b/fs/cifs/dir.c +@@ -830,10 +830,16 @@ lookup_out: + static int + cifs_d_revalidate(struct dentry *direntry, unsigned int flags) + { ++ struct inode *inode; ++ + if (flags & LOOKUP_RCU) + return -ECHILD; + + if (d_really_is_positive(direntry)) { ++ inode = d_inode(direntry); ++ if ((flags & LOOKUP_REVAL) && !CIFS_CACHE_READ(CIFS_I(inode))) ++ CIFS_I(inode)->time = 0; /* force reval */ ++ + if (cifs_revalidate_dentry(direntry)) + return 0; + else { +@@ -844,7 +850,7 @@ cifs_d_revalidate(struct dentry *direntr + * attributes will have been updated by + * cifs_revalidate_dentry(). + */ +- if (IS_AUTOMOUNT(d_inode(direntry)) && ++ if (IS_AUTOMOUNT(inode) && + !(direntry->d_flags & DCACHE_NEED_AUTOMOUNT)) { + spin_lock(&direntry->d_lock); + direntry->d_flags |= DCACHE_NEED_AUTOMOUNT; diff --git a/queue-4.4/cifs-gracefully-handle-queryinfo-errors-during-open.patch b/queue-4.4/cifs-gracefully-handle-queryinfo-errors-during-open.patch new file mode 100644 index 00000000000..3e1432ee837 --- /dev/null +++ b/queue-4.4/cifs-gracefully-handle-queryinfo-errors-during-open.patch @@ -0,0 +1,45 @@ +From 30573a82fb179420b8aac30a3a3595aa96a93156 Mon Sep 17 00:00:00 2001 +From: Pavel Shilovsky +Date: Mon, 30 Sep 2019 10:06:18 -0700 +Subject: CIFS: Gracefully handle QueryInfo errors during open + +From: Pavel Shilovsky + +commit 30573a82fb179420b8aac30a3a3595aa96a93156 upstream. + +Currently if the client identifies problems when processing +metadata returned in CREATE response, the open handle is being +leaked. This causes multiple problems like a file missing a lease +break by that client which causes high latencies to other clients +accessing the file. Another side-effect of this is that the file +can't be deleted. + +Fix this by closing the file after the client hits an error after +the file was opened and the open descriptor wasn't returned to +the user space. Also convert -ESTALE to -EOPENSTALE to allow +the VFS to revalidate a dentry and retry the open. + +Cc: +Signed-off-by: Pavel Shilovsky +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/file.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/fs/cifs/file.c ++++ b/fs/cifs/file.c +@@ -252,6 +252,12 @@ cifs_nt_open(char *full_path, struct ino + rc = cifs_get_inode_info(&inode, full_path, buf, inode->i_sb, + xid, fid); + ++ if (rc) { ++ server->ops->close(xid, tcon, fid); ++ if (rc == -ESTALE) ++ rc = -EOPENSTALE; ++ } ++ + out: + kfree(buf); + return rc; diff --git a/queue-4.4/iio-light-opt3001-fix-mutex-unlock-race.patch b/queue-4.4/iio-light-opt3001-fix-mutex-unlock-race.patch new file mode 100644 index 00000000000..e53de852bd3 --- /dev/null +++ b/queue-4.4/iio-light-opt3001-fix-mutex-unlock-race.patch @@ -0,0 +1,56 @@ +From 82f3015635249a8c8c45bac303fd84905066f04f Mon Sep 17 00:00:00 2001 +From: David Frey +Date: Thu, 19 Sep 2019 15:54:18 -0700 +Subject: iio: light: opt3001: fix mutex unlock race + +From: David Frey + +commit 82f3015635249a8c8c45bac303fd84905066f04f upstream. + +When an end-of-conversion interrupt is received after performing a +single-shot reading of the light sensor, the driver was waking up the +result ready queue before checking opt->ok_to_ignore_lock to determine +if it should unlock the mutex. The problem occurred in the case where +the other thread woke up and changed the value of opt->ok_to_ignore_lock +to false prior to the interrupt thread performing its read of the +variable. In this case, the mutex would be unlocked twice. + +Signed-off-by: David Frey +Reviewed-by: Andreas Dannenberg +Fixes: 94a9b7b1809f ("iio: light: add support for TI's opt3001 light sensor") +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iio/light/opt3001.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/iio/light/opt3001.c ++++ b/drivers/iio/light/opt3001.c +@@ -646,6 +646,7 @@ static irqreturn_t opt3001_irq(int irq, + struct iio_dev *iio = _iio; + struct opt3001 *opt = iio_priv(iio); + int ret; ++ bool wake_result_ready_queue = false; + + if (!opt->ok_to_ignore_lock) + mutex_lock(&opt->lock); +@@ -680,13 +681,16 @@ static irqreturn_t opt3001_irq(int irq, + } + opt->result = ret; + opt->result_ready = true; +- wake_up(&opt->result_ready_queue); ++ wake_result_ready_queue = true; + } + + out: + if (!opt->ok_to_ignore_lock) + mutex_unlock(&opt->lock); + ++ if (wake_result_ready_queue) ++ wake_up(&opt->result_ready_queue); ++ + return IRQ_HANDLED; + } + diff --git a/queue-4.4/kernel-sysctl.c-do-not-override-max_threads-provided-by-userspace.patch b/queue-4.4/kernel-sysctl.c-do-not-override-max_threads-provided-by-userspace.patch new file mode 100644 index 00000000000..52cb897459d --- /dev/null +++ b/queue-4.4/kernel-sysctl.c-do-not-override-max_threads-provided-by-userspace.patch @@ -0,0 +1,83 @@ +From b0f53dbc4bc4c371f38b14c391095a3bb8a0bb40 Mon Sep 17 00:00:00 2001 +From: Michal Hocko +Date: Sun, 6 Oct 2019 17:58:19 -0700 +Subject: kernel/sysctl.c: do not override max_threads provided by userspace + +From: Michal Hocko + +commit b0f53dbc4bc4c371f38b14c391095a3bb8a0bb40 upstream. + +Partially revert 16db3d3f1170 ("kernel/sysctl.c: threads-max observe +limits") because the patch is causing a regression to any workload which +needs to override the auto-tuning of the limit provided by kernel. + +set_max_threads is implementing a boot time guesstimate to provide a +sensible limit of the concurrently running threads so that runaways will +not deplete all the memory. This is a good thing in general but there +are workloads which might need to increase this limit for an application +to run (reportedly WebSpher MQ is affected) and that is simply not +possible after the mentioned change. It is also very dubious to +override an admin decision by an estimation that doesn't have any direct +relation to correctness of the kernel operation. + +Fix this by dropping set_max_threads from sysctl_max_threads so any +value is accepted as long as it fits into MAX_THREADS which is important +to check because allowing more threads could break internal robust futex +restriction. While at it, do not use MIN_THREADS as the lower boundary +because it is also only a heuristic for automatic estimation and admin +might have a good reason to stop new threads to be created even when +below this limit. + +This became more severe when we switched x86 from 4k to 8k kernel +stacks. Starting since 6538b8ea886e ("x86_64: expand kernel stack to +16K") (3.16) we use THREAD_SIZE_ORDER = 2 and that halved the auto-tuned +value. + +In the particular case + + 3.12 + kernel.threads-max = 515561 + + 4.4 + kernel.threads-max = 200000 + +Neither of the two values is really insane on 32GB machine. + +I am not sure we want/need to tune the max_thread value further. If +anything the tuning should be removed altogether if proven not useful in +general. But we definitely need a way to override this auto-tuning. + +Link: http://lkml.kernel.org/r/20190922065801.GB18814@dhcp22.suse.cz +Fixes: 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits") +Signed-off-by: Michal Hocko +Reviewed-by: "Eric W. Biederman" +Cc: Heinrich Schuchardt +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/fork.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/fork.c ++++ b/kernel/fork.c +@@ -2152,7 +2152,7 @@ int sysctl_max_threads(struct ctl_table + struct ctl_table t; + int ret; + int threads = max_threads; +- int min = MIN_THREADS; ++ int min = 1; + int max = MAX_THREADS; + + t = *table; +@@ -2164,7 +2164,7 @@ int sysctl_max_threads(struct ctl_table + if (ret || !write) + return ret; + +- set_max_threads(threads); ++ max_threads = threads; + + return 0; + } diff --git a/queue-4.4/perf-llvm-don-t-access-out-of-scope-array.patch b/queue-4.4/perf-llvm-don-t-access-out-of-scope-array.patch new file mode 100644 index 00000000000..1a5737f2aa9 --- /dev/null +++ b/queue-4.4/perf-llvm-don-t-access-out-of-scope-array.patch @@ -0,0 +1,55 @@ +From 7d4c85b7035eb2f9ab217ce649dcd1bfaf0cacd3 Mon Sep 17 00:00:00 2001 +From: Ian Rogers +Date: Thu, 26 Sep 2019 15:00:18 -0700 +Subject: perf llvm: Don't access out-of-scope array + +From: Ian Rogers + +commit 7d4c85b7035eb2f9ab217ce649dcd1bfaf0cacd3 upstream. + +The 'test_dir' variable is assigned to the 'release' array which is +out-of-scope 3 lines later. + +Extend the scope of the 'release' array so that an out-of-scope array +isn't accessed. + +Bug detected by clang's address sanitizer. + +Fixes: 07bc5c699a3d ("perf tools: Make fetch_kernel_version() publicly available") +Cc: stable@vger.kernel.org # v4.4+ +Signed-off-by: Ian Rogers +Cc: Alexander Shishkin +Cc: Andi Kleen +Cc: Jiri Olsa +Cc: Namhyung Kim +Cc: Peter Zijlstra +Cc: Stephane Eranian +Cc: Wang Nan +Link: http://lore.kernel.org/lkml/20190926220018.25402-1-irogers@google.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/util/llvm-utils.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/tools/perf/util/llvm-utils.c ++++ b/tools/perf/util/llvm-utils.c +@@ -214,14 +214,14 @@ static int detect_kbuild_dir(char **kbui + const char *prefix_dir = ""; + const char *suffix_dir = ""; + ++ /* _UTSNAME_LENGTH is 65 */ ++ char release[128]; ++ + char *autoconf_path; + + int err; + + if (!test_dir) { +- /* _UTSNAME_LENGTH is 65 */ +- char release[128]; +- + err = fetch_kernel_version(NULL, release, + sizeof(release)); + if (err) diff --git a/queue-4.4/series b/queue-4.4/series index f6a73bbeb6f..a2cc4b405ec 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -65,3 +65,8 @@ usb-legousbtower-fix-open-after-failed-reset-request.patch usb-legousbtower-fix-use-after-free-on-release.patch staging-vt6655-fix-memory-leak-in-vt6655_probe.patch iio-adc-ad799x-fix-probe-error-handling.patch +iio-light-opt3001-fix-mutex-unlock-race.patch +perf-llvm-don-t-access-out-of-scope-array.patch +cifs-gracefully-handle-queryinfo-errors-during-open.patch +cifs-force-reval-dentry-if-lookup_reval-flag-is-set.patch +kernel-sysctl.c-do-not-override-max_threads-provided-by-userspace.patch