Files
android_kernel_xiaomi_sm8450/include/linux
Miaohe Lin fe03ccc3ce hugetlb_cgroup: fix imbalanced css_get and css_put pair for shared mappings
commit d85aecf2844ff02a0e5f077252b2461d4f10c9f0 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: 075a61d07a ("hugetlb_cgroup: add accounting for shared mappings")
Reported-by: kernel test robot <lkp@intel.com> (auto build test ERROR)
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike 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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-30 14:31:54 +02:00
..
2020-06-25 22:25:13 -07:00
2020-06-16 14:19:57 +02:00
2020-10-28 13:18:56 +01:00
2020-07-21 08:24:52 -05:00
2020-07-08 10:48:35 -07:00
2020-10-02 14:59:25 -07:00
2020-09-21 15:00:40 -07:00
2020-10-02 15:00:49 -07:00
2020-10-16 17:21:51 +02:00
2020-06-16 19:25:20 +02:00
2020-12-11 14:02:14 -08:00
2020-08-12 20:42:08 +02:00
2020-06-17 00:07:38 +02:00
2020-12-26 16:02:43 +01:00
2020-09-30 22:44:26 +02:00
2020-07-24 17:12:41 -07:00
2020-08-04 21:02:38 -04:00
2020-09-16 08:54:53 -05:00
2020-08-26 12:41:56 +02:00
2020-11-19 22:38:29 -05:00
2020-10-13 18:38:32 -07:00
2021-03-04 11:37:59 +01:00
2020-09-04 09:25:20 -07:00
2021-02-07 15:37:17 +01:00
2020-09-23 18:02:49 -07:00
2021-03-30 14:31:52 +02:00
2020-09-04 12:46:07 +01:00
2020-08-27 16:06:47 -04:00
2020-10-07 14:28:39 -04:00
2020-07-01 10:49:02 +02:00
2020-09-24 19:49:36 -07:00
2020-07-23 17:34:18 +10:00
2020-08-31 12:52:33 -07:00
2020-10-28 11:41:15 -06:00
2020-10-18 09:27:10 -07:00
2020-08-18 17:06:15 +02:00
2020-11-06 10:05:18 -08:00
2020-08-07 11:33:24 -07:00
2020-09-26 22:55:05 -04:00
2021-03-07 12:34:15 +01:00
2020-07-04 09:35:36 -05:00
2020-09-10 14:03:31 -07:00
2020-07-07 11:58:59 -05:00
2020-08-01 11:28:17 +02:00
2020-10-05 13:21:49 +02:00