From mboxrd@z Thu Jan 1 00:00:00 1970 From: igor.stoppa@huawei.com (Igor Stoppa) Date: Fri, 4 Aug 2017 11:02:46 +0300 Subject: [RFC] Tagging of vmalloc pages for supporting the pmalloc allocator In-Reply-To: <20170803151550.GX12521@dhcp22.suse.cz> References: <07063abd-2f5d-20d9-a182-8ae9ead26c3c@huawei.com> <20170802170848.GA3240@redhat.com> <8e82639c-40db-02ce-096a-d114b0436d3c@huawei.com> <20170803114844.GO12521@dhcp22.suse.cz> <20170803135549.GW12521@dhcp22.suse.cz> <20170803144746.GA9501@redhat.com> <20170803151550.GX12521@dhcp22.suse.cz> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.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 -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html