Skip to content
Snippets Groups Projects
  1. Feb 27, 2024
  2. Feb 20, 2024
  3. Feb 15, 2024
  4. Feb 08, 2024
  5. Feb 07, 2024
  6. Jan 26, 2024
    • Marco Elver's avatar
      stackdepot: make fast paths lock-less again · 4434a56e
      Marco Elver authored
      With the introduction of the pool_rwlock (reader-writer lock), several
      fast paths end up taking the pool_rwlock as readers.  Furthermore,
      stack_depot_put() unconditionally takes the pool_rwlock as a writer.
      
      Despite allowing readers to make forward-progress concurrently,
      reader-writer locks have inherent cache contention issues, which does not
      scale well on systems with large CPU counts.
      
      Rework the synchronization story of stack depot to again avoid taking any
      locks in the fast paths.  This is done by relying on RCU-protected list
      traversal, and the NMI-safe subset of RCU to delay reuse of freed stack
      records.  See code comments for more details.
      
      Along with the performance issues, this also fixes incorrect nesting of
      rwlock within a raw_spinlock, given that stack depot should still be
      usable from anywhere:
      
       | [ BUG: Invalid wait context ]
       | -----------------------------
       | swapper/0/1 is trying to lock:
       | ffffffff89869be8 (pool_rwlock){..--}-{3:3}, at: stack_depot_save_flags
       | other info that might help us debug this:
       | context-{5:5}
       | 2 locks held by swapper/0/1:
       |  #0: ffffffff89632440 (rcu_read_lock){....}-{1:3}, at: __queue_work
       |  #1: ffff888100092018 (&pool->lock){-.-.}-{2:2}, at: __queue_work  <-- raw_spin_lock
      
      Stack depot usage stats are similar to the previous version after a KASAN
      kernel boot:
      
       $ cat /sys/kernel/debug/stackdepot/stats
       pools: 838
       allocations: 29865
       frees: 6604
       in_use: 23261
       freelist_size: 1879
      
      The number of pools is the same as previously.  The freelist size is
      minimally larger, but this may also be due to variance across system
      boots.  This shows that even though we do not eagerly wait for the next
      RCU grace period (such as with synchronize_rcu() or call_rcu()) after
      freeing a stack record - requiring depot_pop_free() to "poll" if an entry
      may be used - new allocations are very likely to happen in later RCU grace
      periods.
      
      Link: https://lkml.kernel.org/r/20240118110216.2539519-2-elver@google.com
      
      
      Fixes: 108be8de ("lib/stackdepot: allow users to evict stack traces")
      Reported-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarMarco Elver <elver@google.com>
      Reviewed-by: default avatarAndrey Konovalov <andreyknvl@gmail.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Konovalov <andreyknvl@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      4434a56e
    • Marco Elver's avatar
      stackdepot: add stats counters exported via debugfs · c2a29254
      Marco Elver authored
      Add a few basic stats counters for stack depot that can be used to derive
      if stack depot is working as intended.  This is a snapshot of the new
      stats after booting a system with a KASAN-enabled kernel:
      
       $ cat /sys/kernel/debug/stackdepot/stats
       pools: 838
       allocations: 29861
       frees: 6561
       in_use: 23300
       freelist_size: 1840
      
      Generally, "pools" should be well below the max; once the system is
      booted, "in_use" should remain relatively steady.
      
      Link: https://lkml.kernel.org/r/20240118110216.2539519-1-elver@google.com
      
      
      Signed-off-by: default avatarMarco Elver <elver@google.com>
      Reviewed-by: default avatarAndrey Konovalov <andreyknvl@gmail.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Alexander Potapenko <glider@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      c2a29254
  7. Jan 22, 2024
    • Marco Pagani's avatar
      kunit: run test suites only after module initialization completes · a1af6a2b
      Marco Pagani authored
      
      Commit 2810c1e9 ("kunit: Fix wild-memory-access bug in
      kunit_free_suite_set()") fixed a wild-memory-access bug that could have
      happened during the loading phase of test suites built and executed as
      loadable modules. However, it also introduced a problematic side effect
      that causes test suites modules to crash when they attempt to register
      fake devices.
      
      When a module is loaded, it traverses the MODULE_STATE_UNFORMED and
      MODULE_STATE_COMING states before reaching the normal operating state
      MODULE_STATE_LIVE. Finally, when the module is removed, it moves to
      MODULE_STATE_GOING before being released. However, if the loading
      function load_module() fails between complete_formation() and
      do_init_module(), the module goes directly from MODULE_STATE_COMING to
      MODULE_STATE_GOING without passing through MODULE_STATE_LIVE.
      
      This behavior was causing kunit_module_exit() to be called without
      having first executed kunit_module_init(). Since kunit_module_exit() is
      responsible for freeing the memory allocated by kunit_module_init()
      through kunit_filter_suites(), this behavior was resulting in a
      wild-memory-access bug.
      
      Commit 2810c1e9 ("kunit: Fix wild-memory-access bug in
      kunit_free_suite_set()") fixed this issue by running the tests when the
      module is still in MODULE_STATE_COMING. However, modules in that state
      are not fully initialized, lacking sysfs kobjects. Therefore, if a test
      module attempts to register a fake device, it will inevitably crash.
      
      This patch proposes a different approach to fix the original
      wild-memory-access bug while restoring the normal module execution flow
      by making kunit_module_exit() able to detect if kunit_module_init() has
      previously initialized the tests suite set. In this way, test modules
      can once again register fake devices without crashing.
      
      This behavior is achieved by checking whether mod->kunit_suites is a
      virtual or direct mapping address. If it is a virtual address, then
      kunit_module_init() has allocated the suite_set in kunit_filter_suites()
      using kmalloc_array(). On the contrary, if mod->kunit_suites is still
      pointing to the original address that was set when looking up the
      .kunit_test_suites section of the module, then the loading phase has
      failed and there's no memory to be freed.
      
      v4:
      - rebased on 6.8
      - noted that kunit_filter_suites() must return a virtual address
      v3:
      - add a comment to clarify why the start address is checked
      v2:
      - add include <linux/mm.h>
      
      Fixes: 2810c1e9 ("kunit: Fix wild-memory-access bug in kunit_free_suite_set()")
      Reviewed-by: default avatarDavid Gow <davidgow@google.com>
      Tested-by: default avatarRae Moar <rmoar@google.com>
      Tested-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Reviewed-by: default avatarJavier Martinez Canillas <javierm@redhat.com>
      Signed-off-by: default avatarMarco Pagani <marpagan@redhat.com>
      Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      a1af6a2b
    • Dan Carpenter's avatar
      kunit: device: Fix a NULL vs IS_ERR() check in init() · 083974eb
      Dan Carpenter authored
      
      The root_device_register() function does not return NULL, it returns
      error pointers.  Fix the check to match.
      
      Fixes: d03c720e ("kunit: Add APIs for managing devices")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@linaro.org>
      Reviewed-by: default avatarRae Moar <rmoar@google.com>
      Reviewed-by: default avatarDavid Gow <davidgow@google.com>
      Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      083974eb
    • Dan Carpenter's avatar
      kunit: Fix a NULL vs IS_ERR() bug · ed1a72fb
      Dan Carpenter authored
      
      The kunit_device_register() function doesn't return NULL, it returns
      error pointers.  Change the KUNIT_ASSERT_NOT_NULL() to check for
      ERR_OR_NULL().
      
      Fixes: d03c720e ("kunit: Add APIs for managing devices")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@linaro.org>
      Reviewed-by: default avatarRae Moar <rmoar@google.com>
      Reviewed-by: default avatarDavid Gow <davidgow@google.com>
      Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      ed1a72fb
  8. Jan 19, 2024
  9. Jan 18, 2024
  10. Jan 15, 2024
  11. Jan 12, 2024
  12. Jan 08, 2024
  13. Jan 03, 2024
  14. Dec 29, 2023
  15. Dec 28, 2023
  16. Dec 27, 2023
  17. Dec 22, 2023
  18. Dec 21, 2023
  19. Dec 20, 2023
Loading