1. 14 11月, 2021 1 次提交
  2. 07 11月, 2021 5 次提交
  3. 29 10月, 2021 2 次提交
    • Y
      mm: filemap: check if THP has hwpoisoned subpage for PMD page fault · eac96c3e
      Yang Shi 提交于
      When handling shmem page fault the THP with corrupted subpage could be
      PMD mapped if certain conditions are satisfied.  But kernel is supposed
      to send SIGBUS when trying to map hwpoisoned page.
      
      There are two paths which may do PMD map: fault around and regular
      fault.
      
      Before commit f9ce0be7 ("mm: Cleanup faultaround and finish_fault()
      codepaths") the thing was even worse in fault around path.  The THP
      could be PMD mapped as long as the VMA fits regardless what subpage is
      accessed and corrupted.  After this commit as long as head page is not
      corrupted the THP could be PMD mapped.
      
      In the regular fault path the THP could be PMD mapped as long as the
      corrupted page is not accessed and the VMA fits.
      
      This loophole could be fixed by iterating every subpage to check if any
      of them is hwpoisoned or not, but it is somewhat costly in page fault
      path.
      
      So introduce a new page flag called HasHWPoisoned on the first tail
      page.  It indicates the THP has hwpoisoned subpage(s).  It is set if any
      subpage of THP is found hwpoisoned by memory failure and after the
      refcount is bumped successfully, then cleared when the THP is freed or
      split.
      
      The soft offline path doesn't need this since soft offline handler just
      marks a subpage hwpoisoned when the subpage is migrated successfully.
      But shmem THP didn't get split then migrated at all.
      
      Link: https://lkml.kernel.org/r/20211020210755.23964-3-shy828301@gmail.com
      Fixes: 800d8c63 ("shmem: add huge pages support")
      Signed-off-by: NYang Shi <shy828301@gmail.com>
      Reviewed-by: NNaoya Horiguchi <naoya.horiguchi@nec.com>
      Suggested-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: Peter Xu <peterx@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      eac96c3e
    • Y
      mm: hwpoison: remove the unnecessary THP check · c7cb42e9
      Yang Shi 提交于
      When handling THP hwpoison checked if the THP is in allocation or free
      stage since hwpoison may mistreat it as hugetlb page.  After commit
      415c64c1 ("mm/memory-failure: split thp earlier in memory error
      handling") the problem has been fixed, so this check is no longer
      needed.  Remove it.  The side effect of the removal is hwpoison may
      report unsplit THP instead of unknown error for shmem THP.  It seems not
      like a big deal.
      
      The following patch "mm: filemap: check if THP has hwpoisoned subpage
      for PMD page fault" depends on this, which fixes shmem THP with
      hwpoisoned subpage(s) are mapped PMD wrongly.  So this patch needs to be
      backported to -stable as well.
      
      Link: https://lkml.kernel.org/r/20211020210755.23964-2-shy828301@gmail.comSigned-off-by: NYang Shi <shy828301@gmail.com>
      Suggested-by: NNaoya Horiguchi <naoya.horiguchi@nec.com>
      Acked-by: NNaoya Horiguchi <naoya.horiguchi@nec.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: Peter Xu <peterx@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c7cb42e9
  4. 27 10月, 2021 1 次提交
  5. 27 9月, 2021 1 次提交
  6. 25 9月, 2021 2 次提交
  7. 04 9月, 2021 8 次提交
  8. 21 8月, 2021 1 次提交
  9. 13 7月, 2021 1 次提交
  10. 02 7月, 2021 1 次提交
  11. 01 7月, 2021 3 次提交
  12. 30 6月, 2021 2 次提交
  13. 25 6月, 2021 3 次提交
  14. 17 6月, 2021 2 次提交
    • Y
      mm/memory-failure: make sure wait for page writeback in memory_failure · e8675d29
      yangerkun 提交于
      Our syzkaller trigger the "BUG_ON(!list_empty(&inode->i_wb_list))" in
      clear_inode:
      
        kernel BUG at fs/inode.c:519!
        Internal error: Oops - BUG: 0 [#1] SMP
        Modules linked in:
        Process syz-executor.0 (pid: 249, stack limit = 0x00000000a12409d7)
        CPU: 1 PID: 249 Comm: syz-executor.0 Not tainted 4.19.95
        Hardware name: linux,dummy-virt (DT)
        pstate: 80000005 (Nzcv daif -PAN -UAO)
        pc : clear_inode+0x280/0x2a8
        lr : clear_inode+0x280/0x2a8
        Call trace:
          clear_inode+0x280/0x2a8
          ext4_clear_inode+0x38/0xe8
          ext4_free_inode+0x130/0xc68
          ext4_evict_inode+0xb20/0xcb8
          evict+0x1a8/0x3c0
          iput+0x344/0x460
          do_unlinkat+0x260/0x410
          __arm64_sys_unlinkat+0x6c/0xc0
          el0_svc_common+0xdc/0x3b0
          el0_svc_handler+0xf8/0x160
          el0_svc+0x10/0x218
        Kernel panic - not syncing: Fatal exception
      
      A crash dump of this problem show that someone called __munlock_pagevec
      to clear page LRU without lock_page: do_mmap -> mmap_region -> do_munmap
      -> munlock_vma_pages_range -> __munlock_pagevec.
      
      As a result memory_failure will call identify_page_state without
      wait_on_page_writeback.  And after truncate_error_page clear the mapping
      of this page.  end_page_writeback won't call sb_clear_inode_writeback to
      clear inode->i_wb_list.  That will trigger BUG_ON in clear_inode!
      
      Fix it by checking PageWriteback too to help determine should we skip
      wait_on_page_writeback.
      
      Link: https://lkml.kernel.org/r/20210604084705.3729204-1-yangerkun@huawei.com
      Fixes: 0bc1f8b0 ("hwpoison: fix the handling path of the victimized page frame that belong to non-LRU")
      Signed-off-by: Nyangerkun <yangerkun@huawei.com>
      Acked-by: NNaoya Horiguchi <naoya.horiguchi@nec.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: Yu Kuai <yukuai3@huawei.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8675d29
    • N
      mm,hwpoison: fix race with hugetlb page allocation · 25182f05
      Naoya Horiguchi 提交于
      When hugetlb page fault (under overcommitting situation) and
      memory_failure() race, VM_BUG_ON_PAGE() is triggered by the following
      race:
      
          CPU0:                           CPU1:
      
                                          gather_surplus_pages()
                                            page = alloc_surplus_huge_page()
          memory_failure_hugetlb()
            get_hwpoison_page(page)
              __get_hwpoison_page(page)
                get_page_unless_zero(page)
                                            zero = put_page_testzero(page)
                                            VM_BUG_ON_PAGE(!zero, page)
                                            enqueue_huge_page(h, page)
            put_page(page)
      
      __get_hwpoison_page() only checks the page refcount before taking an
      additional one for memory error handling, which is not enough because
      there's a time window where compound pages have non-zero refcount during
      hugetlb page initialization.
      
      So make __get_hwpoison_page() check page status a bit more for hugetlb
      pages with get_hwpoison_huge_page().  Checking hugetlb-specific flags
      under hugetlb_lock makes sure that the hugetlb page is not transitive.
      It's notable that another new function, HWPoisonHandlable(), is helpful
      to prevent a race against other transitive page states (like a generic
      compound page just before PageHuge becomes true).
      
      Link: https://lkml.kernel.org/r/20210603233632.2964832-2-nao.horiguchi@gmail.com
      Fixes: ead07f6a ("mm/memory-failure: introduce get_hwpoison_page() for consistent refcount handling")
      Signed-off-by: NNaoya Horiguchi <naoya.horiguchi@nec.com>
      Reported-by: NMuchun Song <songmuchun@bytedance.com>
      Acked-by: NMike Kravetz <mike.kravetz@oracle.com>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: <stable@vger.kernel.org>	[5.12+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      25182f05
  15. 07 5月, 2021 1 次提交
  16. 01 5月, 2021 1 次提交
  17. 27 2月, 2021 1 次提交
  18. 25 2月, 2021 1 次提交
  19. 25 1月, 2021 1 次提交
  20. 13 1月, 2021 1 次提交
  21. 16 12月, 2020 1 次提交