[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d20d5dbe-74cd-fe90-8e43-ebbc5a3b4403@gmail.com>
Date: Thu, 11 Mar 2021 08:44:22 +1100
From: "Singh, Balbir" <bsingharora@...il.com>
To: Michal Hocko <mhocko@...e.com>
Cc: Zhou Guanghui <zhouguanghui1@...wei.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
akpm@...ux-foundation.org, hannes@...xchg.org, hughd@...gle.com,
kirill.shutemov@...ux.intel.com, npiggin@...il.com, ziy@...dia.com,
wangkefeng.wang@...wei.com, guohanjun@...wei.com,
dingtianhong@...wei.com, chenweilong@...wei.com,
rui.xiang@...wei.com
Subject: Re: [PATCH v2 1/2] mm/memcg: rename mem_cgroup_split_huge_fixup to
split_page_memcg
On 9/3/21 7:28 pm, Michal Hocko wrote:
> On Tue 09-03-21 09:37:29, Balbir Singh wrote:
>> On 4/3/21 6:40 pm, Zhou Guanghui wrote:
> [...]
>>> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>> /*
>>> - * Because page_memcg(head) is not set on compound tails, set it now.
>>> + * Because page_memcg(head) is not set on tails, set it now.
>>> */
>>> -void mem_cgroup_split_huge_fixup(struct page *head)
>>> +void split_page_memcg(struct page *head, unsigned int nr)
>>> {
>>
>> Do we need input validation on nr? Can nr be aribtrary or can we enforce
>>
>> VM_BUG_ON(!is_power_of_2(nr));
>
> In practice this will be power of 2 but why should we bother to sanitze
> that?
>
Just when DEBUG_VM is enabled to ensure the contract is valid, given that
nr is now variable, we could end up with subtle bugs unless we can audit
all callers. Even the power of 2 check does not catch the fact that nr
is indeed what we expect, but it still checks a large range of invalid
inputs.
Balbir Singh.
Powered by blists - more mailing lists