Skip to content
Snippets Groups Projects
  1. Oct 03, 2022
  2. Sep 11, 2022
  3. Aug 02, 2022
  4. Jul 04, 2022
  5. Jun 29, 2022
  6. May 27, 2022
  7. May 19, 2022
  8. May 13, 2022
  9. May 10, 2022
  10. Mar 17, 2022
    • Guo Ziliang's avatar
      mm: swap: get rid of livelock in swapin readahead · 029c4628
      Guo Ziliang authored
      In our testing, a livelock task was found.  Through sysrq printing, same
      stack was found every time, as follows:
      
        __swap_duplicate+0x58/0x1a0
        swapcache_prepare+0x24/0x30
        __read_swap_cache_async+0xac/0x220
        read_swap_cache_async+0x58/0xa0
        swapin_readahead+0x24c/0x628
        do_swap_page+0x374/0x8a0
        __handle_mm_fault+0x598/0xd60
        handle_mm_fault+0x114/0x200
        do_page_fault+0x148/0x4d0
        do_translation_fault+0xb0/0xd4
        do_mem_abort+0x50/0xb0
      
      The reason for the livelock is that swapcache_prepare() always returns
      EEXIST, indicating that SWAP_HAS_CACHE has not been cleared, so that it
      cannot jump out of the loop.  We suspect that the task that clears the
      SWAP_HAS_CACHE flag never gets a chance to run.  We try to lower the
      priority of the task stuck in a livelock so that the task that clears
      the SWAP_HAS_CACHE flag will run.  The results show that the system
      returns to normal after the priority is lowered.
      
      In our testing, multiple real-time tasks are bound to the same core, and
      the task in the livelock is the highest priority task of the core, so
      the livelocked task cannot be preempted.
      
      Although cond_resched() is used by __read_swap_cache_async, it is an
      empty function in the preemptive system and cannot achieve the purpose
      of releasing the CPU.  A high-priority task cannot release the CPU
      unless preempted by a higher-priority task.  But when this task is
      already the highest priority task on this core, other tasks will not be
      able to be scheduled.  So we think we should replace cond_resched() with
      schedule_timeout_uninterruptible(1), schedule_timeout_interruptible will
      call set_current_state first to set the task state, so the task will be
      removed from the running queue, so as to achieve the purpose of giving
      up the CPU and prevent it from running in kernel mode for too long.
      
      (akpm: ugly hack becomes uglier.  But it fixes the issue in a
      backportable-to-stable fashion while we hopefully work on something
      better)
      
      Link: https://lkml.kernel.org/r/20220221111749.1928222-1-cgel.zte@gmail.com
      
      
      Signed-off-by: default avatarGuo Ziliang <guo.ziliang@zte.com.cn>
      Reported-by: default avatarZeal Robot <zealci@zte.com.cn>
      Reviewed-by: default avatarRan Xiaokai <ran.xiaokai@zte.com.cn>
      Reviewed-by: default avatarJiang Xuexin <jiang.xuexin@zte.com.cn>
      Reviewed-by: default avatarYang Yang <yang.yang29@zte.com.cn>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Roger Quadros <rogerq@kernel.org>
      Cc: Ziliang Guo <guo.ziliang@zte.com.cn>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      029c4628
  11. Mar 15, 2022
  12. Oct 18, 2021
  13. Aug 20, 2021
  14. Jun 29, 2021
  15. May 07, 2021
  16. May 05, 2021
  17. Apr 30, 2021
  18. Feb 26, 2021
  19. Feb 24, 2021
  20. Dec 15, 2020
Loading