linux-stable.git/samples, branch v7.2.5

samples/damon/wsse: stop and free damon ctx when damon_call() fails

2026-09-11T09:50:49+00:00

commit a2c6fa6c23ad87c61e1379b05dc05cf5fed4bf8d upstream.

damon_sample_wsse_start() calls damon_call() right after damon_start() is
succeeded.  The kdamond that has started by the damon_start() could be
terminated by itself before or in the middle of the damon_call()
execution.  There could be multiple reasons for such a stop including
monitoring target process termination and kdamond_fn() internal memory
allocation failures.  In the case, damon_call() will fail and return an
error without cleaning up the DAMON context object.  The
damon_sample_wsse_start() caller assumes it would clean up the object,
though.  When the user requests to start DAMON again,
damon_sample_wsse_start() is called again, allocates a new DAMON context
object and overwrites the pointer for the previous object.  As a result,
the previous context object is leaked.

Safely stop the kdamond and deallocate the context object when the failure
is returned.  Note that the kdamond should be stopped first, because
damon_call() failure means not complete termination of the kdamond but
only the fact that the termination process has started.

The user impact shouldn't be that significant because the race is not easy
to happen, and only up to one DAMON context object can be leaked per race.

The issue was discovered [1] by Sashiko.

Link: https://lore.kernel.org/20260628215447.96166-6-sj@kernel.org
Link: https://lore.kernel.org/20260610034828.4632-1-sj@kernel.org [1]
Fixes: cc9c1b8c205b ("samples/damon/wsse: use damon_call() repeat mode instead of damon_callback")
Signed-off-by: SJ Park 
Reviewed-by: Zenghui Yu 
Cc:  # 6.17.x
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

samples/damon/wsse: handle damon_start() failure

2026-09-11T09:50:49+00:00

commit e4742be45ea45bf554399ce89a09f71e525d7981 upstream.

Patch series "samples/damon: handle damon_{start,stop}() failures".

All DAMON sample modules are not correctly handling failures from
damon_start().  Among those, mtier also has an additional problem for
handling of damon_stop() failures.  wsse and prcl also have a problem in
their damon_call() failure handling.  As a result, memory leaks, next
DAMON operation disruptions, and use-after-free can happen.  Fix those.

Note that only the damon_start() failure caused issues can reliably be
reproduced.  Reproducing those issues require the admin permission,
though.


This patch (of 6):

damon_sample_wsse_start() callers assume it will clean up resources when
it fails.  And the function does the cleanup for context buildup failures.
However, it is not doing the cleanup for damon_start() failure.  As a
result, when damon_start() fails, it leaks the memory for DAMON context.
Free the context in case of the failure to fix the issues.

Note that the issue can reliably be reproduced because the module calls
damon_start() in the exclusive mode.  For example,

    $ sudo damo start
    $ echo $$ | sudo tee /sys/module/damon_sample_wsse/parameters/target_pid
    $ echo Y | sudo tee /sys/module/damon_sample_wsse/parameters/enabled
    $ sudo cat /proc/allocinfo | grep damon_new_ctx

Because the first command is running another DAMON instance, the third
command fails the damon_start() call because the new DAMON instance cannot
exclusively run.  And without this fix, by repeating the third and the
fourth commands above, we can show the memory consumption is only
increasing due to the leaks.  It requires the sudo permission though.

The issue was discovered [1] by Sashiko.

Link: https://lore.kernel.org/20260628215447.96166-2-sj@kernel.org
Link: https://lore.kernel.org/20260609145814.70163-1-sj@kernel.org [1]
Fixes: b757c6cfc696 ("samples/damon/wsse: start and stop DAMON as the user requests")
Signed-off-by: SJ Park 
Reviewed-by: Zenghui Yu 
Cc:  # 6.14.x
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

samples/damon/prcl: stop and free damon ctx when damon_call() fails

2026-09-11T09:50:49+00:00

commit a73fa45d3f0f42c446ae55c5799e3d5ef044cd5d upstream.

