linux-kernel - Re: [RFC PATCH v3 1/6] [PATCH 1/6] mm: refactor of vma

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]

Date:   Fri, 20 May 2022 17:52:56 +0200
From:   Jakub Matěna <matenajakub@...il.com>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     linux-mm@...ck.org, patches@...ts.linux.dev,
        linux-kernel@...r.kernel.org, Vlastimil Babka <vbabka@...e.cz>,
        mhocko@...nel.org, mgorman@...hsingularity.net,
        willy@...radead.org, Liam Howlett <liam.howlett@...cle.com>,
        Hugh Dickins <hughd@...gle.com>, riel@...riel.com,
        rostedt@...dmis.org, peterz@...radead.org, david@...hat.com
Subject: Re: [RFC PATCH v3 1/6] [PATCH 1/6] mm: refactor of vma_merge()

On Fri, May 20, 2022 at 3:26 PM Kirill A. Shutemov <kirill@...temov.name> wrote:
>
> On Mon, May 16, 2022 at 02:54:00PM +0200, Jakub Matěna wrote:
> > Refactor vma_merge() to make it shorter, more understandable and
> > suitable for tracing of successful merges that are made possible by
> > following patches in the series. Main change is the elimination of code
> > duplicity in the case of merge next check. This is done by first doing
> > checks and caching the results before executing the merge itself. Exit
> > paths are also unified.
> >
> > Signed-off-by: Jakub Matěna <matenajakub@...il.com>
>
> Okay, this looks good:
>
> Acked-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
>
> I would also consider renaming 'area' to 'vma'. 'area' feels wrong to me,
> but maybe it is only me.

Well, the 'area' is taken from the original code and the name is not
the only thing wrong about it. It is actually used for two purposes,
which is definitely wrong. First purpose is to store the middle VMA
between prev and next for the use of case 8. And the second purpose is
to store the resulting VMA which is passed to
khugepaged_enter_vma_merge() and also the return value of vma_merge().
So, to me it seems that the best approach is to split it into two
variables 'mid' for the first purpose and 'res' for the second one.

>
> --
>  Kirill A. Shutemov