--- /dev/null
+From a8899b8728013c7b2456f0bfa20e5fea85ee0fd1 Mon Sep 17 00:00:00 2001
+From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+Date: Mon, 21 Nov 2022 15:56:54 +0100
+Subject: drm/i915: Fix negative value passed as remaining time
+
+From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+
+commit a8899b8728013c7b2456f0bfa20e5fea85ee0fd1 upstream.
+
+Commit b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work
+with GuC") extended the API of intel_gt_retire_requests_timeout() with an
+extra argument 'remaining_timeout', intended for passing back unconsumed
+portion of requested timeout when 0 (success) is returned. However, when
+request retirement happens to succeed despite an error returned by a call
+to dma_fence_wait_timeout(), that error code (a negative value) is passed
+back instead of remaining time. If we then pass that negative value
+forward as requested timeout to intel_uc_wait_for_idle(), an explicit BUG
+will be triggered.
+
+If request retirement succeeds but an error code is passed back via
+remaininig_timeout, we may have no clue on how much of the initial timeout
+might have been left for spending it on waiting for GuC to become idle.
+OTOH, since all pending requests have been successfully retired, that
+error code has been already ignored by intel_gt_retire_requests_timeout(),
+then we shouldn't fail.
+
+Assume no more time has been left on error and pass 0 timeout value to
+intel_uc_wait_for_idle() to give it a chance to return success if GuC is
+already idle.
+
+v3: Don't fail on any error passed back via remaining_timeout.
+
+v2: Fix the issue on the caller side, not the provider.
+
+Fixes: b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work with GuC")
+Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+Cc: stable@vger.kernel.org # v5.15+
+Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20221121145655.75141-2-janusz.krzysztofik@linux.intel.com
+(cherry picked from commit f235dbd5b768e238d365fd05d92de5a32abc1c1f)
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gt/intel_gt.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/i915/gt/intel_gt.c
++++ b/drivers/gpu/drm/i915/gt/intel_gt.c
+@@ -616,8 +616,13 @@ int intel_gt_wait_for_idle(struct intel_
+ return -EINTR;
+ }
+
+- return timeout ? timeout : intel_uc_wait_for_idle(>->uc,
+- remaining_timeout);
++ if (timeout)
++ return timeout;
++
++ if (remaining_timeout < 0)
++ remaining_timeout = 0;
++
++ return intel_uc_wait_for_idle(>->uc, remaining_timeout);
+ }
+
+ int intel_gt_init(struct intel_gt *gt)
--- /dev/null
+From 12b8b046e4c9de40fa59b6f067d6826f4e688f68 Mon Sep 17 00:00:00 2001
+From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+Date: Mon, 21 Nov 2022 15:56:55 +0100
+Subject: drm/i915: Never return 0 if not all requests retired
+
+From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+
+commit 12b8b046e4c9de40fa59b6f067d6826f4e688f68 upstream.
+
+Users of intel_gt_retire_requests_timeout() expect 0 return value on
+success. However, we have no protection from passing back 0 potentially
+returned by a call to dma_fence_wait_timeout() when it succedes right
+after its timeout has expired.
+
+Replace 0 with -ETIME before potentially using the timeout value as return
+code, so -ETIME is returned if there are still some requests not retired
+after timeout, 0 otherwise.
+
+v3: Use conditional expression, more compact but also better reflecting
+ intention standing behind the change.
+
+v2: Move the added lines down so flush_submission() is not affected.
+
+Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with retire_request")
+Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
+Cc: stable@vger.kernel.org # v5.5+
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20221121145655.75141-3-janusz.krzysztofik@linux.intel.com
+(cherry picked from commit f301a29f143760ce8d3d6b6a8436d45d3448cde6)
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gt/intel_gt_requests.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
++++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+@@ -199,7 +199,7 @@ out_active: spin_lock(&timelines->lock);
+ if (remaining_timeout)
+ *remaining_timeout = timeout;
+
+- return active_count ? timeout : 0;
++ return active_count ? timeout ?: -ETIME : 0;
+ }
+
+ static void retire_work_handler(struct work_struct *work)
--- /dev/null
+From 3c1ea6a5f4f55d4e376675dda16945eb5d9bb4de Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Fri, 18 Nov 2022 20:52:01 +0200
+Subject: drm/i915: Remove non-existent pipes from bigjoiner pipe mask
+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 3c1ea6a5f4f55d4e376675dda16945eb5d9bb4de upstream.
+
+bigjoiner_pipes() doesn't consider that:
+- RKL only has three pipes
+- some pipes may be fused off
+
+This means that intel_atomic_check_bigjoiner() won't reject
+all configurations that would need a non-existent pipe.
+Instead we just keep on rolling witout actually having
+reserved the slave pipe we need.
+
+It's possible that we don't outright explode anywhere due to
+this since eg. for_each_intel_crtc_in_pipe_mask() will only
+walk the crtcs we've registered even though the passed in
+pipe_mask asks for more of them. But clearly the thing won't
+do what is expected of it when the required pipes are not
+present.
+
+Fix the problem by consulting the device info pipe_mask already
+in bigjoiner_pipes().
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20221118185201.10469-1-ville.syrjala@linux.intel.com
+Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
+(cherry picked from commit f1c87a94a1087a26f41007ee83264033007421b5)
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_display.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_display.c
++++ b/drivers/gpu/drm/i915/display/intel_display.c
+@@ -3717,12 +3717,16 @@ out:
+
+ static u8 bigjoiner_pipes(struct drm_i915_private *i915)
+ {
++ u8 pipes;
++
+ if (DISPLAY_VER(i915) >= 12)
+- return BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D);
++ pipes = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D);
+ else if (DISPLAY_VER(i915) >= 11)
+- return BIT(PIPE_B) | BIT(PIPE_C);
++ pipes = BIT(PIPE_B) | BIT(PIPE_C);
+ else
+- return 0;
++ pipes = 0;
++
++ return pipes & RUNTIME_INFO(i915)->pipe_mask;
+ }
+
+ static bool transcoder_ddi_func_is_enabled(struct drm_i915_private *dev_priv,
--- /dev/null
+From 95bc35f9bee5220dad4e8567654ab3288a181639 Mon Sep 17 00:00:00 2001
+From: SeongJae Park <sj@kernel.org>
+Date: Tue, 22 Nov 2022 19:48:31 +0000
+Subject: mm/damon/sysfs: fix wrong empty schemes assumption under online tuning in damon_sysfs_set_schemes()
+
+From: SeongJae Park <sj@kernel.org>
+
+commit 95bc35f9bee5220dad4e8567654ab3288a181639 upstream.
+
+Commit da87878010e5 ("mm/damon/sysfs: support online inputs update") made
+'damon_sysfs_set_schemes()' to be called for running DAMON context, which
+could have schemes. In the case, DAMON sysfs interface is supposed to
+update, remove, or add schemes to reflect the sysfs files. However, the
+code is assuming the DAMON context wouldn't have schemes at all, and
+therefore creates and adds new schemes. As a result, the code doesn't
+work as intended for online schemes tuning and could have more than
+expected memory footprint. The schemes are all in the DAMON context, so
+it doesn't leak the memory, though.
+
+Remove the wrong asssumption (the DAMON context wouldn't have schemes) in
+'damon_sysfs_set_schemes()' to fix the bug.
+
+Link: https://lkml.kernel.org/r/20221122194831.3472-1-sj@kernel.org
+Fixes: da87878010e5 ("mm/damon/sysfs: support online inputs update")
+Signed-off-by: SeongJae Park <sj@kernel.org>
+Cc: <stable@vger.kernel.org> [5.19+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/damon/sysfs.c | 46 ++++++++++++++++++++++++++++++++++++++++++++--
+ 1 file changed, 44 insertions(+), 2 deletions(-)
+
+--- a/mm/damon/sysfs.c
++++ b/mm/damon/sysfs.c
+@@ -2286,12 +2286,54 @@ static struct damos *damon_sysfs_mk_sche
+ sysfs_scheme->action, "a, &wmarks);
+ }
+
++static void damon_sysfs_update_scheme(struct damos *scheme,
++ struct damon_sysfs_scheme *sysfs_scheme)
++{
++ struct damon_sysfs_access_pattern *access_pattern =
++ sysfs_scheme->access_pattern;
++ struct damon_sysfs_quotas *sysfs_quotas = sysfs_scheme->quotas;
++ struct damon_sysfs_weights *sysfs_weights = sysfs_quotas->weights;
++ struct damon_sysfs_watermarks *sysfs_wmarks = sysfs_scheme->watermarks;
++
++ scheme->pattern.min_sz_region = access_pattern->sz->min;
++ scheme->pattern.max_sz_region = access_pattern->sz->max;
++ scheme->pattern.min_nr_accesses = access_pattern->nr_accesses->min;
++ scheme->pattern.max_nr_accesses = access_pattern->nr_accesses->max;
++ scheme->pattern.min_age_region = access_pattern->age->min;
++ scheme->pattern.max_age_region = access_pattern->age->max;
++
++ scheme->action = sysfs_scheme->action;
++
++ scheme->quota.ms = sysfs_quotas->ms;
++ scheme->quota.sz = sysfs_quotas->sz;
++ scheme->quota.reset_interval = sysfs_quotas->reset_interval_ms;
++ scheme->quota.weight_sz = sysfs_weights->sz;
++ scheme->quota.weight_nr_accesses = sysfs_weights->nr_accesses;
++ scheme->quota.weight_age = sysfs_weights->age;
++
++ scheme->wmarks.metric = sysfs_wmarks->metric;
++ scheme->wmarks.interval = sysfs_wmarks->interval_us;
++ scheme->wmarks.high = sysfs_wmarks->high;
++ scheme->wmarks.mid = sysfs_wmarks->mid;
++ scheme->wmarks.low = sysfs_wmarks->low;
++}
++
+ static int damon_sysfs_set_schemes(struct damon_ctx *ctx,
+ struct damon_sysfs_schemes *sysfs_schemes)
+ {
+- int i;
++ struct damos *scheme, *next;
++ int i = 0;
++
++ damon_for_each_scheme_safe(scheme, next, ctx) {
++ if (i < sysfs_schemes->nr)
++ damon_sysfs_update_scheme(scheme,
++ sysfs_schemes->schemes_arr[i]);
++ else
++ damon_destroy_scheme(scheme);
++ i++;
++ }
+
+- for (i = 0; i < sysfs_schemes->nr; i++) {
++ for (; i < sysfs_schemes->nr; i++) {
+ struct damos *scheme, *next;
+
+ scheme = damon_sysfs_mk_scheme(sysfs_schemes->schemes_arr[i]);
kconfig.debug-provide-a-little-extra-frame_warn-leeway-when-kasan-is-enabled.patch
drm-amdgpu-temporarily-disable-broken-clang-builds-due-to-blown-stack-frame.patch
drm-amdgpu-enable-vangogh-vcn-indirect-sram-mode.patch
+drm-i915-remove-non-existent-pipes-from-bigjoiner-pipe-mask.patch
+drm-i915-fix-negative-value-passed-as-remaining-time.patch
+drm-i915-never-return-0-if-not-all-requests-retired.patch
+tracing-osnoise-fix-duration-type.patch
+tracing-fix-race-where-histograms-can-be-called-before-the-event.patch
+tracing-free-buffers-when-a-used-dynamic-event-is-removed.patch
+mm-damon-sysfs-fix-wrong-empty-schemes-assumption-under-online-tuning-in-damon_sysfs_set_schemes.patch
--- /dev/null
+From ef38c79a522b660f7f71d45dad2d6244bc741841 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Wed, 23 Nov 2022 16:43:23 -0500
+Subject: tracing: Fix race where histograms can be called before the event
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit ef38c79a522b660f7f71d45dad2d6244bc741841 upstream.
+
+commit 94eedf3dded5 ("tracing: Fix race where eprobes can be called before
+the event") fixed an issue where if an event is soft disabled, and the
+trigger is being added, there's a small window where the event sees that
+there's a trigger but does not see that it requires reading the event yet,
+and then calls the trigger with the record == NULL.
+
+This could be solved with adding memory barriers in the hot path, or to
+make sure that all the triggers requiring a record check for NULL. The
+latter was chosen.
+
+Commit 94eedf3dded5 set the eprobe trigger handle to check for NULL, but
+the same needs to be done with histograms.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20221118211809.701d40c0f8a757b0df3c025a@kernel.org/
+Link: https://lore.kernel.org/linux-trace-kernel/20221123164323.03450c3a@gandalf.local.home
+
+Cc: Tom Zanussi <zanussi@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: 7491e2c442781 ("tracing: Add a probe that attaches to trace events")
+Reported-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_events_hist.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/kernel/trace/trace_events_hist.c
++++ b/kernel/trace/trace_events_hist.c
+@@ -5051,6 +5051,9 @@ static void event_hist_trigger(struct ev
+ void *key = NULL;
+ unsigned int i;
+
++ if (unlikely(!rbe))
++ return;
++
+ memset(compound_key, 0, hist_data->key_size);
+
+ for_each_hist_key_field(i, hist_data) {
--- /dev/null
+From 4313e5a613049dfc1819a6dfb5f94cf2caff9452 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Wed, 23 Nov 2022 17:14:34 -0500
+Subject: tracing: Free buffers when a used dynamic event is removed
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit 4313e5a613049dfc1819a6dfb5f94cf2caff9452 upstream.
+
+After 65536 dynamic events have been added and removed, the "type" field
+of the event then uses the first type number that is available (not
+currently used by other events). A type number is the identifier of the
+binary blobs in the tracing ring buffer (known as events) to map them to
+logic that can parse the binary blob.
+
+The issue is that if a dynamic event (like a kprobe event) is traced and
+is in the ring buffer, and then that event is removed (because it is
+dynamic, which means it can be created and destroyed), if another dynamic
+event is created that has the same number that new event's logic on
+parsing the binary blob will be used.
+
+To show how this can be an issue, the following can crash the kernel:
+
+ # cd /sys/kernel/tracing
+ # for i in `seq 65536`; do
+ echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events
+ # done
+
+For every iteration of the above, the writing to the kprobe_events will
+remove the old event and create a new one (with the same format) and
+increase the type number to the next available on until the type number
+reaches over 65535 which is the max number for the 16 bit type. After it
+reaches that number, the logic to allocate a new number simply looks for
+the next available number. When an dynamic event is removed, that number
+is then available to be reused by the next dynamic event created. That is,
+once the above reaches the max number, the number assigned to the event in
+that loop will remain the same.
+
+Now that means deleting one dynamic event and created another will reuse
+the previous events type number. This is where bad things can happen.
+After the above loop finishes, the kprobes/foo event which reads the
+do_sys_openat2 function call's first parameter as an integer.
+
+ # echo 1 > kprobes/foo/enable
+ # cat /etc/passwd > /dev/null
+ # cat trace
+ cat-2211 [005] .... 2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196
+ cat-2211 [005] .... 2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196
+ cat-2211 [005] .... 2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196
+ cat-2211 [005] .... 2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196
+ # echo 0 > kprobes/foo/enable
+
+Now if we delete the kprobe and create a new one that reads a string:
+
+ # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events
+
+And now we can the trace:
+
+ # cat trace
+ sendmail-1942 [002] ..... 530.136320: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������"
+ cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������"
+ cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������"
+ cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������"
+ bash-1515 [007] ..... 534.299093: foo: (do_sys_openat2+0x0/0x240) arg1="kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk���������@��4Z����;Y�����U
+
+And dmesg has:
+
+==================================================================
+BUG: KASAN: use-after-free in string+0xd4/0x1c0
+Read of size 1 at addr ffff88805fdbbfa0 by task cat/2049
+
+ CPU: 0 PID: 2049 Comm: cat Not tainted 6.1.0-rc6-test+ #641
+ Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016
+ Call Trace:
+ <TASK>
+ dump_stack_lvl+0x5b/0x77
+ print_report+0x17f/0x47b
+ kasan_report+0xad/0x130
+ string+0xd4/0x1c0
+ vsnprintf+0x500/0x840
+ seq_buf_vprintf+0x62/0xc0
+ trace_seq_printf+0x10e/0x1e0
+ print_type_string+0x90/0xa0
+ print_kprobe_event+0x16b/0x290
+ print_trace_line+0x451/0x8e0
+ s_show+0x72/0x1f0
+ seq_read_iter+0x58e/0x750
+ seq_read+0x115/0x160
+ vfs_read+0x11d/0x460
+ ksys_read+0xa9/0x130
+ do_syscall_64+0x3a/0x90
+ entry_SYSCALL_64_after_hwframe+0x63/0xcd
+ RIP: 0033:0x7fc2e972ade2
+ Code: c0 e9 b2 fe ff ff 50 48 8d 3d b2 3f 0a 00 e8 05 f0 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
+ RSP: 002b:00007ffc64e687c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
+ RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fc2e972ade2
+ RDX: 0000000000020000 RSI: 00007fc2e980d000 RDI: 0000000000000003
+ RBP: 00007fc2e980d000 R08: 00007fc2e980c010 R09: 0000000000000000
+ R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000020f00
+ R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000
+ </TASK>
+
+ The buggy address belongs to the physical page:
+ page:ffffea00017f6ec0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5fdbb
+ flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)
+ raw: 000fffffc0000000 0000000000000000 ffffea00017f6ec8 0000000000000000
+ raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
+ page dumped because: kasan: bad access detected
+
+ Memory state around the buggy address:
+ ffff88805fdbbe80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+ ffff88805fdbbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+ >ffff88805fdbbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+ ^
+ ffff88805fdbc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+ ffff88805fdbc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+ ==================================================================
+
+This was found when Zheng Yejian sent a patch to convert the event type
+number assignment to use IDA, which gives the next available number, and
+this bug showed up in the fuzz testing by Yujie Liu and the kernel test
+robot. But after further analysis, I found that this behavior is the same
+as when the event type numbers go past the 16bit max (and the above shows
+that).
+
+As modules have a similar issue, but is dealt with by setting a
+"WAS_ENABLED" flag when a module event is enabled, and when the module is
+freed, if any of its events were enabled, the ring buffer that holds that
+event is also cleared, to prevent reading stale events. The same can be
+done for dynamic events.
+
+If any dynamic event that is being removed was enabled, then make sure the
+buffers they were enabled in are now cleared.
+
+Link: https://lkml.kernel.org/r/20221123171434.545706e3@gandalf.local.home
+Link: https://lore.kernel.org/all/20221110020319.1259291-1-zhengyejian1@huawei.com/
+
+Cc: stable@vger.kernel.org
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Depends-on: e18eb8783ec49 ("tracing: Add tracing_reset_all_online_cpus_unlocked() function")
+Depends-on: 5448d44c38557 ("tracing: Add unified dynamic event framework")
+Depends-on: 6212dd29683ee ("tracing/kprobes: Use dyn_event framework for kprobe events")
+Depends-on: 065e63f951432 ("tracing: Only have rmmod clear buffers that its events were active in")
+Depends-on: 575380da8b469 ("tracing: Only clear trace buffer on module unload if event was traced")
+Fixes: 77b44d1b7c283 ("tracing/kprobes: Rename Kprobe-tracer to kprobe-event")
+Reported-by: Zheng Yejian <zhengyejian1@huawei.com>
+Reported-by: Yujie Liu <yujie.liu@intel.com>
+Reported-by: kernel test robot <yujie.liu@intel.com>
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_dynevent.c | 2 ++
+ kernel/trace/trace_events.c | 11 ++++++++++-
+ 2 files changed, 12 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_dynevent.c
++++ b/kernel/trace/trace_dynevent.c
+@@ -118,6 +118,7 @@ int dyn_event_release(const char *raw_co
+ if (ret)
+ break;
+ }
++ tracing_reset_all_online_cpus();
+ mutex_unlock(&event_mutex);
+ out:
+ argv_free(argv);
+@@ -214,6 +215,7 @@ int dyn_events_release_all(struct dyn_ev
+ break;
+ }
+ out:
++ tracing_reset_all_online_cpus();
+ mutex_unlock(&event_mutex);
+
+ return ret;
+--- a/kernel/trace/trace_events.c
++++ b/kernel/trace/trace_events.c
+@@ -2880,7 +2880,10 @@ static int probe_remove_event_call(struc
+ * TRACE_REG_UNREGISTER.
+ */
+ if (file->flags & EVENT_FILE_FL_ENABLED)
+- return -EBUSY;
++ goto busy;
++
++ if (file->flags & EVENT_FILE_FL_WAS_ENABLED)
++ tr->clear_trace = true;
+ /*
+ * The do_for_each_event_file_safe() is
+ * a double loop. After finding the call for this
+@@ -2893,6 +2896,12 @@ static int probe_remove_event_call(struc
+ __trace_remove_event_call(call);
+
+ return 0;
++ busy:
++ /* No need to clear the trace now */
++ list_for_each_entry(tr, &ftrace_trace_arrays, list) {
++ tr->clear_trace = false;
++ }
++ return -EBUSY;
+ }
+
+ /* Remove an event_call */
--- /dev/null
+From 022632f6c43a86f2135642dccd5686de318e861d Mon Sep 17 00:00:00 2001
+From: Daniel Bristot de Oliveira <bristot@kernel.org>
+Date: Thu, 17 Nov 2022 14:46:17 +0100
+Subject: tracing/osnoise: Fix duration type
+
+From: Daniel Bristot de Oliveira <bristot@kernel.org>
+
+commit 022632f6c43a86f2135642dccd5686de318e861d upstream.
+
+The duration type is a 64 long value, not an int. This was
+causing some long noise to report wrong values.
+
+Change the duration to a 64 bits value.
+
+Link: https://lkml.kernel.org/r/a93d8a8378c7973e9c609de05826533c9e977939.1668692096.git.bristot@kernel.org
+
+Cc: stable@vger.kernel.org
+Cc: Daniel Bristot de Oliveira <bristot@kernel.org>
+Cc: Steven Rostedt <rostedt@goodmis.org>
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Jonathan Corbet <corbet@lwn.net>
+Fixes: bce29ac9ce0b ("trace: Add osnoise tracer")
+Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_osnoise.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/kernel/trace/trace_osnoise.c
++++ b/kernel/trace/trace_osnoise.c
+@@ -917,7 +917,7 @@ void osnoise_trace_irq_entry(int id)
+ void osnoise_trace_irq_exit(int id, const char *desc)
+ {
+ struct osnoise_variables *osn_var = this_cpu_osn_var();
+- int duration;
++ s64 duration;
+
+ if (!osn_var->sampling)
+ return;
+@@ -1048,7 +1048,7 @@ static void trace_softirq_entry_callback
+ static void trace_softirq_exit_callback(void *data, unsigned int vec_nr)
+ {
+ struct osnoise_variables *osn_var = this_cpu_osn_var();
+- int duration;
++ s64 duration;
+
+ if (!osn_var->sampling)
+ return;
+@@ -1144,7 +1144,7 @@ thread_entry(struct osnoise_variables *o
+ static void
+ thread_exit(struct osnoise_variables *osn_var, struct task_struct *t)
+ {
+- int duration;
++ s64 duration;
+
+ if (!osn_var->sampling)
+ return;
projects / thirdparty / kernel / stable-queue.git / commitdiff
