From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x224TFn6dSUEQzmoO/kWEz04PiR0SK62Bx4dzwIOOqbiB4ilJx9JLEfeLa2FuuObVO5jT1CnD ARC-Seal: i=1; a=rsa-sha256; t=1517443263; cv=none; d=google.com; s=arc-20160816; b=s0uuAzXNyYJa4iZP5F0Fom+mnSAalBXFoJ/r0WS0YpBujiPnZvjcaCMFFiyEKuwiB3 MQiHdhM8HRis5E+UZpoHTWJ7nFHnmlHyG7e53M7hlt0L1sWEUkycQfhLPagTtNs80Q06 PA5/O+nKsDxap59dDAGsLjEo8fHYLM/bvS5sZZI1p+a/mOehfZQQ/MINfaFgiMoTKHVR uwWppI5+Qz2Ums5+pbSy2w8I60gAT2n1XsE5XxLINTZikYAKDNGp+pO64qWXiLi1Scle v5zvfmIab+m5EPDRbHKlnC5M70wQBLzBQ5TO3by40W3w8je2jndKvKiWjkotf0H9Texj wU+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:delivered-to:list-id:list-subscribe :list-unsubscribe:list-help:list-post:precedence:mailing-list :arc-authentication-results; bh=YvchmSTK/ozfBeZGcr04v7tkmhobHWAK+EtEceV/z9Q=; b=HpFecdhnoJDA240hZBkE4CHIfftO/FQdaBmIfMk0jLCfEkukxPrEgboOvq8DJ6XAar PgyN6zPiHkCV21GLy9qSHikVKFvE0FOY3+YRRR4A2z5EhNQq7Qgz6HuLaKoTgB96NL6L DmXuNNYzuF/JLWv3fmjK+odoB1+Ht/W8shRcPmAgwlXtsmpYjyrXxZdQ+PT7CbC251CO aaZLYjjR+DK68ErU74IgCZAU4/KtpinXkf45VeUbk4Z+poZeCLyQc2q19r4UGxhKH35L n1+WUn1CHCslWKCfGLSIYapPczHBDWyZMEysl/CuFnd/kizq+7GN0JcPCFm8j8p0P9vm oz3A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11549-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11549-gregkh=linuxfoundation.org@lists.openwall.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11549-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11549-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: Date: Wed, 31 Jan 2018 18:00:36 -0600 (CST) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Igor Stoppa cc: jglisse@redhat.com, keescook@chromium.org, mhocko@kernel.org, labbott@redhat.com, hch@infradead.org, willy@infradead.org, linux-security-module@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com Subject: Re: [PATCH 3/6] struct page: add field for vm_struct In-Reply-To: <20180130151446.24698-4-igor.stoppa@huawei.com> Message-ID: References: <20180130151446.24698-1-igor.stoppa@huawei.com> <20180130151446.24698-4-igor.stoppa@huawei.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfPnuMWJOo2hvB5hrWtsMOwbdCP4fPB8UNMQLWxsLkKFLIUK6mjWvgcwFCSE2ZSFdkAL27b9ks/onfoyJtPouY0SEgepBOgJQ88uN/NGGjsuj5ZnMBcnK 5t0YZkiV2MR0uxTwrh6ijFwzJ9W18MfpfKY70nQ70DoEmEixbmBvK5cWl6Wlu2eFItxuhgV1rUVYPKHWHf7670ybshNMbiCYZi9164Rm4uktgf5LNvslbQ65 J6RLrzooxretcptGFvvIWzxpOy6ST/CN8djnUtyjHyrwVex5zgnohRxj5DpAa/X+W4LUfOLZyp3wJUOWnUnEtmHqe/idI/cxbt+FcoRguswxtpY+677U5CWU zYYzjEGGd5JRf2b9nvB/f04uUHDBB+k+nTCj5ZlYC1fBf7gpPSi6EU1t6jLpJlM4KpasyhwYOBi7XdO7avI4i6HPhYBOV/CUw0AZC3cG+NP3S4IaREwb+HOi dUw26feUwpTuX5Jw7aE8gsW+nnUmgUcrdVttMdELhODMOqPEFOiscR4sJlo= X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1591031026595146297?= X-GMAIL-MSGID: =?utf-8?q?1591154587332812275?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Tue, 30 Jan 2018, Igor Stoppa wrote: > @@ -1769,6 +1774,9 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align, > > kmemleak_vmalloc(area, size, gfp_mask); > > + for (page_counter = 0; page_counter < area->nr_pages; page_counter++) > + area->pages[page_counter]->area = area; > + > return addr; Well this introduces significant overhead for large sized allocation. Does this not matter because the areas are small? Would it not be better to use compound page allocations here? page_head(whatever) gets you the head page where you can store all sorts of information about the chunk of memory.