linux-kernel - Re: [PATCH] md: simplify free_params for kmalloc vs vmalloc fallback

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LRH.2.02.1604281129360.14065@file01.intranet.prod.int.rdu2.redhat.com>
Date:	Thu, 28 Apr 2016 11:40:59 -0400 (EDT)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	Michal Hocko <mhocko@...nel.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	LKML <linux-kernel@...r.kernel.org>,
	Shaohua Li <shli@...nel.org>, dm-devel@...hat.com
Subject: Re: [PATCH] md: simplify free_params for kmalloc vs vmalloc
 fallback



On Thu, 28 Apr 2016, Michal Hocko wrote:

> On Thu 28-04-16 11:04:05, Mikulas Patocka wrote:
> > Acked-by: Mikulas Patocka <mpatocka@...hat.com>
> 
> Thanks!
> 
> > BTW. we could also use kvmalloc to complement kvfree, proposed here: 
> > https://www.redhat.com/archives/dm-devel/2015-July/msg00046.html
> 
> If there are sufficient users (I haven't checked other than quick git
> grep on KMALLOC_MAX_SIZE

the problem is that kmallocs with large sizes near KMALLOC_MAX_SIZE are 
unreliable, they'll randomly fail if memory is too fragmented.

> and there do not seem that many) who are
> sharing the same fallback strategy then why not. But I suspect that some
> would rather fallback earlier and even do not attempt larger than e.g.
> order-1 requests.
> -- 
> Michal Hocko
> SUSE Labs

There are many users that use one of these patterns:

	if (size <= some_threshold)
		p = kmalloc(size);
	else
		p = vmalloc(size);

or

	p = kmalloc(size);
	if (!p)
		p = vmalloc(size);


For example: alloc_fdmem, seq_buf_alloc, setxattr, getxattr, ipc_alloc, 
pidlist_allocate, get_pages_array, alloc_bucket_locks, 
frame_vector_create. If you grep the kernel for vmalloc, you'll find this 
pattern over and over again.

In alloc_large_system_hash, there is
	table = __vmalloc(size, GFP_ATOMIC, PAGE_KERNEL);
- that is clearly wrong because __vmalloc doesn't respect GFP_ATOMIC

Mikulas