linux-kernel - [RFC][10/11][MANUX] Suggestion : kmalloc()

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

Date:	Tue, 15 Apr 2014 15:43:15 +0200
From:	Emmanuel Colbus <ecolbus@...ux.info>
To:	linux-kernel@...r.kernel.org
Subject: [RFC][10/11][MANUX] Suggestion : kmalloc()

Finally, since cloning the Linux kernel gave me some ideas, I would like
to give you a couple of suggestions of my own. Feel free to do what you
want with them.

First, I'm not sure whether this has been done or not, but I would like
to suggest you to mark your kernel memory allocator with gcc's malloc
attribute (and mark kfree() as taking void*, not const void*).

Yes, I know, it apparently doesn't corresponds with what the malloc
attribute's specification covers, since there are still pointers to the
returned memory area somewhere else in the kernel. However, I would like
to point out that this isn't relevant : in *any* malloc-like
implementation, there will be such pointers somewhere in the allocator.
What's important is whether they are such pointers *in the specific
compilation units from which the allocator is called*.

And since the allocator can't call itself (well, I'm not sure for the
Linux one, of course, but this happens to be true in mine), leaving
kmalloc in a separate file allows setting this attribute, which gives a
little speed boost to the code (that's what it did to my kernel when I
did it). That's because it allows the compiler to know that two areas
allocated with such a function *cannot* alias each other, which helps it
optimize the memory accesses to them.
--
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/