--- /dev/null
+From e84131a88a8cdcd6fe9f234ed98e3f8ca049142b Mon Sep 17 00:00:00 2001
+From: Joshua Ashton <joshua@froggi.es>
+Date: Thu, 16 Jun 2022 01:21:27 +0000
+Subject: amd/display/dc: Fix COLOR_ENCODING and COLOR_RANGE doing nothing for DCN20+
+
+From: Joshua Ashton <joshua@froggi.es>
+
+commit e84131a88a8cdcd6fe9f234ed98e3f8ca049142b upstream.
+
+For DCN20 and above, the code that actually hooks up the provided
+input_color_space got lost at some point.
+
+Fixes COLOR_ENCODING and COLOR_RANGE doing nothing on DCN20+.
+Tested using Steam Remote Play Together + gamescope.
+
+Update other DCNs the same wasy DCN1.x was updates in
+commit a1e07ba89d49 ("drm/amd/display: Use plane->color_space for dpp if specified")
+
+Fixes: a1e07ba89d49 ("drm/amd/display: Use plane->color_space for dpp if specified")
+Signed-off-by: Joshua Ashton <joshua@froggi.es>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c | 3 +++
+ drivers/gpu/drm/amd/display/dc/dcn201/dcn201_dpp.c | 3 +++
+ drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c | 3 +++
+ 3 files changed, 9 insertions(+)
+
+--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c
++++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c
+@@ -212,6 +212,9 @@ static void dpp2_cnv_setup (
+ break;
+ }
+
++ /* Set default color space based on format if none is given. */
++ color_space = input_color_space ? input_color_space : color_space;
++
+ if (is_2bit == 1 && alpha_2bit_lut != NULL) {
+ REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT0, alpha_2bit_lut->lut0);
+ REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT1, alpha_2bit_lut->lut1);
+--- a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_dpp.c
++++ b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_dpp.c
+@@ -153,6 +153,9 @@ static void dpp201_cnv_setup(
+ break;
+ }
+
++ /* Set default color space based on format if none is given. */
++ color_space = input_color_space ? input_color_space : color_space;
++
+ if (is_2bit == 1 && alpha_2bit_lut != NULL) {
+ REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT0, alpha_2bit_lut->lut0);
+ REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT1, alpha_2bit_lut->lut1);
+--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
++++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
+@@ -294,6 +294,9 @@ static void dpp3_cnv_setup (
+ break;
+ }
+
++ /* Set default color space based on format if none is given. */
++ color_space = input_color_space ? input_color_space : color_space;
++
+ if (is_2bit == 1 && alpha_2bit_lut != NULL) {
+ REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT0, alpha_2bit_lut->lut0);
+ REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT1, alpha_2bit_lut->lut1);
--- /dev/null
+From 98b02e9f002b21944176774cf420c4d674f6201c Mon Sep 17 00:00:00 2001
+From: George Shen <george.shen@amd.com>
+Date: Thu, 7 Oct 2021 15:59:44 -0400
+Subject: drm/amd/display: Fix typo in override_lane_settings
+
+From: George Shen <george.shen@amd.com>
+
+commit 98b02e9f002b21944176774cf420c4d674f6201c upstream.
+
+[Why]
+The function currently skips overriding the drive
+settings of the first lane.
+
+[How]
+Change for loop to start at 0 instead of 1.
+
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
+Acked-by: Alan Liu <HaoPing.Liu@amd.com>
+Signed-off-by: George Shen <george.shen@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
++++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+@@ -944,7 +944,7 @@ static void override_lane_settings(const
+
+ return;
+
+- for (lane = 1; lane < LANE_COUNT_DP_MAX; lane++) {
++ for (lane = 0; lane < LANE_COUNT_DP_MAX; lane++) {
+ if (lt_settings->voltage_swing)
+ lane_settings[lane].VOLTAGE_SWING = *lt_settings->voltage_swing;
+ if (lt_settings->pre_emphasis)
--- /dev/null
+From 13bd259b64bb58ae130923ada42ebc19bf3f2fa2 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Mon, 13 Jun 2022 23:14:39 +0300
+Subject: drm/i915: Implement w/a 22010492432 for adl-s
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit 13bd259b64bb58ae130923ada42ebc19bf3f2fa2 upstream.
+
+adl-s needs the combo PLL DCO fraction w/a as well.
+Gets us slightly more accurate clock out of the PLL.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220613201439.23341-1-ville.syrjala@linux.intel.com
+Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
+(cherry picked from commit d36bdd77b9e6aa7f5cb7b0f11ebbab8e5febf10b)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
++++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+@@ -2437,7 +2437,7 @@ static void icl_wrpll_params_populate(st
+ }
+
+ /*
+- * Display WA #22010492432: ehl, tgl, adl-p
++ * Display WA #22010492432: ehl, tgl, adl-s, adl-p
+ * Program half of the nominal DCO divider fraction value.
+ */
+ static bool
+@@ -2445,7 +2445,7 @@ ehl_combo_pll_div_frac_wa_needed(struct
+ {
+ return ((IS_PLATFORM(i915, INTEL_ELKHARTLAKE) &&
+ IS_JSL_EHL_DISPLAY_STEP(i915, STEP_B0, STEP_FOREVER)) ||
+- IS_TIGERLAKE(i915) || IS_ALDERLAKE_P(i915)) &&
++ IS_TIGERLAKE(i915) || IS_ALDERLAKE_S(i915) || IS_ALDERLAKE_P(i915)) &&
+ i915->dpll.ref_clks.nssc == 38400;
+ }
+
--- /dev/null
+From cb995f4eeba9d268fd4b56c2423ad6c1d1ea1b82 Mon Sep 17 00:00:00 2001
+From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
+Date: Fri, 17 Jun 2022 20:00:17 -0400
+Subject: filemap: Handle sibling entries in filemap_get_read_batch()
+
+From: Matthew Wilcox (Oracle) <willy@infradead.org>
+
+commit cb995f4eeba9d268fd4b56c2423ad6c1d1ea1b82 upstream.
+
+If a read races with an invalidation followed by another read, it is
+possible for a folio to be replaced with a higher-order folio. If that
+happens, we'll see a sibling entry for the new folio in the next iteration
+of the loop. This manifests as a NULL pointer dereference while holding
+the RCU read lock.
+
+Handle this by simply returning. The next call will find the new folio
+and handle it correctly. The other ways of handling this rare race are
+more complex and it's just not worth it.
+
+Reported-by: Dave Chinner <david@fromorbit.com>
+Reported-by: Brian Foster <bfoster@redhat.com>
+Debugged-by: Brian Foster <bfoster@redhat.com>
+Tested-by: Brian Foster <bfoster@redhat.com>
+Reviewed-by: Brian Foster <bfoster@redhat.com>
+Fixes: cbd59c48ae2b ("mm/filemap: use head pages in generic_file_buffered_read")
+Cc: stable@vger.kernel.org
+Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/filemap.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/mm/filemap.c
++++ b/mm/filemap.c
+@@ -2385,6 +2385,8 @@ static void filemap_get_read_batch(struc
+ continue;
+ if (xas.xa_index > max || xa_is_value(folio))
+ break;
++ if (xa_is_sibling(folio))
++ break;
+ if (!folio_try_get_rcu(folio))
+ goto retry;
+
--- /dev/null
+From eeaa345e128515135ccb864c04482180c08e3259 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Wed, 8 Jun 2022 20:22:05 +0200
+Subject: mm/slub: add missing TID updates on slab deactivation
+
+From: Jann Horn <jannh@google.com>
+
+commit eeaa345e128515135ccb864c04482180c08e3259 upstream.
+
+The fastpath in slab_alloc_node() assumes that c->slab is stable as long as
+the TID stays the same. However, two places in __slab_alloc() currently
+don't update the TID when deactivating the CPU slab.
+
+If multiple operations race the right way, this could lead to an object
+getting lost; or, in an even more unlikely situation, it could even lead to
+an object being freed onto the wrong slab's freelist, messing up the
+`inuse` counter and eventually causing a page to be freed to the page
+allocator while it still contains slab objects.
+
+(I haven't actually tested these cases though, this is just based on
+looking at the code. Writing testcases for this stuff seems like it'd be
+a pain...)
+
+The race leading to state inconsistency is (all operations on the same CPU
+and kmem_cache):
+
+ - task A: begin do_slab_free():
+ - read TID
+ - read pcpu freelist (==NULL)
+ - check `slab == c->slab` (true)
+ - [PREEMPT A->B]
+ - task B: begin slab_alloc_node():
+ - fastpath fails (`c->freelist` is NULL)
+ - enter __slab_alloc()
+ - slub_get_cpu_ptr() (disables preemption)
+ - enter ___slab_alloc()
+ - take local_lock_irqsave()
+ - read c->freelist as NULL
+ - get_freelist() returns NULL
+ - write `c->slab = NULL`
+ - drop local_unlock_irqrestore()
+ - goto new_slab
+ - slub_percpu_partial() is NULL
+ - get_partial() returns NULL
+ - slub_put_cpu_ptr() (enables preemption)
+ - [PREEMPT B->A]
+ - task A: finish do_slab_free():
+ - this_cpu_cmpxchg_double() succeeds()
+ - [CORRUPT STATE: c->slab==NULL, c->freelist!=NULL]
+
+From there, the object on c->freelist will get lost if task B is allowed to
+continue from here: It will proceed to the retry_load_slab label,
+set c->slab, then jump to load_freelist, which clobbers c->freelist.
+
+But if we instead continue as follows, we get worse corruption:
+
+ - task A: run __slab_free() on object from other struct slab:
+ - CPU_PARTIAL_FREE case (slab was on no list, is now on pcpu partial)
+ - task A: run slab_alloc_node() with NUMA node constraint:
+ - fastpath fails (c->slab is NULL)
+ - call __slab_alloc()
+ - slub_get_cpu_ptr() (disables preemption)
+ - enter ___slab_alloc()
+ - c->slab is NULL: goto new_slab
+ - slub_percpu_partial() is non-NULL
+ - set c->slab to slub_percpu_partial(c)
+ - [CORRUPT STATE: c->slab points to slab-1, c->freelist has objects
+ from slab-2]
+ - goto redo
+ - node_match() fails
+ - goto deactivate_slab
+ - existing c->freelist is passed into deactivate_slab()
+ - inuse count of slab-1 is decremented to account for object from
+ slab-2
+
+At this point, the inuse count of slab-1 is 1 lower than it should be.
+This means that if we free all allocated objects in slab-1 except for one,
+SLUB will think that slab-1 is completely unused, and may free its page,
+leading to use-after-free.
+
+Fixes: c17dda40a6a4e ("slub: Separate out kmem_cache_cpu processing from deactivate_slab")
+Fixes: 03e404af26dc2 ("slub: fast release on full slab")
+Cc: stable@vger.kernel.org
+Signed-off-by: Jann Horn <jannh@google.com>
+Acked-by: Christoph Lameter <cl@linux.com>
+Acked-by: David Rientjes <rientjes@google.com>
+Reviewed-by: Muchun Song <songmuchun@bytedance.com>
+Tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
+Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+Link: https://lore.kernel.org/r/20220608182205.2945720-1-jannh@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/slub.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/mm/slub.c
++++ b/mm/slub.c
+@@ -2939,6 +2939,7 @@ redo:
+
+ if (!freelist) {
+ c->slab = NULL;
++ c->tid = next_tid(c->tid);
+ local_unlock_irqrestore(&s->cpu_slab->lock, flags);
+ stat(s, DEACTIVATE_BYPASS);
+ goto new_slab;
+@@ -2971,6 +2972,7 @@ deactivate_slab:
+ freelist = c->freelist;
+ c->slab = NULL;
+ c->freelist = NULL;
++ c->tid = next_tid(c->tid);
+ local_unlock_irqrestore(&s->cpu_slab->lock, flags);
+ deactivate_slab(s, slab, freelist);
+
dm-do-not-return-early-from-dm_io_complete-if-blk_sts_again-without-polling.patch
dm-mirror-log-clear-log-bits-up-to-bits_per_long-boundary.patch
tracing-kprobes-check-whether-get_kretprobe-returns-null-in-kretprobe_dispatcher.patch
+filemap-handle-sibling-entries-in-filemap_get_read_batch.patch
+mm-slub-add-missing-tid-updates-on-slab-deactivation.patch
+drm-i915-implement-w-a-22010492432-for-adl-s.patch
+amd-display-dc-fix-color_encoding-and-color_range-doing-nothing-for-dcn20.patch
+drm-amd-display-fix-typo-in-override_lane_settings.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
