From: Greg Kroah-Hartman Date: Sat, 29 Jan 2022 13:35:57 +0000 (+0100) Subject: 5.4-stable patches X-Git-Tag: v5.4.176~87 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=0bb33de70b8c5fe4b844186f72c8767fb57d3215;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: drm-etnaviv-relax-submit-size-limits.patch fsnotify-fix-fsnotify-hooks-in-pseudo-filesystems.patch pm-wakeup-simplify-the-output-logic-of-pm_show_wakelocks.patch tracing-don-t-inc-err_log-entry-count-if-entry-allocation-fails.patch tracing-histogram-fix-a-potential-memory-leak-for-kstrdup.patch --- diff --git a/queue-5.4/drm-etnaviv-relax-submit-size-limits.patch b/queue-5.4/drm-etnaviv-relax-submit-size-limits.patch new file mode 100644 index 00000000000..9b8a89a1a6e --- /dev/null +++ b/queue-5.4/drm-etnaviv-relax-submit-size-limits.patch @@ -0,0 +1,35 @@ +From e3d26528e083e612314d4dcd713f3d5a26143ddc Mon Sep 17 00:00:00 2001 +From: Lucas Stach +Date: Thu, 6 Jan 2022 19:10:21 +0100 +Subject: drm/etnaviv: relax submit size limits + +From: Lucas Stach + +commit e3d26528e083e612314d4dcd713f3d5a26143ddc upstream. + +While all userspace tried to limit commandstreams to 64K in size, +a bug in the Mesa driver lead to command streams of up to 128K +being submitted. Allow those to avoid breaking existing userspace. + +Fixes: 6dfa2fab8ddd ("drm/etnaviv: limit submit sizes") +Cc: stable@vger.kernel.org +Signed-off-by: Lucas Stach +Reviewed-by: Christian Gmeiner +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c ++++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c +@@ -471,8 +471,8 @@ int etnaviv_ioctl_gem_submit(struct drm_ + return -EINVAL; + } + +- if (args->stream_size > SZ_64K || args->nr_relocs > SZ_64K || +- args->nr_bos > SZ_64K || args->nr_pmrs > 128) { ++ if (args->stream_size > SZ_128K || args->nr_relocs > SZ_128K || ++ args->nr_bos > SZ_128K || args->nr_pmrs > 128) { + DRM_ERROR("submit arguments out of size limits\n"); + return -EINVAL; + } diff --git a/queue-5.4/fsnotify-fix-fsnotify-hooks-in-pseudo-filesystems.patch b/queue-5.4/fsnotify-fix-fsnotify-hooks-in-pseudo-filesystems.patch new file mode 100644 index 00000000000..f57a80e2886 --- /dev/null +++ b/queue-5.4/fsnotify-fix-fsnotify-hooks-in-pseudo-filesystems.patch @@ -0,0 +1,124 @@ +From 29044dae2e746949ad4b9cbdbfb248994d1dcdb4 Mon Sep 17 00:00:00 2001 +From: Amir Goldstein +Date: Thu, 20 Jan 2022 23:53:05 +0200 +Subject: fsnotify: fix fsnotify hooks in pseudo filesystems + +From: Amir Goldstein + +commit 29044dae2e746949ad4b9cbdbfb248994d1dcdb4 upstream. + +Commit 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of +d_delete()") moved the fsnotify delete hook before d_delete() so fsnotify +will have access to a positive dentry. + +This allowed a race where opening the deleted file via cached dentry +is now possible after receiving the IN_DELETE event. + +To fix the regression in pseudo filesystems, convert d_delete() calls +to d_drop() (see commit 46c46f8df9aa ("devpts_pty_kill(): don't bother +with d_delete()") and move the fsnotify hook after d_drop(). + +Add a missing fsnotify_unlink() hook in nfsdfs that was found during +the audit of fsnotify hooks in pseudo filesystems. + +Note that the fsnotify hooks in simple_recursive_removal() follow +d_invalidate(), so they require no change. + +Link: https://lore.kernel.org/r/20220120215305.282577-2-amir73il@gmail.com +Reported-by: Ivan Delalande +Link: https://lore.kernel.org/linux-fsdevel/YeNyzoDM5hP5LtGW@visor/ +Fixes: 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()") +Cc: stable@vger.kernel.org # v5.3+ +Signed-off-by: Amir Goldstein +Signed-off-by: Jan Kara +Signed-off-by: Greg Kroah-Hartman +--- + fs/configfs/dir.c | 6 +++--- + fs/devpts/inode.c | 2 +- + fs/nfsd/nfsctl.c | 5 +++-- + net/sunrpc/rpc_pipe.c | 4 ++-- + 4 files changed, 9 insertions(+), 8 deletions(-) + +--- a/fs/configfs/dir.c ++++ b/fs/configfs/dir.c +@@ -1805,8 +1805,8 @@ void configfs_unregister_group(struct co + configfs_detach_group(&group->cg_item); + d_inode(dentry)->i_flags |= S_DEAD; + dont_mount(dentry); ++ d_drop(dentry); + fsnotify_rmdir(d_inode(parent), dentry); +- d_delete(dentry); + inode_unlock(d_inode(parent)); + + dput(dentry); +@@ -1947,10 +1947,10 @@ void configfs_unregister_subsystem(struc + configfs_detach_group(&group->cg_item); + d_inode(dentry)->i_flags |= S_DEAD; + dont_mount(dentry); +- fsnotify_rmdir(d_inode(root), dentry); + inode_unlock(d_inode(dentry)); + +- d_delete(dentry); ++ d_drop(dentry); ++ fsnotify_rmdir(d_inode(root), dentry); + + inode_unlock(d_inode(root)); + +--- a/fs/devpts/inode.c ++++ b/fs/devpts/inode.c +@@ -621,8 +621,8 @@ void devpts_pty_kill(struct dentry *dent + + dentry->d_fsdata = NULL; + drop_nlink(dentry->d_inode); +- fsnotify_unlink(d_inode(dentry->d_parent), dentry); + d_drop(dentry); ++ fsnotify_unlink(d_inode(dentry->d_parent), dentry); + dput(dentry); /* d_alloc_name() in devpts_pty_new() */ + } + +--- a/fs/nfsd/nfsctl.c ++++ b/fs/nfsd/nfsctl.c +@@ -1247,7 +1247,8 @@ static void nfsdfs_remove_file(struct in + clear_ncl(d_inode(dentry)); + dget(dentry); + ret = simple_unlink(dir, dentry); +- d_delete(dentry); ++ d_drop(dentry); ++ fsnotify_unlink(dir, dentry); + dput(dentry); + WARN_ON_ONCE(ret); + } +@@ -1336,8 +1337,8 @@ void nfsd_client_rmdir(struct dentry *de + dget(dentry); + ret = simple_rmdir(dir, dentry); + WARN_ON_ONCE(ret); ++ d_drop(dentry); + fsnotify_rmdir(dir, dentry); +- d_delete(dentry); + dput(dentry); + inode_unlock(dir); + } +--- a/net/sunrpc/rpc_pipe.c ++++ b/net/sunrpc/rpc_pipe.c +@@ -599,9 +599,9 @@ static int __rpc_rmdir(struct inode *dir + + dget(dentry); + ret = simple_rmdir(dir, dentry); ++ d_drop(dentry); + if (!ret) + fsnotify_rmdir(dir, dentry); +- d_delete(dentry); + dput(dentry); + return ret; + } +@@ -612,9 +612,9 @@ static int __rpc_unlink(struct inode *di + + dget(dentry); + ret = simple_unlink(dir, dentry); ++ d_drop(dentry); + if (!ret) + fsnotify_unlink(dir, dentry); +- d_delete(dentry); + dput(dentry); + return ret; + } diff --git a/queue-5.4/pm-wakeup-simplify-the-output-logic-of-pm_show_wakelocks.patch b/queue-5.4/pm-wakeup-simplify-the-output-logic-of-pm_show_wakelocks.patch new file mode 100644 index 00000000000..6c48495eb07 --- /dev/null +++ b/queue-5.4/pm-wakeup-simplify-the-output-logic-of-pm_show_wakelocks.patch @@ -0,0 +1,51 @@ +From c9d967b2ce40d71e968eb839f36c936b8a9cf1ea Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman +Date: Thu, 13 Jan 2022 19:44:20 +0100 +Subject: PM: wakeup: simplify the output logic of pm_show_wakelocks() + +From: Greg Kroah-Hartman + +commit c9d967b2ce40d71e968eb839f36c936b8a9cf1ea upstream. + +The buffer handling in pm_show_wakelocks() is tricky, and hopefully +correct. Ensure it really is correct by using sysfs_emit_at() which +handles all of the tricky string handling logic in a PAGE_SIZE buffer +for us automatically as this is a sysfs file being read from. + +Reviewed-by: Lee Jones +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + kernel/power/wakelock.c | 11 ++++------- + 1 file changed, 4 insertions(+), 7 deletions(-) + +--- a/kernel/power/wakelock.c ++++ b/kernel/power/wakelock.c +@@ -39,23 +39,20 @@ ssize_t pm_show_wakelocks(char *buf, boo + { + struct rb_node *node; + struct wakelock *wl; +- char *str = buf; +- char *end = buf + PAGE_SIZE; ++ int len = 0; + + mutex_lock(&wakelocks_lock); + + for (node = rb_first(&wakelocks_tree); node; node = rb_next(node)) { + wl = rb_entry(node, struct wakelock, node); + if (wl->ws->active == show_active) +- str += scnprintf(str, end - str, "%s ", wl->name); ++ len += sysfs_emit_at(buf, len, "%s ", wl->name); + } +- if (str > buf) +- str--; + +- str += scnprintf(str, end - str, "\n"); ++ len += sysfs_emit_at(buf, len, "\n"); + + mutex_unlock(&wakelocks_lock); +- return (str - buf); ++ return len; + } + + #if CONFIG_PM_WAKELOCKS_LIMIT > 0 diff --git a/queue-5.4/series b/queue-5.4/series index 89bce359329..b3663b2d93c 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -3,3 +3,8 @@ s390-hypfs-include-z-vm-guests-with-access-control-group-set.patch scsi-zfcp-fix-failed-recovery-on-gone-remote-port-with-non-npiv-fcp-devices.patch udf-restore-i_lenalloc-when-inode-expansion-fails.patch udf-fix-null-ptr-deref-when-converting-from-inline-format.patch +pm-wakeup-simplify-the-output-logic-of-pm_show_wakelocks.patch +tracing-histogram-fix-a-potential-memory-leak-for-kstrdup.patch +tracing-don-t-inc-err_log-entry-count-if-entry-allocation-fails.patch +fsnotify-fix-fsnotify-hooks-in-pseudo-filesystems.patch +drm-etnaviv-relax-submit-size-limits.patch diff --git a/queue-5.4/tracing-don-t-inc-err_log-entry-count-if-entry-allocation-fails.patch b/queue-5.4/tracing-don-t-inc-err_log-entry-count-if-entry-allocation-fails.patch new file mode 100644 index 00000000000..d19daeabdd1 --- /dev/null +++ b/queue-5.4/tracing-don-t-inc-err_log-entry-count-if-entry-allocation-fails.patch @@ -0,0 +1,38 @@ +From 67ab5eb71b37b55f7c5522d080a1b42823351776 Mon Sep 17 00:00:00 2001 +From: Tom Zanussi +Date: Thu, 27 Jan 2022 15:44:18 -0600 +Subject: tracing: Don't inc err_log entry count if entry allocation fails + +From: Tom Zanussi + +commit 67ab5eb71b37b55f7c5522d080a1b42823351776 upstream. + +tr->n_err_log_entries should only be increased if entry allocation +succeeds. + +Doing it when it fails won't cause any problems other than wasting an +entry, but should be fixed anyway. + +Link: https://lkml.kernel.org/r/cad1ab28f75968db0f466925e7cba5970cec6c29.1643319703.git.zanussi@kernel.org + +Cc: stable@vger.kernel.org +Fixes: 2f754e771b1a6 ("tracing: Don't inc err_log entry count if entry allocation fails") +Signed-off-by: Tom Zanussi +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -6994,7 +6994,8 @@ static struct tracing_log_err *get_traci + err = kzalloc(sizeof(*err), GFP_KERNEL); + if (!err) + err = ERR_PTR(-ENOMEM); +- tr->n_err_log_entries++; ++ else ++ tr->n_err_log_entries++; + + return err; + } diff --git a/queue-5.4/tracing-histogram-fix-a-potential-memory-leak-for-kstrdup.patch b/queue-5.4/tracing-histogram-fix-a-potential-memory-leak-for-kstrdup.patch new file mode 100644 index 00000000000..043a85e3f1c --- /dev/null +++ b/queue-5.4/tracing-histogram-fix-a-potential-memory-leak-for-kstrdup.patch @@ -0,0 +1,37 @@ +From e629e7b525a179e29d53463d992bdee759c950fb Mon Sep 17 00:00:00 2001 +From: Xiaoke Wang +Date: Tue, 25 Jan 2022 12:07:15 +0800 +Subject: tracing/histogram: Fix a potential memory leak for kstrdup() + +From: Xiaoke Wang + +commit e629e7b525a179e29d53463d992bdee759c950fb upstream. + +kfree() is missing on an error path to free the memory allocated by +kstrdup(): + + p = param = kstrdup(data->params[i], GFP_KERNEL); + +So it is better to free it via kfree(p). + +Link: https://lkml.kernel.org/r/tencent_C52895FD37802832A3E5B272D05008866F0A@qq.com + +Cc: stable@vger.kernel.org +Fixes: d380dcde9a07c ("tracing: Fix now invalid var_ref_vals assumption in trace action") +Signed-off-by: Xiaoke Wang +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace_events_hist.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/kernel/trace/trace_events_hist.c ++++ b/kernel/trace/trace_events_hist.c +@@ -4398,6 +4398,7 @@ static int trace_action_create(struct hi + + var_ref_idx = find_var_ref_idx(hist_data, var_ref); + if (WARN_ON(var_ref_idx < 0)) { ++ kfree(p); + ret = var_ref_idx; + goto err; + }