--- /dev/null
+From 9731698ecb9c851f353ce2496292ff9fcea39dff Mon Sep 17 00:00:00 2001
+From: Andrey Ryabinin <arbn@yandex-team.com>
+Date: Mon, 15 Nov 2021 19:46:04 +0300
+Subject: cputime, cpuacct: Include guest time in user time in cpuacct.stat
+
+From: Andrey Ryabinin <arbn@yandex-team.com>
+
+commit 9731698ecb9c851f353ce2496292ff9fcea39dff upstream.
+
+cpuacct.stat in no-root cgroups shows user time without guest time
+included int it. This doesn't match with user time shown in root
+cpuacct.stat and /proc/<pid>/stat. This also affects cgroup2's cpu.stat
+in the same way.
+
+Make account_guest_time() to add user time to cgroup's cpustat to
+fix this.
+
+Fixes: ef12fefabf94 ("cpuacct: add per-cgroup utime/stime statistics")
+Signed-off-by: Andrey Ryabinin <arbn@yandex-team.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
+Acked-by: Tejun Heo <tj@kernel.org>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20211115164607.23784-1-arbn@yandex-team.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/sched/cputime.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/kernel/sched/cputime.c
++++ b/kernel/sched/cputime.c
+@@ -148,10 +148,10 @@ void account_guest_time(struct task_stru
+
+ /* Add guest time to cpustat. */
+ if (task_nice(p) > 0) {
+- cpustat[CPUTIME_NICE] += cputime;
++ task_group_account_field(p, CPUTIME_NICE, cputime);
+ cpustat[CPUTIME_GUEST_NICE] += cputime;
+ } else {
+- cpustat[CPUTIME_USER] += cputime;
++ task_group_account_field(p, CPUTIME_USER, cputime);
+ cpustat[CPUTIME_GUEST] += cputime;
+ }
+ }
--- /dev/null
+From 4a7f4110f79163fd53ea65438041994ed615e3af Mon Sep 17 00:00:00 2001
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+Date: Wed, 1 Dec 2021 14:59:29 +0200
+Subject: device property: Fix fwnode_graph_devcon_match() fwnode leak
+
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+
+commit 4a7f4110f79163fd53ea65438041994ed615e3af upstream.
+
+For each endpoint it encounters, fwnode_graph_devcon_match() checks
+whether the endpoint's remote port parent device is available. If it is
+not, it ignores the endpoint but does not put the reference to the remote
+endpoint port parent fwnode. For available devices the fwnode handle
+reference is put as expected.
+
+Put the reference for unavailable devices now.
+
+Fixes: 637e9e52b185 ("device connection: Find device connections also from device graphs")
+Cc: 5.1+ <stable@vger.kernel.org> # 5.1+
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/base/property.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/base/property.c
++++ b/drivers/base/property.c
+@@ -1269,8 +1269,10 @@ fwnode_graph_devcon_match(struct fwnode_
+
+ fwnode_graph_for_each_endpoint(fwnode, ep) {
+ node = fwnode_graph_get_remote_port_parent(ep);
+- if (!fwnode_device_is_available(node))
++ if (!fwnode_device_is_available(node)) {
++ fwnode_handle_put(node);
+ continue;
++ }
+
+ ret = match(node, con_id, data);
+ fwnode_handle_put(node);
--- /dev/null
+From 0726ed3065eeb910f9cea0c933bc021a848e00b3 Mon Sep 17 00:00:00 2001
+From: Yizhuo Zhai <yzhai003@ucr.edu>
+Date: Fri, 17 Dec 2021 20:22:23 -0800
+Subject: drm/amd/display: Fix the uninitialized variable in enable_stream_features()
+
+From: Yizhuo Zhai <yzhai003@ucr.edu>
+
+commit 0726ed3065eeb910f9cea0c933bc021a848e00b3 upstream.
+
+In function enable_stream_features(), the variable "old_downspread.raw"
+could be uninitialized if core_link_read_dpcd() fails, however, it is
+used in the later if statement, and further, core_link_write_dpcd()
+may write random value, which is potentially unsafe.
+
+Fixes: 6016cd9dba0f ("drm/amd/display: add helper for enabling mst stream features")
+Cc: stable@vger.kernel.org
+Signed-off-by: Yizhuo Zhai <yzhai003@ucr.edu>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
++++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+@@ -1696,6 +1696,8 @@ static void enable_stream_features(struc
+ union down_spread_ctrl old_downspread;
+ union down_spread_ctrl new_downspread;
+
++ memset(&old_downspread, 0, sizeof(old_downspread));
++
+ core_link_read_dpcd(link, DP_DOWNSPREAD_CTRL,
+ &old_downspread.raw, sizeof(old_downspread));
+
--- /dev/null
+From e8309d50e97851ff135c4e33325d37b032666b94 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Wed, 12 Jan 2022 22:38:51 -0500
+Subject: drm/amdgpu: don't do resets on APUs which don't support it
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit e8309d50e97851ff135c4e33325d37b032666b94 upstream.
+
+It can cause a hang. This is normally not enabled for GPU
+hangs on these asics, but was recently enabled for handling
+aborted suspends. This causes hangs on some platforms
+on suspend.
+
+Fixes: daf8de0874ab5b ("drm/amdgpu: always reset the asic in suspend (v2)")
+Cc: stable@vger.kernel.org
+Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1858
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/cik.c | 4 ++++
+ drivers/gpu/drm/amd/amdgpu/vi.c | 4 ++++
+ 2 files changed, 8 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/cik.c
++++ b/drivers/gpu/drm/amd/amdgpu/cik.c
+@@ -1428,6 +1428,10 @@ static int cik_asic_reset(struct amdgpu_
+ {
+ int r;
+
++ /* APUs don't have full asic reset */
++ if (adev->flags & AMD_IS_APU)
++ return 0;
++
+ if (cik_asic_reset_method(adev) == AMD_RESET_METHOD_BACO) {
+ dev_info(adev->dev, "BACO reset\n");
+ r = amdgpu_dpm_baco_reset(adev);
+--- a/drivers/gpu/drm/amd/amdgpu/vi.c
++++ b/drivers/gpu/drm/amd/amdgpu/vi.c
+@@ -956,6 +956,10 @@ static int vi_asic_reset(struct amdgpu_d
+ {
+ int r;
+
++ /* APUs don't have full asic reset */
++ if (adev->flags & AMD_IS_APU)
++ return 0;
++
+ if (vi_asic_reset_method(adev) == AMD_RESET_METHOD_BACO) {
+ dev_info(adev->dev, "BACO reset\n");
+ r = amdgpu_dpm_baco_reset(adev);
--- /dev/null
+From c4c6ef229593366ab593d4d424addc7025b54a76 Mon Sep 17 00:00:00 2001
+From: Brian Norris <briannorris@chromium.org>
+Date: Wed, 3 Nov 2021 13:52:00 -0700
+Subject: drm/bridge: analogix_dp: Make PSR-exit block less
+
+From: Brian Norris <briannorris@chromium.org>
+
+commit c4c6ef229593366ab593d4d424addc7025b54a76 upstream.
+
+Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
+"PSR exit" used non-blocking analogix_dp_send_psr_spd(). The refactor
+started using the blocking variant, for a variety of reasons -- quoting
+Sean Paul's potentially-faulty memory:
+
+"""
+ - To avoid racing a subsequent PSR entry (if exit takes a long time)
+ - To avoid racing disable/modeset
+ - We're not displaying new content while exiting PSR anyways, so there
+ is minimal utility in allowing frames to be submitted
+ - We're lying to userspace telling them frames are on the screen when
+ we're just dropping them on the floor
+"""
+
+However, I'm finding that this blocking transition is causing upwards of
+60+ ms of unneeded latency on PSR-exit, to the point that initial cursor
+movements when leaving PSR are unbearably jumpy.
+
+It turns out that we need to meet in the middle somewhere: Sean is right
+that we were "lying to userspace" with a non-blocking PSR-exit, but the
+new blocking behavior is also waiting too long:
+
+According to the eDP specification, the sink device must support PSR
+entry transitions from both state 4 (ACTIVE_RESYNC) and state 0
+(INACTIVE). It also states that in ACTIVE_RESYNC, "the Sink device must
+display the incoming active frames from the Source device with no
+visible glitches and/or artifacts."
+
+Thus, for our purposes, we only need to wait for ACTIVE_RESYNC before
+moving on; we are ready to display video, and subsequent PSR-entry is
+safe.
+
+Tested on a Samsung Chromebook Plus (i.e., Rockchip RK3399 Gru Kevin),
+where this saves about 60ms of latency, for PSR-exit that used to
+take about 80ms.
+
+Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR")
+Cc: <stable@vger.kernel.org>
+Cc: Zain Wang <wzz@rock-chips.com>
+Cc: Tomasz Figa <tfiga@chromium.org>
+Cc: Heiko Stuebner <heiko@sntech.de>
+Cc: Sean Paul <seanpaul@chromium.org>
+Signed-off-by: Brian Norris <briannorris@chromium.org>
+Reviewed-by: Sean Paul <seanpaul@chromium.org>
+Signed-off-by: Robert Foss <robert.foss@linaro.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/20211103135112.v3.1.I67612ea073c3306c71b46a87be894f79707082df@changeid
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 14 ++++++++++++--
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
++++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+@@ -998,11 +998,21 @@ int analogix_dp_send_psr_spd(struct anal
+ if (!blocking)
+ return 0;
+
++ /*
++ * db[1]!=0: entering PSR, wait for fully active remote frame buffer.
++ * db[1]==0: exiting PSR, wait for either
++ * (a) ACTIVE_RESYNC - the sink "must display the
++ * incoming active frames from the Source device with no visible
++ * glitches and/or artifacts", even though timings may still be
++ * re-synchronizing; or
++ * (b) INACTIVE - the transition is fully complete.
++ */
+ ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
+ psr_status >= 0 &&
+ ((vsc->db[1] && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||
+- (!vsc->db[1] && psr_status == DP_PSR_SINK_INACTIVE)), 1500,
+- DP_TIMEOUT_PSR_LOOP_MS * 1000);
++ (!vsc->db[1] && (psr_status == DP_PSR_SINK_ACTIVE_RESYNC ||
++ psr_status == DP_PSR_SINK_INACTIVE))),
++ 1500, DP_TIMEOUT_PSR_LOOP_MS * 1000);
+ if (ret) {
+ dev_warn(dp->dev, "Failed to apply PSR %d\n", ret);
+ return ret;
--- /dev/null
+From 6dfa2fab8ddd46faa771a102672176bee7a065de Mon Sep 17 00:00:00 2001
+From: Lucas Stach <l.stach@pengutronix.de>
+Date: Fri, 17 Dec 2021 11:59:28 +0100
+Subject: drm/etnaviv: limit submit sizes
+
+From: Lucas Stach <l.stach@pengutronix.de>
+
+commit 6dfa2fab8ddd46faa771a102672176bee7a065de upstream.
+
+Currently we allow rediculous amounts of kernel memory being allocated
+via the etnaviv GEM_SUBMIT ioctl, which is a pretty easy DoS vector. Put
+some reasonable limits in to fix this.
+
+The commandstream size is limited to 64KB, which was already a soft limit
+on older kernels after which the kernel only took submits on a best effort
+base, so there is no userspace that tries to submit commandstreams larger
+than this. Even if the whole commandstream is a single incrementing address
+load, the size limit also limits the number of potential relocs and
+referenced buffers to slightly under 64K, so use the same limit for those
+arguments. The performance monitoring infrastructure currently supports
+less than 50 performance counter signals, so limiting them to 128 on a
+single submit seems like a reasonably future-proof number for now. This
+number can be bumped if needed without breaking the interface.
+
+Cc: stable@vger.kernel.org
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
+Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
++++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+@@ -469,6 +469,12 @@ 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) {
++ DRM_ERROR("submit arguments out of size limits\n");
++ return -EINVAL;
++ }
++
+ /*
+ * Copy the command submission and bo array to kernel space in
+ * one go, and do this outside of any locks.
--- /dev/null
+From ef3ac01564067a4337bb798b8eddc6ea7b78fd10 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Jos=C3=A9=20Roberto=20de=20Souza?= <jose.souza@intel.com>
+Date: Thu, 13 Jan 2022 08:04:37 -0800
+Subject: drm/i915/display/ehl: Update voltage swing table
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: José Roberto de Souza <jose.souza@intel.com>
+
+commit ef3ac01564067a4337bb798b8eddc6ea7b78fd10 upstream.
+
+EHL table was recently updated with some minor fixes.
+
+BSpec: 21257
+Cc: stable@vger.kernel.org
+Cc: Clint Taylor <clinton.a.taylor@intel.com>
+Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
+Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220113160437.49059-1-jose.souza@intel.com
+(cherry picked from commit 5ec7baef52c367cdbda964aa662f7135c25bab1f)
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
++++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
+@@ -476,14 +476,14 @@ static const struct intel_ddi_buf_trans
+ static const union intel_ddi_buf_trans_entry _ehl_combo_phy_ddi_translations_dp[] = {
+ /* NT mV Trans mV db */
+ { .icl = { 0xA, 0x33, 0x3F, 0x00, 0x00 } }, /* 350 350 0.0 */
+- { .icl = { 0xA, 0x47, 0x36, 0x00, 0x09 } }, /* 350 500 3.1 */
+- { .icl = { 0xC, 0x64, 0x34, 0x00, 0x0B } }, /* 350 700 6.0 */
+- { .icl = { 0x6, 0x7F, 0x30, 0x00, 0x0F } }, /* 350 900 8.2 */
++ { .icl = { 0xA, 0x47, 0x38, 0x00, 0x07 } }, /* 350 500 3.1 */
++ { .icl = { 0xC, 0x64, 0x33, 0x00, 0x0C } }, /* 350 700 6.0 */
++ { .icl = { 0x6, 0x7F, 0x2F, 0x00, 0x10 } }, /* 350 900 8.2 */
+ { .icl = { 0xA, 0x46, 0x3F, 0x00, 0x00 } }, /* 500 500 0.0 */
+- { .icl = { 0xC, 0x64, 0x38, 0x00, 0x07 } }, /* 500 700 2.9 */
++ { .icl = { 0xC, 0x64, 0x37, 0x00, 0x08 } }, /* 500 700 2.9 */
+ { .icl = { 0x6, 0x7F, 0x32, 0x00, 0x0D } }, /* 500 900 5.1 */
+ { .icl = { 0xC, 0x61, 0x3F, 0x00, 0x00 } }, /* 650 700 0.6 */
+- { .icl = { 0x6, 0x7F, 0x38, 0x00, 0x07 } }, /* 600 900 3.5 */
++ { .icl = { 0x6, 0x7F, 0x37, 0x00, 0x08 } }, /* 600 900 3.5 */
+ { .icl = { 0x6, 0x7F, 0x3F, 0x00, 0x00 } }, /* 900 900 0.0 */
+ };
+
--- /dev/null
+From bd6e07e72f37f34535bec7eebc807e5fcfe37b43 Mon Sep 17 00:00:00 2001
+From: Ilia Mirkin <imirkin@alum.mit.edu>
+Date: Sun, 7 Mar 2021 12:48:53 -0500
+Subject: drm/nouveau/kms/nv04: use vzalloc for nv04_display
+
+From: Ilia Mirkin <imirkin@alum.mit.edu>
+
+commit bd6e07e72f37f34535bec7eebc807e5fcfe37b43 upstream.
+
+The struct is giant, and triggers an order-7 allocation (512K). There is
+no reason for this to be kmalloc-type memory, so switch to vmalloc. This
+should help loading nouveau on low-memory and/or long-running systems.
+
+Reported-by: Nathan E. Egge <unlord@xiph.org>
+Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Reviewed-by: Karol Herbst <kherbst@redhat.com>
+Signed-off-by: Karol Herbst <kherbst@redhat.com>
+Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/dispnv04/disp.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
++++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
+@@ -205,7 +205,7 @@ nv04_display_destroy(struct drm_device *
+ nvif_notify_dtor(&disp->flip);
+
+ nouveau_display(dev)->priv = NULL;
+- kfree(disp);
++ vfree(disp);
+
+ nvif_object_unmap(&drm->client.device.object);
+ }
+@@ -223,7 +223,7 @@ nv04_display_create(struct drm_device *d
+ struct nv04_display *disp;
+ int i, ret;
+
+- disp = kzalloc(sizeof(*disp), GFP_KERNEL);
++ disp = vzalloc(sizeof(*disp));
+ if (!disp)
+ return -ENOMEM;
+
--- /dev/null
+From a21115dd38c6cf396ba39aefd561e7903ca6149d Mon Sep 17 00:00:00 2001
+From: Dmitry Osipenko <digetx@gmail.com>
+Date: Wed, 1 Dec 2021 02:23:17 +0300
+Subject: drm/tegra: submit: Add missing pm_runtime_mark_last_busy()
+
+From: Dmitry Osipenko <digetx@gmail.com>
+
+commit a21115dd38c6cf396ba39aefd561e7903ca6149d upstream.
+
+Runtime PM auto-suspension doesn't work without pm_runtime_mark_last_busy(),
+add it.
+
+Cc: <stable@vger.kernel.org>
+Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/tegra/submit.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/tegra/submit.c
++++ b/drivers/gpu/drm/tegra/submit.c
+@@ -475,8 +475,10 @@ static void release_job(struct host1x_jo
+ kfree(job_data->used_mappings);
+ kfree(job_data);
+
+- if (pm_runtime_enabled(client->base.dev))
++ if (pm_runtime_enabled(client->base.dev)) {
++ pm_runtime_mark_last_busy(client->base.dev);
+ pm_runtime_put_autosuspend(client->base.dev);
++ }
+ }
+
+ int tegra_drm_ioctl_channel_submit(struct drm_device *drm, void *data,
--- /dev/null
+From e388164ea385f04666c4633f5dc4f951fca71890 Mon Sep 17 00:00:00 2001
+From: Xie Yongji <xieyongji@bytedance.com>
+Date: Mon, 22 Nov 2021 17:05:31 +0800
+Subject: fuse: Pass correct lend value to filemap_write_and_wait_range()
+
+From: Xie Yongji <xieyongji@bytedance.com>
+
+commit e388164ea385f04666c4633f5dc4f951fca71890 upstream.
+
+The acceptable maximum value of lend parameter in
+filemap_write_and_wait_range() is LLONG_MAX rather than -1. And there is
+also some logic depending on LLONG_MAX check in write_cache_pages(). So
+let's pass LLONG_MAX to filemap_write_and_wait_range() in
+fuse_writeback_range() instead.
+
+Fixes: 59bda8ecee2f ("fuse: flush extending writes")
+Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
+Cc: <stable@vger.kernel.org> # v5.15
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fuse/file.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/fuse/file.c
++++ b/fs/fuse/file.c
+@@ -2913,7 +2913,7 @@ fuse_direct_IO(struct kiocb *iocb, struc
+
+ static int fuse_writeback_range(struct inode *inode, loff_t start, loff_t end)
+ {
+- int err = filemap_write_and_wait_range(inode->i_mapping, start, -1);
++ int err = filemap_write_and_wait_range(inode->i_mapping, start, LLONG_MAX);
+
+ if (!err)
+ fuse_sync_writes(inode);
--- /dev/null
+From ced50f1133af12f7521bb777fcf4046ca908fb77 Mon Sep 17 00:00:00 2001
+From: Ilan Peer <ilan.peer@intel.com>
+Date: Fri, 10 Dec 2021 09:06:21 +0200
+Subject: iwlwifi: mvm: Increase the scan timeout guard to 30 seconds
+
+From: Ilan Peer <ilan.peer@intel.com>
+
+commit ced50f1133af12f7521bb777fcf4046ca908fb77 upstream.
+
+With the introduction of 6GHz channels the scan guard timeout should
+be adjusted to account for the following extreme case:
+
+- All 6GHz channels are scanned passively: 58 channels.
+- The scan is fragmented with the following parameters: 3 fragments,
+ 95 TUs suspend time, 44 TUs maximal out of channel time.
+
+The above would result with scan time of more than 24 seconds. Thus,
+set the timeout to 30 seconds.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ilan Peer <ilan.peer@intel.com>
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Link: https://lore.kernel.org/r/iwlwifi.20211210090244.3c851b93aef5.I346fa2e1d79220a6770496e773c6f87a2ad9e6c4@changeid
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
++++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
+@@ -2487,7 +2487,7 @@ static int iwl_mvm_check_running_scans(s
+ return -EIO;
+ }
+
+-#define SCAN_TIMEOUT 20000
++#define SCAN_TIMEOUT 30000
+
+ void iwl_mvm_scan_timeout_wk(struct work_struct *work)
+ {
--- /dev/null
+From db19c6f1a2a353cc8dec35b4789733a3cf6e2838 Mon Sep 17 00:00:00 2001
+From: John David Anglin <dave.anglin@bell.net>
+Date: Wed, 22 Dec 2021 16:01:31 +0000
+Subject: parisc: Fix lpa and lpa_user defines
+
+From: John David Anglin <dave.anglin@bell.net>
+
+commit db19c6f1a2a353cc8dec35b4789733a3cf6e2838 upstream.
+
+While working on the rewrite to the light-weight syscall and futex code, I
+experimented with using a hash index based on the user physical address of
+atomic variable. This exposed two problems with the lpa and lpa_user defines.
+
+Because of the copy instruction, the pa argument needs to be an early clobber
+argument. This prevents gcc from allocating the va and pa arguments to the same
+register.
+
+Secondly, the lpa instruction can cause a page fault so we need to catch
+exceptions.
+
+Signed-off-by: John David Anglin <dave.anglin@bell.net>
+Fixes: 116d753308cf ("parisc: Use lpa instruction to load physical addresses in driver code")
+Signed-off-by: Helge Deller <deller@gmx.de>
+Cc: stable@vger.kernel.org # v5.2+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/include/asm/special_insns.h | 44 +++++++++++++++++---------------
+ 1 file changed, 24 insertions(+), 20 deletions(-)
+
+--- a/arch/parisc/include/asm/special_insns.h
++++ b/arch/parisc/include/asm/special_insns.h
+@@ -2,28 +2,32 @@
+ #ifndef __PARISC_SPECIAL_INSNS_H
+ #define __PARISC_SPECIAL_INSNS_H
+
+-#define lpa(va) ({ \
+- unsigned long pa; \
+- __asm__ __volatile__( \
+- "copy %%r0,%0\n\t" \
+- "lpa %%r0(%1),%0" \
+- : "=r" (pa) \
+- : "r" (va) \
+- : "memory" \
+- ); \
+- pa; \
++#define lpa(va) ({ \
++ unsigned long pa; \
++ __asm__ __volatile__( \
++ "copy %%r0,%0\n" \
++ "8:\tlpa %%r0(%1),%0\n" \
++ "9:\n" \
++ ASM_EXCEPTIONTABLE_ENTRY(8b, 9b) \
++ : "=&r" (pa) \
++ : "r" (va) \
++ : "memory" \
++ ); \
++ pa; \
+ })
+
+-#define lpa_user(va) ({ \
+- unsigned long pa; \
+- __asm__ __volatile__( \
+- "copy %%r0,%0\n\t" \
+- "lpa %%r0(%%sr3,%1),%0" \
+- : "=r" (pa) \
+- : "r" (va) \
+- : "memory" \
+- ); \
+- pa; \
++#define lpa_user(va) ({ \
++ unsigned long pa; \
++ __asm__ __volatile__( \
++ "copy %%r0,%0\n" \
++ "8:\tlpa %%r0(%%sr3,%1),%0\n" \
++ "9:\n" \
++ ASM_EXCEPTIONTABLE_ENTRY(8b, 9b) \
++ : "=&r" (pa) \
++ : "r" (va) \
++ : "memory" \
++ ); \
++ pa; \
+ })
+
+ #define mfctl(reg) ({ \
--- /dev/null
+From 467ba14e1660b52a2f9338b484704c461bd23019 Mon Sep 17 00:00:00 2001
+From: Nicholas Piggin <npiggin@gmail.com>
+Date: Thu, 16 Dec 2021 20:33:42 +1000
+Subject: powerpc/64s/radix: Fix huge vmap false positive
+
+From: Nicholas Piggin <npiggin@gmail.com>
+
+commit 467ba14e1660b52a2f9338b484704c461bd23019 upstream.
+
+pmd_huge() is defined to false when HUGETLB_PAGE is not configured, but
+the vmap code still installs huge PMDs. This leads to false bad PMD
+errors when vunmapping because it is not seen as a huge PTE, and the bad
+PMD check catches it. The end result may not be much more serious than
+some bad pmd warning messages, because the pmd_none_or_clear_bad() does
+what we wanted and clears the huge PTE anyway.
+
+Fix this by checking pmd_is_leaf(), which checks for a PTE regardless of
+config options. The whole huge/large/leaf stuff is a tangled mess but
+that's kernel-wide and not something we can improve much in arch/powerpc
+code.
+
+pmd_page(), pud_page(), etc., called by vmalloc_to_page() on huge vmaps
+can similarly trigger a false VM_BUG_ON when CONFIG_HUGETLB_PAGE=n, so
+those checks are adjusted. The checks were added by commit d6eacedd1f0e
+("powerpc/book3s: Use config independent helpers for page table walk"),
+while implementing a similar fix for other page table walking functions.
+
+Fixes: d909f9109c30 ("powerpc/64s/radix: Enable HAVE_ARCH_HUGE_VMAP")
+Cc: stable@vger.kernel.org # v5.3+
+Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20211216103342.609192-1-npiggin@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/mm/book3s64/radix_pgtable.c | 4 ++--
+ arch/powerpc/mm/pgtable_64.c | 14 +++++++++++---
+ 2 files changed, 13 insertions(+), 5 deletions(-)
+
+--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
++++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
+@@ -1093,7 +1093,7 @@ int pud_set_huge(pud_t *pud, phys_addr_t
+
+ int pud_clear_huge(pud_t *pud)
+ {
+- if (pud_huge(*pud)) {
++ if (pud_is_leaf(*pud)) {
+ pud_clear(pud);
+ return 1;
+ }
+@@ -1140,7 +1140,7 @@ int pmd_set_huge(pmd_t *pmd, phys_addr_t
+
+ int pmd_clear_huge(pmd_t *pmd)
+ {
+- if (pmd_huge(*pmd)) {
++ if (pmd_is_leaf(*pmd)) {
+ pmd_clear(pmd);
+ return 1;
+ }
+--- a/arch/powerpc/mm/pgtable_64.c
++++ b/arch/powerpc/mm/pgtable_64.c
+@@ -102,7 +102,8 @@ EXPORT_SYMBOL(__pte_frag_size_shift);
+ struct page *p4d_page(p4d_t p4d)
+ {
+ if (p4d_is_leaf(p4d)) {
+- VM_WARN_ON(!p4d_huge(p4d));
++ if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP))
++ VM_WARN_ON(!p4d_huge(p4d));
+ return pte_page(p4d_pte(p4d));
+ }
+ return virt_to_page(p4d_pgtable(p4d));
+@@ -112,7 +113,8 @@ struct page *p4d_page(p4d_t p4d)
+ struct page *pud_page(pud_t pud)
+ {
+ if (pud_is_leaf(pud)) {
+- VM_WARN_ON(!pud_huge(pud));
++ if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP))
++ VM_WARN_ON(!pud_huge(pud));
+ return pte_page(pud_pte(pud));
+ }
+ return virt_to_page(pud_pgtable(pud));
+@@ -125,7 +127,13 @@ struct page *pud_page(pud_t pud)
+ struct page *pmd_page(pmd_t pmd)
+ {
+ if (pmd_is_leaf(pmd)) {
+- VM_WARN_ON(!(pmd_large(pmd) || pmd_huge(pmd)));
++ /*
++ * vmalloc_to_page may be called on any vmap address (not only
++ * vmalloc), and it uses pmd_page() etc., when huge vmap is
++ * enabled so these checks can't be used.
++ */
++ if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP))
++ VM_WARN_ON(!(pmd_large(pmd) || pmd_huge(pmd)));
+ return pte_page(pmd_pte(pmd));
+ }
+ return virt_to_page(pmd_page_vaddr(pmd));
--- /dev/null
+From 4da96175014be67c846fd274eace08066e525d75 Mon Sep 17 00:00:00 2001
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Sat, 16 Oct 2021 08:44:28 +0200
+Subject: remoteproc: imx_rproc: Fix a resource leak in the remove function
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+commit 4da96175014be67c846fd274eace08066e525d75 upstream.
+
+'priv->workqueue' is destroyed in the error handling path of the probe but
+not in the remove function.
+
+Add the missing call to release some resources.
+
+Cc: stable <stable@vger.kernel.org>
+Fixes: 2df7062002d0 ("remoteproc: imx_proc: enable virtio/mailbox")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Reviewed-by: Peng Fan <peng.fan@nxp.com>
+Tested-by: Peng Fan <peng.fan@nxp.com>
+Link: https://lore.kernel.org/r/d28ca94a4031bd7297d47c2164e18885a5a6ec19.1634366546.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/remoteproc/imx_rproc.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/remoteproc/imx_rproc.c
++++ b/drivers/remoteproc/imx_rproc.c
+@@ -830,6 +830,7 @@ static int imx_rproc_remove(struct platf
+ clk_disable_unprepare(priv->clk);
+ rproc_del(rproc);
+ imx_rproc_free_mbox(rproc);
++ destroy_workqueue(priv->workqueue);
+ rproc_free(rproc);
+
+ return 0;
--- /dev/null
+From c2c224932fd0ee6854d6ebfc8d059c2bcad86606 Mon Sep 17 00:00:00 2001
+From: Alexander Gordeev <agordeev@linux.ibm.com>
+Date: Thu, 4 Nov 2021 07:14:44 +0100
+Subject: s390/mm: fix 2KB pgtable release race
+
+From: Alexander Gordeev <agordeev@linux.ibm.com>
+
+commit c2c224932fd0ee6854d6ebfc8d059c2bcad86606 upstream.
+
+There is a race on concurrent 2KB-pgtables release paths when
+both upper and lower halves of the containing parent page are
+freed, one via page_table_free_rcu() + __tlb_remove_table(),
+and the other via page_table_free(). The race might lead to a
+corruption as result of remove of list item in page_table_free()
+concurrently with __free_page() in __tlb_remove_table().
+
+Let's assume first the lower and next the upper 2KB-pgtables are
+freed from a page. Since both halves of the page are allocated
+the tracking byte (bits 24-31 of the page _refcount) has value
+of 0x03 initially:
+
+CPU0 CPU1
+---- ----
+
+page_table_free_rcu() // lower half
+{
+ // _refcount[31..24] == 0x03
+ ...
+ atomic_xor_bits(&page->_refcount,
+ 0x11U << (0 + 24));
+ // _refcount[31..24] <= 0x12
+ ...
+ table = table | (1U << 0);
+ tlb_remove_table(tlb, table);
+}
+...
+__tlb_remove_table()
+{
+ // _refcount[31..24] == 0x12
+ mask = _table & 3;
+ // mask <= 0x01
+ ...
+
+ page_table_free() // upper half
+ {
+ // _refcount[31..24] == 0x12
+ ...
+ atomic_xor_bits(
+ &page->_refcount,
+ 1U << (1 + 24));
+ // _refcount[31..24] <= 0x10
+ // mask <= 0x10
+ ...
+ atomic_xor_bits(&page->_refcount,
+ mask << (4 + 24));
+ // _refcount[31..24] <= 0x00
+ // mask <= 0x00
+ ...
+ if (mask != 0) // == false
+ break;
+ fallthrough;
+ ...
+ if (mask & 3) // == false
+ ...
+ else
+ __free_page(page); list_del(&page->lru);
+ ^^^^^^^^^^^^^^^^^^ RACE! ^^^^^^^^^^^^^^^^^^^^^
+} ...
+ }
+
+The problem is page_table_free() releases the page as result of
+lower nibble unset and __tlb_remove_table() observing zero too
+early. With this update page_table_free() will use the similar
+logic as page_table_free_rcu() + __tlb_remove_table(), and mark
+the fragment as pending for removal in the upper nibble until
+after the list_del().
+
+In other words, the parent page is considered as unreferenced and
+safe to release only when the lower nibble is cleared already and
+unsetting a bit in upper nibble results in that nibble turned zero.
+
+Cc: stable@vger.kernel.org
+Suggested-by: Vlastimil Babka <vbabka@suse.com>
+Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
+Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/mm/pgalloc.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/s390/mm/pgalloc.c
++++ b/arch/s390/mm/pgalloc.c
+@@ -244,13 +244,15 @@ void page_table_free(struct mm_struct *m
+ /* Free 2K page table fragment of a 4K page */
+ bit = ((unsigned long) table & ~PAGE_MASK)/(PTRS_PER_PTE*sizeof(pte_t));
+ spin_lock_bh(&mm->context.lock);
+- mask = atomic_xor_bits(&page->_refcount, 1U << (bit + 24));
++ mask = atomic_xor_bits(&page->_refcount, 0x11U << (bit + 24));
+ mask >>= 24;
+ if (mask & 3)
+ list_add(&page->lru, &mm->context.pgtable_list);
+ else
+ list_del(&page->lru);
+ spin_unlock_bh(&mm->context.lock);
++ mask = atomic_xor_bits(&page->_refcount, 0x10U << (bit + 24));
++ mask >>= 24;
+ if (mask != 0)
+ return;
+ } else {
--- /dev/null
+From dd02d4234c9a2214a81c57a16484304a1a51872a Mon Sep 17 00:00:00 2001
+From: Andrey Ryabinin <arbn@yandex-team.com>
+Date: Mon, 15 Nov 2021 19:46:06 +0300
+Subject: sched/cpuacct: Fix user/system in shown cpuacct.usage*
+
+From: Andrey Ryabinin <arbn@yandex-team.com>
+
+commit dd02d4234c9a2214a81c57a16484304a1a51872a upstream.
+
+cpuacct has 2 different ways of accounting and showing user
+and system times.
+
+The first one uses cpuacct_account_field() to account times
+and cpuacct.stat file to expose them. And this one seems to work ok.
+
+The second one is uses cpuacct_charge() function for accounting and
+set of cpuacct.usage* files to show times. Despite some attempts to
+fix it in the past it still doesn't work. Sometimes while running KVM
+guest the cpuacct_charge() accounts most of the guest time as
+system time. This doesn't match with user&system times shown in
+cpuacct.stat or proc/<pid>/stat.
+
+Demonstration:
+ # git clone https://github.com/aryabinin/kvmsample
+ # make
+ # mkdir /sys/fs/cgroup/cpuacct/test
+ # echo $$ > /sys/fs/cgroup/cpuacct/test/tasks
+ # ./kvmsample &
+ # for i in {1..5}; do cat /sys/fs/cgroup/cpuacct/test/cpuacct.usage_sys; sleep 1; done
+ 1976535645
+ 2979839428
+ 3979832704
+ 4983603153
+ 5983604157
+
+Use cpustats accounted in cpuacct_account_field() as the source
+of user/sys times for cpuacct.usage* files. Make cpuacct_charge()
+to account only summary execution time.
+
+Fixes: d740037fac70 ("sched/cpuacct: Split usage accounting into user_usage and sys_usage")
+Signed-off-by: Andrey Ryabinin <arbn@yandex-team.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
+Acked-by: Tejun Heo <tj@kernel.org>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20211115164607.23784-3-arbn@yandex-team.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/sched/cpuacct.c | 79 +++++++++++++++++++------------------------------
+ 1 file changed, 32 insertions(+), 47 deletions(-)
+
+--- a/kernel/sched/cpuacct.c
++++ b/kernel/sched/cpuacct.c
+@@ -21,15 +21,11 @@ static const char * const cpuacct_stat_d
+ [CPUACCT_STAT_SYSTEM] = "system",
+ };
+
+-struct cpuacct_usage {
+- u64 usages[CPUACCT_STAT_NSTATS];
+-};
+-
+ /* track CPU usage of a group of tasks and its child groups */
+ struct cpuacct {
+ struct cgroup_subsys_state css;
+ /* cpuusage holds pointer to a u64-type object on every CPU */
+- struct cpuacct_usage __percpu *cpuusage;
++ u64 __percpu *cpuusage;
+ struct kernel_cpustat __percpu *cpustat;
+ };
+
+@@ -49,7 +45,7 @@ static inline struct cpuacct *parent_ca(
+ return css_ca(ca->css.parent);
+ }
+
+-static DEFINE_PER_CPU(struct cpuacct_usage, root_cpuacct_cpuusage);
++static DEFINE_PER_CPU(u64, root_cpuacct_cpuusage);
+ static struct cpuacct root_cpuacct = {
+ .cpustat = &kernel_cpustat,
+ .cpuusage = &root_cpuacct_cpuusage,
+@@ -68,7 +64,7 @@ cpuacct_css_alloc(struct cgroup_subsys_s
+ if (!ca)
+ goto out;
+
+- ca->cpuusage = alloc_percpu(struct cpuacct_usage);
++ ca->cpuusage = alloc_percpu(u64);
+ if (!ca->cpuusage)
+ goto out_free_ca;
+
+@@ -99,7 +95,8 @@ static void cpuacct_css_free(struct cgro
+ static u64 cpuacct_cpuusage_read(struct cpuacct *ca, int cpu,
+ enum cpuacct_stat_index index)
+ {
+- struct cpuacct_usage *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
++ u64 *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
++ u64 *cpustat = per_cpu_ptr(ca->cpustat, cpu)->cpustat;
+ u64 data;
+
+ /*
+@@ -115,14 +112,17 @@ static u64 cpuacct_cpuusage_read(struct
+ raw_spin_rq_lock_irq(cpu_rq(cpu));
+ #endif
+
+- if (index == CPUACCT_STAT_NSTATS) {
+- int i = 0;
+-
+- data = 0;
+- for (i = 0; i < CPUACCT_STAT_NSTATS; i++)
+- data += cpuusage->usages[i];
+- } else {
+- data = cpuusage->usages[index];
++ switch (index) {
++ case CPUACCT_STAT_USER:
++ data = cpustat[CPUTIME_USER] + cpustat[CPUTIME_NICE];
++ break;
++ case CPUACCT_STAT_SYSTEM:
++ data = cpustat[CPUTIME_SYSTEM] + cpustat[CPUTIME_IRQ] +
++ cpustat[CPUTIME_SOFTIRQ];
++ break;
++ case CPUACCT_STAT_NSTATS:
++ data = *cpuusage;
++ break;
+ }
+
+ #ifndef CONFIG_64BIT
+@@ -132,10 +132,14 @@ static u64 cpuacct_cpuusage_read(struct
+ return data;
+ }
+
+-static void cpuacct_cpuusage_write(struct cpuacct *ca, int cpu, u64 val)
++static void cpuacct_cpuusage_write(struct cpuacct *ca, int cpu)
+ {
+- struct cpuacct_usage *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
+- int i;
++ u64 *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
++ u64 *cpustat = per_cpu_ptr(ca->cpustat, cpu)->cpustat;
++
++ /* Don't allow to reset global kernel_cpustat */
++ if (ca == &root_cpuacct)
++ return;
+
+ #ifndef CONFIG_64BIT
+ /*
+@@ -143,9 +147,10 @@ static void cpuacct_cpuusage_write(struc
+ */
+ raw_spin_rq_lock_irq(cpu_rq(cpu));
+ #endif
+-
+- for (i = 0; i < CPUACCT_STAT_NSTATS; i++)
+- cpuusage->usages[i] = val;
++ *cpuusage = 0;
++ cpustat[CPUTIME_USER] = cpustat[CPUTIME_NICE] = 0;
++ cpustat[CPUTIME_SYSTEM] = cpustat[CPUTIME_IRQ] = 0;
++ cpustat[CPUTIME_SOFTIRQ] = 0;
+
+ #ifndef CONFIG_64BIT
+ raw_spin_rq_unlock_irq(cpu_rq(cpu));
+@@ -196,7 +201,7 @@ static int cpuusage_write(struct cgroup_
+ return -EINVAL;
+
+ for_each_possible_cpu(cpu)
+- cpuacct_cpuusage_write(ca, cpu, 0);
++ cpuacct_cpuusage_write(ca, cpu);
+
+ return 0;
+ }
+@@ -243,25 +248,10 @@ static int cpuacct_all_seq_show(struct s
+ seq_puts(m, "\n");
+
+ for_each_possible_cpu(cpu) {
+- struct cpuacct_usage *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
+-
+ seq_printf(m, "%d", cpu);
+-
+- for (index = 0; index < CPUACCT_STAT_NSTATS; index++) {
+-#ifndef CONFIG_64BIT
+- /*
+- * Take rq->lock to make 64-bit read safe on 32-bit
+- * platforms.
+- */
+- raw_spin_rq_lock_irq(cpu_rq(cpu));
+-#endif
+-
+- seq_printf(m, " %llu", cpuusage->usages[index]);
+-
+-#ifndef CONFIG_64BIT
+- raw_spin_rq_unlock_irq(cpu_rq(cpu));
+-#endif
+- }
++ for (index = 0; index < CPUACCT_STAT_NSTATS; index++)
++ seq_printf(m, " %llu",
++ cpuacct_cpuusage_read(ca, cpu, index));
+ seq_puts(m, "\n");
+ }
+ return 0;
+@@ -339,16 +329,11 @@ static struct cftype files[] = {
+ void cpuacct_charge(struct task_struct *tsk, u64 cputime)
+ {
+ struct cpuacct *ca;
+- int index = CPUACCT_STAT_SYSTEM;
+- struct pt_regs *regs = get_irq_regs() ? : task_pt_regs(tsk);
+-
+- if (regs && user_mode(regs))
+- index = CPUACCT_STAT_USER;
+
+ rcu_read_lock();
+
+ for (ca = task_ca(tsk); ca; ca = parent_ca(ca))
+- __this_cpu_add(ca->cpuusage->usages[index], cputime);
++ __this_cpu_add(*ca->cpuusage, cputime);
+
+ rcu_read_unlock();
+ }
--- /dev/null
+From 7576d48c64f36f6fea9df2882f710a474fa35f40 Mon Sep 17 00:00:00 2001
+From: James Smart <jsmart2021@gmail.com>
+Date: Fri, 3 Dec 2021 16:26:38 -0800
+Subject: scsi: lpfc: Fix lpfc_force_rscn ndlp kref imbalance
+
+From: James Smart <jsmart2021@gmail.com>
+
+commit 7576d48c64f36f6fea9df2882f710a474fa35f40 upstream.
+
+Issuing lpfc_force_rscn twice results in an ndlp kref use-after-free call
+trace.
+
+A prior patch reworked the get/put handling by ensuring nlp_get was done
+before WQE submission and a put was done in the completion path.
+Unfortunately, the issue_els_rscn path had a piece of legacy code that did
+a nlp_put, causing an imbalance on the ref counts.
+
+Fixed by removing the unnecessary legacy code snippet.
+
+Link: https://lore.kernel.org/r/20211204002644.116455-4-jsmart2021@gmail.com
+Fixes: 4430f7fd09ec ("scsi: lpfc: Rework locations of ndlp reference taking")
+Cc: <stable@vger.kernel.org> # v5.11+
+Co-developed-by: Justin Tee <justin.tee@broadcom.com>
+Signed-off-by: Justin Tee <justin.tee@broadcom.com>
+Signed-off-by: James Smart <jsmart2021@gmail.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/lpfc/lpfc_els.c | 5 -----
+ 1 file changed, 5 deletions(-)
+
+--- a/drivers/scsi/lpfc/lpfc_els.c
++++ b/drivers/scsi/lpfc/lpfc_els.c
+@@ -3531,11 +3531,6 @@ lpfc_issue_els_rscn(struct lpfc_vport *v
+ return 1;
+ }
+
+- /* This will cause the callback-function lpfc_cmpl_els_cmd to
+- * trigger the release of node.
+- */
+- if (!(vport->fc_flag & FC_PT2PT))
+- lpfc_nlp_put(ndlp);
+ return 0;
+ }
+
--- /dev/null
+From d3b3404df318504ec084213ab1065b73f49b0f1d Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Sat, 18 Dec 2021 10:58:56 +0100
+Subject: serial: Fix incorrect rs485 polarity on uart open
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit d3b3404df318504ec084213ab1065b73f49b0f1d upstream.
+
+Commit a6845e1e1b78 ("serial: core: Consider rs485 settings to drive
+RTS") sought to deassert RTS when opening an rs485-enabled uart port.
+That way, the transceiver does not occupy the bus until it transmits
+data.
+
+Unfortunately, the commit mixed up the logic and *asserted* RTS instead
+of *deasserting* it:
+
+The commit amended uart_port_dtr_rts(), which raises DTR and RTS when
+opening an rs232 port. "Raising" actually means lowering the signal
+that's coming out of the uart, because an rs232 transceiver not only
+changes a signal's voltage level, it also *inverts* the signal. See
+the simplified schematic in the MAX232 datasheet for an example:
+https://www.ti.com/lit/ds/symlink/max232.pdf
+
+So, to raise RTS on an rs232 port, TIOCM_RTS is *set* in port->mctrl
+and that results in the signal being driven low.
+
+In contrast to rs232, the signal level for rs485 Transmit Enable is the
+identity, not the inversion: If the transceiver expects a "high" RTS
+signal for Transmit Enable, the signal coming out of the uart must also
+be high, so TIOCM_RTS must be *cleared* in port->mctrl.
+
+The commit did the exact opposite, but it's easy to see why given the
+confusing semantics of rs232 and rs485. Fix it.
+
+Fixes: a6845e1e1b78 ("serial: core: Consider rs485 settings to drive RTS")
+Cc: stable@vger.kernel.org # v4.14+
+Cc: Rafael Gago Castano <rgc@hms.se>
+Cc: Jan Kiszka <jan.kiszka@siemens.com>
+Cc: Su Bao Cheng <baocheng.su@siemens.com>
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Link: https://lore.kernel.org/r/9395767847833f2f3193c49cde38501eeb3b5669.1639821059.git.lukas@wunner.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/serial_core.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/tty/serial/serial_core.c
++++ b/drivers/tty/serial/serial_core.c
+@@ -162,7 +162,7 @@ static void uart_port_dtr_rts(struct uar
+ int RTS_after_send = !!(uport->rs485.flags & SER_RS485_RTS_AFTER_SEND);
+
+ if (raise) {
+- if (rs485_on && !RTS_after_send) {
++ if (rs485_on && RTS_after_send) {
+ uart_set_mctrl(uport, TIOCM_DTR);
+ uart_clear_mctrl(uport, TIOCM_RTS);
+ } else {
+@@ -171,7 +171,7 @@ static void uart_port_dtr_rts(struct uar
+ } else {
+ unsigned int clear = TIOCM_DTR;
+
+- clear |= (!rs485_on || !RTS_after_send) ? TIOCM_RTS : 0;
++ clear |= (!rs485_on || RTS_after_send) ? TIOCM_RTS : 0;
+ uart_clear_mctrl(uport, clear);
+ }
+ }
xen-gntdev-fix-unmap-notification-order.patch
md-move-alloc-free-acct-bioset-in-to-personality.patch
hid-magicmouse-fix-an-error-handling-path-in-magicmouse_probe.patch
+fuse-pass-correct-lend-value-to-filemap_write_and_wait_range.patch
+serial-fix-incorrect-rs485-polarity-on-uart-open.patch
+cputime-cpuacct-include-guest-time-in-user-time-in-cpuacct.stat.patch
+sched-cpuacct-fix-user-system-in-shown-cpuacct.usage.patch
+tracing-kprobes-nmissed-not-showed-correctly-for-kretprobe.patch
+tracing-have-syscall-trace-events-use-trace_event_buffer_lock_reserve.patch
+remoteproc-imx_rproc-fix-a-resource-leak-in-the-remove-function.patch
+iwlwifi-mvm-increase-the-scan-timeout-guard-to-30-seconds.patch
+s390-mm-fix-2kb-pgtable-release-race.patch
+device-property-fix-fwnode_graph_devcon_match-fwnode-leak.patch
+drm-tegra-submit-add-missing-pm_runtime_mark_last_busy.patch
+drm-etnaviv-limit-submit-sizes.patch
+drm-amd-display-fix-the-uninitialized-variable-in-enable_stream_features.patch
+drm-nouveau-kms-nv04-use-vzalloc-for-nv04_display.patch
+drm-bridge-analogix_dp-make-psr-exit-block-less.patch
+parisc-fix-lpa-and-lpa_user-defines.patch
+powerpc-64s-radix-fix-huge-vmap-false-positive.patch
+scsi-lpfc-fix-lpfc_force_rscn-ndlp-kref-imbalance.patch
+drm-amdgpu-don-t-do-resets-on-apus-which-don-t-support-it.patch
+drm-i915-display-ehl-update-voltage-swing-table.patch
--- /dev/null
+From 3e2a56e6f639492311e0a8533f0a7aed60816308 Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Fri, 7 Jan 2022 17:56:56 -0500
+Subject: tracing: Have syscall trace events use trace_event_buffer_lock_reserve()
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit 3e2a56e6f639492311e0a8533f0a7aed60816308 upstream.
+
+Currently, the syscall trace events call trace_buffer_lock_reserve()
+directly, which means that it misses out on some of the filtering
+optimizations provided by the helper function
+trace_event_buffer_lock_reserve(). Have the syscall trace events call that
+instead, as it was missed when adding the update to use the temp buffer
+when filtering.
+
+Link: https://lkml.kernel.org/r/20220107225839.823118570@goodmis.org
+
+Cc: stable@vger.kernel.org
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Tom Zanussi <zanussi@kernel.org>
+Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
+Fixes: 0fc1b09ff1ff4 ("tracing: Use temp buffer when filtering events")
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_syscalls.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/kernel/trace/trace_syscalls.c
++++ b/kernel/trace/trace_syscalls.c
+@@ -323,8 +323,7 @@ static void ftrace_syscall_enter(void *d
+
+ trace_ctx = tracing_gen_ctx();
+
+- buffer = tr->array_buffer.buffer;
+- event = trace_buffer_lock_reserve(buffer,
++ event = trace_event_buffer_lock_reserve(&buffer, trace_file,
+ sys_data->enter_event->event.type, size, trace_ctx);
+ if (!event)
+ return;
+@@ -367,8 +366,7 @@ static void ftrace_syscall_exit(void *da
+
+ trace_ctx = tracing_gen_ctx();
+
+- buffer = tr->array_buffer.buffer;
+- event = trace_buffer_lock_reserve(buffer,
++ event = trace_event_buffer_lock_reserve(&buffer, trace_file,
+ sys_data->exit_event->event.type, sizeof(*entry),
+ trace_ctx);
+ if (!event)
--- /dev/null
+From dfea08a2116fe327f79d8f4d4b2cf6e0c88be11f Mon Sep 17 00:00:00 2001
+From: Xiangyang Zhang <xyz.sun.ok@gmail.com>
+Date: Fri, 7 Jan 2022 23:02:42 +0800
+Subject: tracing/kprobes: 'nmissed' not showed correctly for kretprobe
+
+From: Xiangyang Zhang <xyz.sun.ok@gmail.com>
+
+commit dfea08a2116fe327f79d8f4d4b2cf6e0c88be11f upstream.
+
+The 'nmissed' column of the 'kprobe_profile' file for kretprobe is
+not showed correctly, kretprobe can be skipped by two reasons,
+shortage of kretprobe_instance which is counted by tk->rp.nmissed,
+and kprobe itself is missed by some reason, so to show the sum.
+
+Link: https://lkml.kernel.org/r/20220107150242.5019-1-xyz.sun.ok@gmail.com
+
+Cc: stable@vger.kernel.org
+Fixes: 4a846b443b4e ("tracing/kprobes: Cleanup kprobe tracer code")
+Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
+Signed-off-by: Xiangyang Zhang <xyz.sun.ok@gmail.com>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_kprobe.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_kprobe.c
++++ b/kernel/trace/trace_kprobe.c
+@@ -1175,15 +1175,18 @@ static int probes_profile_seq_show(struc
+ {
+ struct dyn_event *ev = v;
+ struct trace_kprobe *tk;
++ unsigned long nmissed;
+
+ if (!is_trace_kprobe(ev))
+ return 0;
+
+ tk = to_trace_kprobe(ev);
++ nmissed = trace_kprobe_is_return(tk) ?
++ tk->rp.kp.nmissed + tk->rp.nmissed : tk->rp.kp.nmissed;
+ seq_printf(m, " %-44s %15lu %15lu\n",
+ trace_probe_name(&tk->tp),
+ trace_kprobe_nhit(tk),
+- tk->rp.kp.nmissed);
++ nmissed);
+
+ return 0;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
