linux-kernel - Re: [PATCH v11 6/9] hugetlb_cgroup: support noreserve mappings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ac89801a-1285-78df-9baf-3404054b89cb@oracle.com>
Date:   Fri, 7 Feb 2020 10:16:43 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Mina Almasry <almasrymina@...gle.com>
Cc:     shuah@...nel.org, rientjes@...gle.com, shakeelb@...gle.com,
        gthelen@...gle.com, akpm@...ux-foundation.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-kselftest@...r.kernel.org, cgroups@...r.kernel.org
Subject: Re: [PATCH v11 6/9] hugetlb_cgroup: support noreserve mappings

On 2/6/20 2:31 PM, Mike Kravetz wrote:
> On 2/3/20 3:22 PM, Mina Almasry wrote:
>> Support MAP_NORESERVE accounting as part of the new counter.
>>
>> For each hugepage allocation, at allocation time we check if there is
>> a reservation for this allocation or not. If there is a reservation for
>> this allocation, then this allocation was charged at reservation time,
>> and we don't re-account it. If there is no reserevation for this
>> allocation, we charge the appropriate hugetlb_cgroup.
>>
>> The hugetlb_cgroup to uncharge for this allocation is stored in
>> page[3].private. We use new APIs added in an earlier patch to set this
>> pointer.
> 
> Ah!  That reminded me to look at the migration code.  Turns out that none
> of the existing cgroup information (page[2]) is being migrated today.  That
> is a bug. :(  I'll confirm and fix in a patch separate from this series.
> We will need to make sure that new information added by this series in page[3]
> is also migrated.  That would be in an earlier patch where the use of the
> field is introduced.

My appologies!

cgroup information is migrated and you took care of it for new reservation
information in patch 2.  Please disregard that statement.

-- 
Mike Kravetz