1. 30 12月, 2021 2 次提交
  2. 10 12月, 2021 1 次提交
  3. 03 12月, 2021 1 次提交
  4. 30 11月, 2021 1 次提交
  5. 29 11月, 2021 1 次提交
  6. 21 10月, 2021 1 次提交
  7. 13 10月, 2021 3 次提交
  8. 12 10月, 2021 2 次提交
  9. 29 9月, 2021 2 次提交
  10. 14 7月, 2021 16 次提交
  11. 15 6月, 2021 1 次提交
    • M
      mm, hugetlb: fix simple resv_huge_pages underflow on UFFDIO_COPY · 82ac4173
      Mina Almasry 提交于
      stable inclusion
      from stable-5.10.43
      commit 2eb4ec9c2c3535b9755c484183cc5c4d90fd37ff
      bugzilla: 109284
      CVE: NA
      
      --------------------------------
      
      [ Upstream commit d84cf06e ]
      
      The userfaultfd hugetlb tests cause a resv_huge_pages underflow.  This
      happens when hugetlb_mcopy_atomic_pte() is called with !is_continue on
      an index for which we already have a page in the cache.  When this
      happens, we allocate a second page, double consuming the reservation,
      and then fail to insert the page into the cache and return -EEXIST.
      
      To fix this, we first check if there is a page in the cache which
      already consumed the reservation, and return -EEXIST immediately if so.
      
      There is still a rare condition where we fail to copy the page contents
      AND race with a call for hugetlb_no_page() for this index and again we
      will underflow resv_huge_pages.  That is fixed in a more complicated
      patch not targeted for -stable.
      
      Test:
      
        Hacked the code locally such that resv_huge_pages underflows produce a
        warning, then:
      
        ./tools/testing/selftests/vm/userfaultfd hugetlb_shared 10
      	2 /tmp/kokonut_test/huge/userfaultfd_test && echo test success
        ./tools/testing/selftests/vm/userfaultfd hugetlb 10
      	2 /tmp/kokonut_test/huge/userfaultfd_test && echo test success
      
      Both tests succeed and produce no warnings.  After the test runs number
      of free/resv hugepages is correct.
      
      [mike.kravetz@oracle.com: changelog fixes]
      
      Link: https://lkml.kernel.org/r/20210528004649.85298-1-almasrymina@google.com
      Fixes: 8fb5debc ("userfaultfd: hugetlbfs: add hugetlb_mcopy_atomic_pte for userfaultfd support")
      Signed-off-by: NMina Almasry <almasrymina@google.com>
      Reviewed-by: NMike Kravetz <mike.kravetz@oracle.com>
      Cc: Axel Rasmussen <axelrasmussen@google.com>
      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>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      82ac4173
  12. 03 6月, 2021 1 次提交
  13. 19 4月, 2021 1 次提交
    • M
      hugetlb_cgroup: fix imbalanced css_get and css_put pair for shared mappings · c329e216
      Miaohe Lin 提交于
      stable inclusion
      from stable-5.10.27
      commit fe03ccc3ce906a31005637263fb82dd84d5d1dac
      bugzilla: 51493
      
      --------------------------------
      
      commit d85aecf2 upstream.
      
      The current implementation of hugetlb_cgroup for shared mappings could
      have different behavior.  Consider the following two scenarios:
      
       1.Assume initial css reference count of hugetlb_cgroup is 1:
        1.1 Call hugetlb_reserve_pages with from = 1, to = 2. So css reference
            count is 2 associated with 1 file_region.
        1.2 Call hugetlb_reserve_pages with from = 2, to = 3. So css reference
            count is 3 associated with 2 file_region.
        1.3 coalesce_file_region will coalesce these two file_regions into
            one. So css reference count is 3 associated with 1 file_region
            now.
      
       2.Assume initial css reference count of hugetlb_cgroup is 1 again:
        2.1 Call hugetlb_reserve_pages with from = 1, to = 3. So css reference
            count is 2 associated with 1 file_region.
      
      Therefore, we might have one file_region while holding one or more css
      reference counts. This inconsistency could lead to imbalanced css_get()
      and css_put() pair. If we do css_put one by one (i.g. hole punch case),
      scenario 2 would put one more css reference. If we do css_put all
      together (i.g. truncate case), scenario 1 will leak one css reference.
      
      The imbalanced css_get() and css_put() pair would result in a non-zero
      reference when we try to destroy the hugetlb cgroup. The hugetlb cgroup
      directory is removed __but__ associated resource is not freed. This
      might result in OOM or can not create a new hugetlb cgroup in a busy
      workload ultimately.
      
      In order to fix this, we have to make sure that one file_region must
      hold exactly one css reference. So in coalesce_file_region case, we
      should release one css reference before coalescence. Also only put css
      reference when the entire file_region is removed.
      
      The last thing to note is that the caller of region_add() will only hold
      one reference to h_cg->css for the whole contiguous reservation region.
      But this area might be scattered when there are already some
      file_regions reside in it. As a result, many file_regions may share only
      one h_cg->css reference. In order to ensure that one file_region must
      hold exactly one css reference, we should do css_get() for each
      file_region and release the reference held by caller when they are done.
      
      [linmiaohe@huawei.com: fix imbalanced css_get and css_put pair for shared mappings]
        Link: https://lkml.kernel.org/r/20210316023002.53921-1-linmiaohe@huawei.com
      
      Link: https://lkml.kernel.org/r/20210301120540.37076-1-linmiaohe@huawei.com
      Fixes: 075a61d0 ("hugetlb_cgroup: add accounting for shared mappings")
      Reported-by: kernel test robot <lkp@intel.com> (auto build test ERROR)
      Signed-off-by: NMiaohe Lin <linmiaohe@huawei.com>
      Reviewed-by: NMike Kravetz <mike.kravetz@oracle.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Wanpeng Li <liwp.linux@gmail.com>
      Cc: Mina Almasry <almasrymina@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Acked-by: N  Weilong Chen <chenweilong@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      c329e216
  14. 09 4月, 2021 4 次提交
  15. 09 3月, 2021 3 次提交