linux-kernel - [RFC] Use plan9 C extensions

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 9 Jan 2019 12:31:19 -0800
From:   Matthew Wilcox <willy@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     linux-kernel@...r.kernel.org,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nathan Chancellor <natechancellor@...il.com>,
        Joel Stanley <joel@....id.au>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>
Subject: [RFC] Use plan9 C extensions

While replacing idr_alloc_cyclic(), I've come across a situation in
which being able to depend on -fplan9-extensions is going to lead to
nicer code in the users.

For cyclic allocations, we need to keep a 'next' value somewhere.
The IDR had a moderately large root, so they didn't mind the cost to
all users of embedding the next value in the root.  For the XArray,
I care about increasing it from the current 16 bytes on 64-bit or
12 bytes on 32-bit.  If most users used it, I wouldn't care, but
only about 10% of the IDR users use the cyclic functionality.

What I currently have is this (random example):

-       struct idr      s2s_cp_stateids;
-       spinlock_t      s2s_cp_lock;
+       struct xarray   s2s_cp_stateids;
+       u32             s2s_cp_stateid_next;

...

+       if (xa_alloc_cyclic(&nn->s2s_cp_stateids,
+                               &copy->cp_stateid.si_opaque.so_id, copy,
+                               xa_u32_limit, &nn->s2s_cp_stateid_next,
+                               GFP_KERNEL))
                return 0;

What I'd really like to do is have a special data structure for the
cyclic users that embeds that "next" field, but I can pass to all the
regular xa_foo() functions.  Something like this:

struct cyclic_xarray {
	struct xarray;
	u32 next;
};

Then this user would do:

	struct cyclic_xarray s2s_cp_stateids;

	if (xa_alloc_cyclic(&nn->s2s_cp_stateids,
				&copy->cp_stateid.si_opaque.so_id, copy,
				xa_u32_limit, GFP_KERNEL))

(ie one fewer argument, as well as one fewer thing to track in their struct).

That's what -fplan9-extensions would allow us to do.  Without it,
we'd need to name that struct xarray and need extra syntactic sugar;
eg later when it calls xa_erase(), it'd look like this:

	xa_erase(&nn->s2s_cp_stateids, copy->cp_stateid.si_opaque.so_id);

instead of:

	xa_erase(&nn->s2s_cp_stateids.xa, copy->cp_stateid.si_opaque.so_id);

-fplan9-extensions is supported in gcc since 4.6 which is now our minimum
version.  This might annoy the people who want to get the kernel compiling
with LLVM though (and any other compilers?  is icc still a thing?).  Added
those people to the cc.