[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170807182103.GC25038@linux-80c1.suse>
Date: Mon, 7 Aug 2017 11:21:03 -0700
From: Davidlohr Bueso <dave@...olabs.net>
To: Guillaume Knispel <guillaume.knispel@...ersonicimagine.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Manfred Spraul <manfred@...orfullife.com>,
Kees Cook <keescook@...omium.org>,
Alexey Dobriyan <adobriyan@...il.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Serge Hallyn <serge@...lyn.com>,
Andrey Vagin <avagin@...nvz.org>,
Marc Pardo <marc.pardo@...ersonicimagine.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ipc: optimize semget/shmget/msgget for lots of keys
On Mon, 31 Jul 2017, Guillaume Knispel wrote:
> struct ipc_ids {
> int in_use;
> unsigned short seq;
>+ bool tables_initialized;
So this is really ugly to have, but I understand why you added it. I
wonder what folks would think if we just panic() in the rhashtable_init()
ENOMEM case, and convert the EINVALs to WARNs. This way the function
would always be called successfully. This is similar to what futex_init
does, with the underlying hash table allocator panicing. sems and msg
would probably have to be converted to pure_initcall, but hey, we could
at least get the symmetry back.
> static int __init ipc_ns_init(void)
> {
>- shm_init_ns(&init_ipc_ns);
>- return 0;
>+ const int err = shm_init_ns(&init_ipc_ns);
>+ WARN(err, "ipc: sysV shm_init_ns failed: %d\n", err);
nit: s/sysV/sysv
>+ return err;
> }
Thanks,
Davidlohr
Powered by blists - more mailing lists