Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755379AbdDMBD1 (ORCPT ); Wed, 12 Apr 2017 21:03:27 -0400 Received: from mail-pg0-f68.google.com ([74.125.83.68]:33741 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752134AbdDMBDW (ORCPT ); Wed, 12 Apr 2017 21:03:22 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas From: Ho-Eun Ryu In-Reply-To: <20170412173151.GA23054@infradead.org> Date: Thu, 13 Apr 2017 10:03:14 +0900 Cc: Andrew Morton , Andrey Ryabinin , Andreas Dilger , Vlastimil Babka , Michal Hocko , Chris Wilson , Ingo Molnar , zijun_hu , Matthew Wilcox , Thomas Garnier , "Kirill A. Shutemov" , linux-arch@vger.kernel.org, linux-mm@kvack.org, LKML Message-Id: <3F99A1DC-3DEF-4EEB-AD6E-7848D7A6049D@gmail.com> References: <1491973350-26816-1-git-send-email-hoeun.ryu@gmail.com> <20170412060218.GA16170@infradead.org> <20170412173151.GA23054@infradead.org> To: Christoph Hellwig X-Mailer: Apple Mail (2.3273) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v3D13aIV022617 Content-Length: 933 Lines: 24 > On 13 Apr 2017, at 2:31 AM, Christoph Hellwig wrote: > > On Wed, Apr 12, 2017 at 08:42:08PM +0900, Hoeun Ryu wrote: >> >>> On Apr 12, 2017, at 3:02 PM, Christoph Hellwig wrote: >>> >>>> On Wed, Apr 12, 2017 at 02:01:59PM +0900, 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. >>> >>> How would they be removed "by accident"? >> >> I don't mean actual use-cases, but I just want to make it robust against like programming errors. > > Oh, ok. The patch makes sense then, although the changelog could use > a little update. OK, I will. Any other suggestions for code itself ?