damon_sample_prcl_start() calls damon_call() right after damon_start() is
succeeded.  The kdamond that has started by the damon_start() could be
terminated by itself before or in the middle of the damon_call()
execution.  There could be multiple reasons for such a stop including
monitoring target process termination and kdamond_fn() internal memory
allocation failures.  In the case, damon_call() will fail and return an
error without cleaning up the DAMON context object.  The
damon_sample_prcl_start() caller assumes it would clean up the object,
though.  When the user requests to start DAMON again,
damon_sample_prcl_start() is called again, allocates a new DAMON context
object and overwrites the pointer for the previous object.  As a result,
the previous context object is leaked.

Safely stop the kdamond and deallocate the context object when the failure
is returned.  Note that the kdamond should be stopped first, because
damon_call() failure means not complete termination of the kdamond but
only the fact that the termination process has started.

The user impact shouldn't be that significant because the race is not easy
to happen, and only up to one DAMON context object can be leaked per race.

The issue was discovered [1] by Sashiko.

Link: https://lore.kernel.org/20260628215447.96166-7-sj@kernel.org
Link: https://lore.kernel.org/20260610035214.4850-1-sj@kernel.org [1]
Fixes: a6c33f1054e3 ("samples/damon/prcl: use damon_call() repeat mode instead of damon_callback")
Signed-off-by: SJ Park 
Reviewed-by: Zenghui Yu 
Cc:  # 6.17.x
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

samples/damon/prcl: handle damon_start() failure

2026-09-11T09:50:49+00:00

commit 8b724349229bb6ebbf781178be011ba9bc2cca57 upstream.

damon_sample_prcl_start() callers assume it will clean up resources when
it fails.  And the function does the cleanup for context buildup failures.
However, it is not doing the cleanup for damon_start() failure.  As a
result, when damon_start() fails, it leaks the memory for DAMON context.
Free the context in case of the failure to fix the issues.

Note that the issue can reliably be reproduced because the module calls
damon_start() in the exclusive mode.  For example,

    $ sudo damo start
    $ echo $$ | sudo tee /sys/module/damon_sample_prcl/parameters/target_pid
    $ echo Y | sudo tee /sys/module/damon_sample_prcl/parameters/enabled
    $ sudo cat /proc/allocinfo | grep damon_new_ctx

Because the first command is running another DAMON instance, the third
command fails the damon_start() call because the new DAMON instance cannot
exclusively run.  And without this fix, by repeating the third and the
fourth commands above, we can show the memory consumption is only
increasing due to the leaks.  It requires the sudo permission though.

The issue was discovered [1] by Sashiko.

Link: https://lore.kernel.org/20260628215447.96166-3-sj@kernel.org
Link: https://lore.kernel.org/20260609145814.70163-1-sj@kernel.org [1]
Fixes: 2aca254620a8 ("samples/damon: introduce a skeleton of a smaple DAMON module for proactive reclamation")
Signed-off-by: SJ Park 
Reviewed-by: Zenghui Yu 
Cc:  # 6.14.x
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

samples/damon/mtier: handle damon_stop() failure

2026-09-11T09:50:49+00:00

commit 9dc5b6d66fd51b103eff21ed0df3e292f489ebc0 upstream.

damon_sample_mtier_stop() assumes its damon_stop() call will always
successfully stops the two DAMON contexts.  Hence it deallocates the two
DAMON contexts after the damon_stop() call.  However, if a given context
is already stopped, damon_stop() fails and returns an error while letting
the DAMON contexts that have not yet stopped keep running.  This kind of
unexpected early DAMON context stops could happen due to memory allocation
failures in kdamond_fn().  Because damon_sample_mtier_stop() just
deallocates all DAMON contexts with damon_target and damon_region objects
that are linked to the contexts, the execution of the unstopped DAMON
context (kdamond) ends up using the memory that freed (use-after-free).
Fix the issue by separating the damon_stop() to be invoked per context.

Note that DAMON_SYSFS also allows multiple DAMON contexts execution.  But,
it calls damon_stop() for each context one by one.  Hence this issue is
only in mtier.

For the long term, it would be better to refactor damon_stop() to always
ensure stopping all contexts regardless of the failures in the middle.
Make this fix in the current way, though, to keep it simple and easy to
backport.  I will do the refactoring later.

The issue was discovered [1] by Sashiko.

