linux-kernel - Re: [PATCH v2 24/29] nios2: Module support

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: <6364841.e2Acy30lOs@wuerfel>
Date:	Tue, 15 Jul 2014 12:24:46 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Ley Foon Tan <lftan@...era.com>
Cc:	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, lftan.linux@...il.com,
	cltang@...esourcery.com
Subject: Re: [PATCH v2 24/29] nios2: Module support

On Tuesday 15 July 2014 16:45:51 Ley Foon Tan wrote:
> +void *module_alloc(unsigned long size)
> +{
> +	if (size == 0)
> +		return NULL;
> +	return kmalloc(size, GFP_KERNEL);
> +}
> +
> +/* Free memory returned from module_alloc */
> +void module_free(struct module *mod, void *module_region)
> +{
> +	kfree(module_region);
> +}

Any particular reason for defining these to use kmalloc rather than
the default vmalloc based functions?

Note that kmalloc is more limited in size and won't work if the memory
is fragmented, while vmalloc has a small overhead on some architectures
due to TLB pressure, but only if the normal kernel memory is able to
use huge pages.

> +void module_arch_cleanup(struct module *mod)
> +{
> +}

This is not needed at all.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/