Skip to content
Snippets Groups Projects
  1. Jun 10, 2023
    • Arnd Bergmann's avatar
      kunit: include debugfs header file · 23108f6a
      Arnd Bergmann authored
      An extra #include statement is needed to ensure the prototypes for debugfs
      interfaces are visible, avoiding this warning:
      
      lib/kunit/debugfs.c:28:6: error: no previous prototype for 'kunit_debugfs_cleanup' [-Werror=missing-prototypes]
      lib/kunit/debugfs.c:33:6: error: no previous prototype for 'kunit_debugfs_init' [-Werror=missing-prototypes]
      lib/kunit/debugfs.c:102:6: error: no previous prototype for 'kunit_debugfs_create_suite' [-Werror=missing-prototypes]
      lib/kunit/debugfs.c:118:6: error: no previous prototype for 'kunit_debugfs_destroy_suite' [-Werror=missing-prototypes]
      
      Link: https://lkml.kernel.org/r/20230517131102.934196-10-arnd@kernel.org
      
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarDavid Gow <davidgow@google.com>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Dennis Zhou <dennis@kernel.org>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Paul Moore <paul@paul-moore.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael@kernel.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Waiman Long <longman@redhat.com>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      23108f6a
    • Arnd Bergmann's avatar
      lib: devmem_is_allowed: include linux/io.h · 6b76ca2a
      Arnd Bergmann authored
      The devmem_is_allowed() function is defined in a file of the same name,
      but the declaration is in asm/io.h, which is not included there, causing a
      W=1 warning:
      
      lib/devmem_is_allowed.c:20:5: error: no previous prototype for 'devmem_is_allowed' [-Werror=missing-prototypes]
      
      Include the appropriate header to avoid the warning.
      
      Link: https://lkml.kernel.org/r/20230517131102.934196-6-arnd@kernel.org
      
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Dennis Zhou <dennis@kernel.org>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Paul Moore <paul@paul-moore.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael@kernel.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Waiman Long <longman@redhat.com>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      6b76ca2a
    • Alexey Dobriyan's avatar
      add intptr_t · 3db55767
      Alexey Dobriyan authored
      Add signed intptr_t given that a) it is standard type and b) uintptr_t is
      in tree.
      
      Link: https://lkml.kernel.org/r/ed66b9e4-1fb7-45be-9bb9-d4bc291c691f@p183
      
      
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      3db55767
  2. May 22, 2023
  3. May 17, 2023
  4. May 09, 2023
  5. May 03, 2023
    • Kefeng Wang's avatar
      mm: hwpoison: coredump: support recovery from dump_user_range() · 245f0922
      Kefeng Wang authored
      dump_user_range() is used to copy the user page to a coredump file, but if
      a hardware memory error occurred during copy, which called from
      __kernel_write_iter() in dump_user_range(), it crashes,
      
        CPU: 112 PID: 7014 Comm: mca-recover Not tainted 6.3.0-rc2 #425
      
        pc : __memcpy+0x110/0x260
        lr : _copy_from_iter+0x3bc/0x4c8
        ...
        Call trace:
         __memcpy+0x110/0x260
         copy_page_from_iter+0xcc/0x130
         pipe_write+0x164/0x6d8
         __kernel_write_iter+0x9c/0x210
         dump_user_range+0xc8/0x1d8
         elf_core_dump+0x308/0x368
         do_coredump+0x2e8/0xa40
         get_signal+0x59c/0x788
         do_signal+0x118/0x1f8
         do_notify_resume+0xf0/0x280
         el0_da+0x130/0x138
         el0t_64_sync_handler+0x68/0xc0
         el0t_64_sync+0x188/0x190
      
      Generally, the '->write_iter' of file ops will use copy_page_from_iter()
      and copy_page_from_iter_atomic(), change memcpy() to copy_mc_to_kernel()
      in both of them to handle #MC during source read, which stop coredump
      processing and kill the task instead of kernel panic, but the source
      address may not always a user address, so introduce a new copy_mc flag in
      struct iov_iter{} to indicate that the iter could do a safe memory copy,
      also introduce the helpers to set/cleck the flag, for now, it's only used
      in coredump's dump_user_range(), but it could expand to any other
      scenarios to fix the similar issue.
      
      Link: https://lkml.kernel.org/r/20230417045323.11054-1-wangkefeng.wang@huawei.com
      
      
      Signed-off-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Christian Brauner <brauner@kernel.org>
      Cc: Miaohe Lin <linmiaohe@huawei.com>
      Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
      Cc: Tong Tiangen <tongtiangen@huawei.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      245f0922
  6. May 02, 2023
  7. Apr 26, 2023
  8. Apr 24, 2023
  9. Apr 21, 2023
  10. Apr 18, 2023
  11. Apr 17, 2023
  12. Apr 16, 2023
  13. Apr 15, 2023
    • Thomas Gleixner's avatar
      debugobject: Prevent init race with static objects · 63a75969
      Thomas Gleixner authored
      
      Statically initialized objects are usually not initialized via the init()
      function of the subsystem. They are special cased and the subsystem
      provides a function to validate whether an object which is not yet tracked
      by debugobjects is statically initialized. This means the object is started
      to be tracked on first use, e.g. activation.
      
      This works perfectly fine, unless there are two concurrent operations on
      that object. Schspa decoded the problem:
      
      T0 	          	    	    T1
      
      debug_object_assert_init(addr)
        lock_hash_bucket()
        obj = lookup_object(addr);
        if (!obj) {
        	unlock_hash_bucket();
      	- > preemption
      			            lock_subsytem_object(addr);
      				      activate_object(addr)
      				      lock_hash_bucket();
      				      obj = lookup_object(addr);
      				      if (!obj) {
      				    	unlock_hash_bucket();
      					if (is_static_object(addr))
      					   init_and_track(addr);
      				      lock_hash_bucket();
      				      obj = lookup_object(addr);
      				      obj->state = ACTIVATED;
      				      unlock_hash_bucket();
      
      				    subsys function modifies content of addr,
      				    so static object detection does
      				    not longer work.
      
      				    unlock_subsytem_object(addr);
      				    
              if (is_static_object(addr)) <- Fails
      
      	  debugobject emits a warning and invokes the fixup function which
      	  reinitializes the already active object in the worst case.
      
      This race exists forever, but was never observed until mod_timer() got a
      debug_object_assert_init() added which is outside of the timer base lock
      held section right at the beginning of the function to cover the lockless
      early exit points too.
      
      Rework the code so that the lookup, the static object check and the
      tracking object association happens atomically under the hash bucket
      lock. This prevents the issue completely as all callers are serialized on
      the hash bucket lock and therefore cannot observe inconsistent state.
      
      Fixes: 3ac7fe5a ("infrastructure to debug (dynamic) objects")
      Reported-by: default avatar <syzbot+5093ba19745994288b53@syzkaller.appspotmail.com>
      Debugged-by: default avatarSchspa Shi <schspa@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarStephen Boyd <swboyd@chromium.org>
      Link: https://syzkaller.appspot.com/bug?id=22c8a5938eab640d1c6bcc0e3dc7be519d878462
      Link: https://lore.kernel.org/lkml/20230303161906.831686-1-schspa@gmail.com
      Link: https://lore.kernel.org/r/87zg7dzgao.ffs@tglx
      63a75969
  14. Apr 13, 2023
  15. Apr 12, 2023
  16. Apr 08, 2023
  17. Apr 06, 2023
Loading