Link: https://lore.kernel.org/20260628215447.96166-5-sj@kernel.org
Link: https://lore.kernel.org/20260609014219.3013-1-sj@kernel.org [1]
Fixes: 82a08bde3cf7 ("samples/damon: implement a DAMON module for memory tiering")
Signed-off-by: SJ Park 
Reviewed-by: Zenghui Yu 
Cc:  # 6.16.x
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

samples/damon/mtier: handle damon_start() failure

2026-09-11T09:50:49+00:00

commit c7230d08ee79b13127bd2b45a3648d361ac912fc upstream.

damon_sample_mtier_start() callers assume it will clean up resources when
it fails.  And the function does the cleanup for context buildup failures.
However, it is not doing the cleanup for damon_start() failure.

As a result, when damon_start() fails, it could leak the memory for DAMON
context.  Also, if damon_start() fails for only the second context, the
first context will indefinitely run, and avoid starting other DAMON
contexts since it is running in the exclusive mode.  Stop possibly started
DAMON context and free the contexts in case of the failure to fix the
issues.

Note that the issue can reliably be reproduced because the module calls
damon_start() in the exclusive mode.  For example,

    $ sudo damo start
    $ echo Y | sudo tee /sys/module/damon_sample_mtier/parameters/enabled
    $ sudo cat /proc/allocinfo | grep damon_new_ctx

Because the first command is running another DAMON instance, the second
command fails the damon_start() call because the new DAMON instance cannot
exclusively run.  And without this fix, by repeating the second and the
third commands above, we can show the memory consumption is only
increasing due to the leaks.  It requires the sudo permission though.

The issue was discovered [1] by Sashiko.

Link: https://lore.kernel.org/20260628215447.96166-4-sj@kernel.org
Link: https://lore.kernel.org/20260608112455.274231F00893@smtp.kernel.org [1]
Fixes: 82a08bde3cf7 ("samples/damon: implement a DAMON module for memory tiering")
Signed-off-by: SJ Park 
Reviewed-by: Zenghui Yu 
Cc:  # 6.16.x
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

samples/damon/mtier: error out for zero quota goal target values

2026-08-05T03:02:02+00:00

Patch series "mm/damon: avoid division by zero from damos_quota_score()".

DAMON_SAMPLE_MTIER and DAMON_LRU_SORT allow the user to trigger division
by zero in damos_quota_score().  Avoid it by adding parameters validation
checks.


This patch (of 2):

damos_quota_score() can trigger division by zero if the target_value is
zero.  DAMON_SAMPLE_MTIER lets users set the target_value via
node0_mem_{used,free}_bp parameters.  It doesn't guard zero value case,
though.  As a result, users can trigger division by zero.  Fix the issue
by returning an error when the user tries to start DAMON with zero
node0_mem_{used,free}_bp parameter values.

DAMON_SAMPLE_MTIER is just a sample module, but the consequence is quite
bad.  Also the zero node0_mem_free_bp parameter might look like a
reasonable setup to some users.  Hence, the issue might really happen in
the real world.

