From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752095AbdHDIEY (ORCPT <rfc822;w@1wt.eu>);
        Fri, 4 Aug 2017 04:04:24 -0400
Received: from lhrrgout.huawei.com ([194.213.3.17]:32717 "EHLO
        lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751278AbdHDIES (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 4 Aug 2017 04:04:18 -0400
Subject: Re: [RFC] Tagging of vmalloc pages for supporting the pmalloc
 allocator
To: Michal Hocko <mhocko@kernel.org>
CC: Jerome Glisse <jglisse@redhat.com>, Linux-MM <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>,
        <linux-security-module@vger.kernel.org>,
        "kernel-hardening@lists.openwall.com" 
        <kernel-hardening@lists.openwall.com>,
        Kees Cook <keescook@google.com>
References: <07063abd-2f5d-20d9-a182-8ae9ead26c3c@huawei.com>
 <20170802170848.GA3240@redhat.com>
 <8e82639c-40db-02ce-096a-d114b0436d3c@huawei.com>
 <20170803114844.GO12521@dhcp22.suse.cz>
 <c3a250a6-ad4d-d24d-d0bf-4c43c467ebe6@huawei.com>
 <20170803135549.GW12521@dhcp22.suse.cz> <20170803144746.GA9501@redhat.com>
 <ab4809cd-0efc-a79d-6852-4bd2349a2b3f@huawei.com>
 <20170803151550.GX12521@dhcp22.suse.cz>
From: Igor Stoppa <igor.stoppa@huawei.com>
Message-ID: <abe0c086-8c5a-d6fb-63c4-bf75528d0ec5@huawei.com>
Date: Fri, 4 Aug 2017 11:02:46 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170803151550.GX12521@dhcp22.suse.cz>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.122.225.51]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
        refid=str=0001.0A090205.59842A65.0112,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0,
        ip=0.0.0.0,
        so=2013-06-18 04:22:30,
        dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 5acb2892ebed374a65cb7f75df5c6bb5
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org



On 03/08/17 18:15, Michal Hocko wrote:

> I would check the one where we have mapping. It is rather unlikely
> vmalloc users would touch this one.

That was also the initial recommendation from Jerome Glisse, but it
seemed unusable, because of the related comment.

I should have asked for clarifications back then :-(

But it's never too late ...


struct page {
  /* First double word block */
  unsigned long flags;		/* Atomic flags, some possibly
				 * updated asynchronously */
union {
	struct address_space *mapping;	/* If low bit clear, points to
					 * inode address_space, or NULL.
					 * If page mapped as anonymous
					 * memory, low bit is set, and
					 * it points to anon_vma object:
					 * see PAGE_MAPPING_ANON below.
					 */
...
}

mapping seems to be used exclusively in 2 ways, based on the value of
its lower bit.

Therefore I discarded it as valid option ("private", otoh was far more
alluring), but maybe I could wrap it inside a union, together with vm_area?

---
thanks, igor