linux-kernel - Re: [PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

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:   Tue, 18 Apr 2017 08:59:46 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Hoeun Ryu <hoeun.ryu@...il.com>
Cc:     hch@...radead.org, khandual@...ux.vnet.ibm.com,
        Andrew Morton <akpm@...ux-foundation.org>,
        Roman Pen <r.peniaev@...il.com>,
        Andreas Dilger <adilger@...ger.ca>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Chris Wilson <chris@...is-wilson.co.uk>,
        Ingo Molnar <mingo@...nel.org>, zijun_hu <zijun_hu@....com>,
        Matthew Wilcox <mawilcox@...rosoft.com>,
        Thomas Garnier <thgarnie@...gle.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        linux-arch@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from
 removing the areas

On Tue 18-04-17 14:48:39, Hoeun Ryu wrote:
>  vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area
> during boot process and those virtually mapped areas are never unmapped.
> So `OR` VM_STATIC flag to the areas in vmalloc_init() when importing
> existing vmlist entries and prevent those areas from being removed from the
> rbtree by accident.

Has this been a problem in the past or currently so that it is worth
handling?

> This flags can be also used by other vmalloc APIs to
> specify that the area will never go away.

Do we have a user for that?

> This makes remove_vm_area() more robust against other kind of errors (eg.
> programming errors).

Well, yes it will help to prevent from vfree(early_mem) but we have 4
users of vm_area_register_early so I am really wondering whether this is
worth additional code. It would really help to understand your
motivation for the patch if we were explicit about the problem you are
trying to solve.

Thanks

-- 
Michal Hocko
SUSE Labs