From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x225kkUo2S3f/fPENvtITNhG9kL6wl808KSGTdWY9rXKifxJrDOYB81m/Vfm9qUWWkzSQkt3l ARC-Seal: i=1; a=rsa-sha256; t=1517674476; cv=none; d=google.com; s=arc-20160816; b=A8h7cVqNyJC/6+IYg64pjFztD99JM4rQYUhF8IrR220yS8FMC8C1nza9yXBn828nt1 Y5rWPTA0fR+KqHo00MB7eK1it0DAeWhOiXNbsMjvOwwvzEM2y/xm9jZHoFDKpBKoWtXU Jv9fdBhUiNp7lkNYXNdSe7c+2mP6w+kvRXspBz+No/xeAwQ6pmfDezwBDx5feRQkA7nz PV+fCEZhsKuRQ5nVDMet69hh/WkxVAs+Of4lC8B1esBbAWAx1Kium0HfF1BvrU3h3blP 1mwDSlUuGBEByFeq2jGmtWII5LwZeq/bCOBAGl0VEV6JxMY6Wmq76dVwOpYvFju+/SaA uyBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :delivered-to:list-id:list-subscribe:list-unsubscribe:list-help :list-post:precedence:mailing-list:arc-authentication-results; bh=h7opQsocjQ7g9BoiHyxfpa+eBJT4UhnU2JxOaCXJT48=; b=B27GsZAxO6hMOhdqQMnvMANWU/eae4GIJmMCUY/3h0LKS1lMYLpSEC1MFDhGsW9FFw yStxYFImHYODnCYDo0MjhiQTOhmsqEHLqaE6xwp7nFUjk71qGCZn1jpTD+bSku8mrW5w aOzNH+FW2QbGcl/HRe7DUwXTU5MvHmZJfxGyv8FA2car/2tJCsqNl+j/OLWnaGxzYv7D hK0VcZ4HcwHhpRKDHifQPgUERUScqkYGRLdTk4CL23gr506QUcjqr8Z+LzBmAGZMHclB +zaxadii/PSxsmCE2ipRYrVhEPFnu9ROsZgIkek7KGzAuAdxjxOvGQT0KS8Fb6D/Twx+ vM4g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11561-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11561-gregkh=linuxfoundation.org@lists.openwall.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11561-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11561-gregkh=linuxfoundation.org@lists.openwall.com Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: Subject: Re: [PATCH 3/6] struct page: add field for vm_struct To: Christopher Lameter CC: , , , , , , , , , References: <20180130151446.24698-1-igor.stoppa@huawei.com> <20180130151446.24698-4-igor.stoppa@huawei.com> <48fde114-d063-cfbf-e1b6-262411fcd963@huawei.com> From: Igor Stoppa Message-ID: Date: Sat, 3 Feb 2018 18:13:58 +0200 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: 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-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1591031026595146297?= X-GMAIL-MSGID: =?utf-8?q?1591397031774210421?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 02/02/18 20:43, Christopher Lameter wrote: > On Thu, 1 Feb 2018, Igor Stoppa wrote: > >>> Would it not be better to use compound page allocations here? [...] > Ok its compound_head(). See also the use in the SLAB and SLUB allocator. > >> During hardened user copy permission check, I need to confirm if the >> memory range that would be exposed to userspace is a legitimate >> sub-range of a pmalloc allocation. > > If you save the size in the head page struct then you could do that pretty > fast. Ok, now I get what you mean. But it doesn't seem to fit the intended use case, for other reasons (maybe the same, from 2 different POV): - compound pages are aggregates of regular pages, in numbers that are powers of 2, while the amount of pages to allocate is not known upfront. One *could* give a hint to pmalloc about how many pages to allocate every time there is a need to grow the pool. Iow it would be the size of a chunk. But I'm afraid the granularity would still be pretty low, so maybe it would be 2-4 times less. - the property of the compound page will affect the property of all the pages in the compound, so when one is write protected, it can generate a lot of wasted memory, if there is too much slack (because of the order) With vmalloc, I can allocate any number of pages, minimizing the waste. Finally, there was a discussion about optimization: http://www.openwall.com/lists/kernel-hardening/2017/08/07/2 The patch I sent does indeed take advantage of the new information, not just for pmalloc use. I have not measured if/where/what there is gain, but it does look like the extra info can be exploited also elsewhere. -- igor