linux-kernel - Re: [PATCH 1/6] mm: introduce kv[mz]alloc helpers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 30 Jan 2017 09:42:21 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Michal Hocko <mhocko@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     David Rientjes <rientjes@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Johannes Weiner <hannes@...xchg.org>,
        Al Viro <viro@...iv.linux.org.uk>, linux-mm@...ck.org,
        LKML <linux-kernel@...r.kernel.org>,
        Anatoly Stepanov <astepanov@...udlinux.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Mike Snitzer <snitzer@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Theodore Ts'o <tytso@....edu>,
        Andreas Dilger <adilger@...ger.ca>
Subject: Re: [PATCH 1/6] mm: introduce kv[mz]alloc helpers

On 01/26/2017 01:09 PM, Michal Hocko wrote:
> On Thu 12-01-17 16:37:12, Michal Hocko wrote:
> [...]
>> +void *kvmalloc_node(size_t size, gfp_t flags, int node)
>> +{
>> +	gfp_t kmalloc_flags = flags;
>> +	void *ret;
>> +
>> +	/*
>> +	 * vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables)
>> +	 * so the given set of flags has to be compatible.
>> +	 */
>> +	WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
>> +
>> +	/*
>> +	 * Make sure that larger requests are not too disruptive - no OOM
>> +	 * killer and no allocation failure warnings as we have a fallback
>> +	 */
>> +	if (size > PAGE_SIZE)
>> +		kmalloc_flags |= __GFP_NORETRY | __GFP_NOWARN;
>> +
>> +	ret = kmalloc_node(size, kmalloc_flags, node);
>> +
>> +	/*
>> +	 * It doesn't really make sense to fallback to vmalloc for sub page
>> +	 * requests
>> +	 */
>> +	if (ret || size <= PAGE_SIZE)
>> +		return ret;
>> +
>> +	return __vmalloc_node_flags(size, node, flags);
>> +}
>> +EXPORT_SYMBOL(kvmalloc_node);
>
> While discussing bpf change I've realized that the vmalloc fallback
> doesn't request __GFP_HIGHMEM. So I've updated the patch to do so. All
> the current users except for f2fs_kv[zm]alloc which just seemed to
> forgot or didn't know about the flag. In the next step, I would like to
> check whether we actually have any __vmalloc* user which would strictly
> refuse __GFP_HIGHMEM because I do not really see any reason for that and
> if there is none then I would simply pull __GFP_HIGHMEM handling into
> the vmalloc.
>
> So before I resend the full series again, can I keep acks with the
> following?

OK!

Thanks,
Vlastimil