[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170418065946.GB22360@dhcp22.suse.cz>
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
Powered by blists - more mailing lists