One reliable way to reproduce the issue is like below:

    # cd /sys/module/damon_sample_mtier/parameters
    # echo 4096 > node0_start_addr
    # echo 8192 > node0_end_addr
    # echo 8192 > node1_start_addr
    # echo 81920 > node1_end_addr
    # echo 0 > node0_mem_free_bp
    # echo Y > enabled
    # dmesg -w
    [...]
    [18792.235916] Oops: divide error: 0000 [#1] SMP NOPTI
    [...]
    [18792.242787] RIP: 0010:damos_quota_score+0x6f/0x480
    [...]

This issue was discovered [1] by Sashiko.

Link: https://lore.kernel.org/20260803134034.15217-1-sj@kernel.org
Link: https://lore.kernel.org/20260803134034.15217-2-sj@kernel.org
Link: https://lore.kernel.org/20260801202657.117135-1-sj@kernel.org [1]
Fixes: c5e67d40a102 ("samples/damon/mtier: add parameters for node0 memory usage")
Signed-off-by: SJ Park 
Cc:  # 6.17.x
Signed-off-by: Andrew Morton

Merge tag 'trace-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace

2026-07-12T16:46:37+00:00

Pull tracing fixes from Steven Rostedt:

 - Free field in error path of synthetic event parse

   In __create_synth_event() the field was allocated but was not freed
   in the error path

 - Fix ring_buffer_event_length() on 8 byte aligned architectures

   On architectures with CONFIG_HAVE_64BIT_ALIGNED_ACCESS set to y, the
   ring_buffer_event_length() may return the wrong size. This is because
   archs with that config set will always use the "big event meta
   header" as that is 8 bytes keeping the payload 8 bytes aligned, even
   when a 4 byte header could hold the size of the event

   But ring_buffer_event_length() doesn't take this into account and
   only subtracts 4 bytes for the meta header in the length when it
   should have subtracted 8 bytes

 - Have osnoise wait for a full rcu synchronization on unregister

   osnoise_unregister_instance() used to call synchronize_rcu() before
   freeing its copy of the instance but was switched to kfree_rcu(). The
   osniose tracer has code that traverses the instances that it uses,
   and inst is just a pointer to that instance. By using kfree_rcu()
   instead of synchronize_rcu(), the instance that the inst pointer is
   pointing to can be freed while the osnoise code is still referencing
   it

   That is, a rmdir on an instance first unregisters the tracer. When
   the unregister finishes, the rmdir expects that the tracer is
   finished with the instance that it is using. By putting back the
   synchronize_rcu() in osnoise_unregister_instance() the unregistering
   of osnoise will now return when all the users of the instance have
   finished

 - Remove an unused setting of "ret" in tracing_set_tracer()

 - Fix ring_buffer_read_page() copying events

   The commit that changed ring_buffer_read_page() to show dropped
   events from the buffer itself, split the "commit" variable between
   the commit value (with flags) and "size" that holds the size of the
   sub-buffer. A cut and paste error changed the test of the reading
   from checking the size of the buffer to the size of the event causing
   reads to only read one event at a time

 - Make tracepoint_printk a static variable

   When the tracing sysctl knobs were move from sysctl.c to trace.c, the
   variable tracepoint_printk no longer needed to be global. Make it
   static

 - Fix some typos

 - Fix NULL pointer dereference in func_set_flag()

   The flags update of the function tracer first checks if the value of
   the flag is the same and exits if they are, and then it checks if the
   current tracer is the function tracer and exits if it isn't. The
   problem is that these checks need to be in a reversed order, as if
   the tracer isn't the function tracer, then the flag being checked may
   not exist. Reverse the order of these checks

 - Fix ufs core trace events to not dereference a pointer in TP_printk()

   The TP_printk() part of the TRACE_EVENT() macro is called when the
   user reads the "trace" file. This can be seconds, minutes, hours,
   days, weeks, and even months after the data was recorded into the
   ring buffer. Thus, saving a pointer to an object into the ring buffer
   and then dereferencing it from TP_printk() can cause harm as the
   object the pointer is pointing to may no longer exist

   Fix all the trace events in ufs core to save the device name in the
   ring buffer instead of dereferencing the device descriptor from
   TP_printk()

 - Prevent out-of-bound reads in glob matching of trace events

   The filter logic of events allows simple glob logic to add wild cards
   to filter on strings. But some events have fields that may not have a
   terminating 'nul' character. This may cause the glob matching to go
   beyond the string. Change the logic to always pass in the length of
   the field that is being matched

 - Add no-rcu-check version of trace_##event##_enabled()

   The trace_##event##_enabled() usually wraps trace events to do extra
   work that is only needed when the trace event is enabled. But this
   can hide events that are placed in locations where RCU is not
   watching, and can make lockdep not see these bugs when the event is
   not enabled

   The trace_##event##_enabled() was updated to always test to make sure
   RCU is watching to catch locations that may call events without RCU
   being active

   This caused a false positive for the irq_disabled() and related
   events. As that use trace_irq_disabled_enabled() to force RCU to be
   watching when the event is enabled via the ct_irq_enter() function,
   calls the event, and then calls ct_irq_exit() to put RCU back to its
   original state

   The trace_irq_disabled_enabled() should not trigger a warning when
   RCU is not watching because the code within its block handles the
   case properly. Make a __trace_##event##_enabled() version for this
   event to use that doesn't check RCU is watching as it handles the
   case when it isn't

 - Fix use-after-free in user_event_mm_dup()

   When the enabler is removed from the link list, it is freed
   immediately. But it is protected via RCU and needs to be freed after
   an RCU grace period. Use queue_rcu_work() so that the event_mutex can
   also be taken as user_event_put() takes the mutex on the last
   reference is released

 - Free type string in error path of parse_synth_field()

   There's an error path in parse_synth_field() where the allocated type
   string is not freed

 - Add selftest that tests deferred event teardown

 - Fix leak in error path of trace_remote_alloc_buffer()

   If page allocation fails, the desc->nr_cpus is not incremented for
   the current CPU and the allocations done for it are not freed

 - Fix allocation length in trace_remote_alloc_buffer()

   The logic to calculate the struct_len was doing a double count and
   setting the value too large. Calculate the size upfront to fix the
   error and simplify the logic

 - Fix sparse CPU masks in ring_buffer_desc()

   If there are sparse CPUs (gaps in the numbering), the
   ring_buffer_desc() will fail as it tests the CPU number against the
   number of CPUs that are used

* tag 'trace-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  ring-buffer: Allow sparse CPU masks in ring_buffer_desc()
  tracing/remotes: Fix struct_len in trace_remote_alloc_buffer()
  tracing/remotes: Fix leak in trace_remote_alloc_buffer() error path
  selftests/user_events: Wait for deferred event teardown after unregister
  tracing/synthetic: Free type string on error path
  tracing/user_events: Fix use-after-free in user_event_mm_dup()
  tracing: Add a no-rcu-check version of trace_##event##_enabled()
  tracing: Prevent out-of-bounds read in glob matching
  ufs: core: tracing: Do not dereference pointers in TP_printk()
  tracing: Fix NULL pointer dereference in func_set_flag()
  samples: ftrace: Fix typos in benchmark comment
  tracing: Make tracepoint_printk static as not exported
  ring-buffer: Fix ring_buffer_read_page() copying only one event per page
  tracing: Remove unused ret assignment in tracing_set_tracer()
  tracing/osnoise: Call synchronize_rcu() when unregistering
  ring-buffer: Fix event length with forced 8-byte alignment
  tracing/synthetic: Free pending field on error path

samples: ftrace: Fix typos in benchmark comment

2026-07-07T14:42:28+00:00

Fix two typos in the ftrace operations sample benchmark comment.

Link: https://patch.msgid.link/20260621095153.93762-1-pyudistira519@gmail.com
Signed-off-by: Yudistira Putra 
Signed-off-by: Steven Rostedt

Merge tag 'mm-hotfixes-stable-2026-07-06-17-49' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2026-07-07T01:51:36+00:00

Pull misc fixes from Andrew Morton:
 "20 hotfixes. 17 are for MM. 12 are cc:stable and the remaining 8
  address post-7.1 issues or aren't considered suitable for backporting.

  Two patches from SJ addresses a couple of quite old DAMON issues. And
  two patches from Yichong Chen fixes tools/virtio build issues. The
  remaining patches are singletons"

* tag 'mm-hotfixes-stable-2026-07-06-17-49' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
  tools/include: include stdint.h for SIZE_MAX in overflow.h
  tools/virtio: add missing compat definitions for vhost_net_test
  mm: do file ownership checks with the proper mount idmap
  samples/damon/mtier: fail early if address range parameters are invalid
  mm: a second pagecache maintainer
  mm/damon: add a kernel-doc comment for damon_ctx->rnd_state
  mm/damon: add a kernel-doc comment for damon_ctx->probes
  mailmap: add entries for Radu Rendec
  selftests/mm: hmm-tests: include linux/mman.h to access MADV_COLLAPSE
  selftests/mm: pagemap_ioctl: use the correct page size for transact_test()
  fs/proc: fix KPF_KSM reported for all anonymous pages
  mm: page_ext: add count limit to page_ext_iter_next to prevent invalid PFN access
  mm/damon/ops-common: handle extreme intervals in damon_hot_score()
  MAINTAINERS: add Lance as an rmap reviewer
  mm/compaction: handle free_pages_prepare() properly in compaction_free()
  mm/damon/sysfs-schemes: put stats for scheme_add_dirs() internal error
  mm/damon/sysfs-schemes: fix dir put orders in access_pattern_add_dirs()
  mm: shrinker: fix NULL pointer dereference in debugfs
  mm: shrinker: fix shrinker_info teardown race with expansion
  selftests/mm: fix ksft_process_madv.sh test category