Skip to content
Snippets Groups Projects
  1. Jun 10, 2023
  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