From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751247AbdJCWEA (ORCPT ); Tue, 3 Oct 2017 18:04:00 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:53792 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750841AbdJCWD7 (ORCPT ); Tue, 3 Oct 2017 18:03:59 -0400 Date: Tue, 3 Oct 2017 15:03:58 -0700 From: Andrew Morton To: Davidlohr Bueso Cc: manfred@colorfullife.com, linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: Re: [PATCH 1/4] sysvipc: unteach ids->next_id for !CHECKPOINT_RESTORE Message-Id: <20171003150358.d9b902d2e3e1489f425fd38c@linux-foundation.org> In-Reply-To: <20170831172049.14576-2-dave@stgolabs.net> References: <20170831172049.14576-1-dave@stgolabs.net> <20170831172049.14576-2-dave@stgolabs.net> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 31 Aug 2017 10:20:46 -0700 Davidlohr Bueso wrote: > The next_id object-allocation functionality was introduced in > 03f595668017f (ipc: add sysctl to specify desired next object id). > Given that these new entries are _only_ exported under the > CONFIG_CHECKPOINT_RESTORE option, there is no point for the > common case to even know about ->next_id. As such rewrite > ipc_buildid() such that it can do away with the field as well as > unnecessary branches when adding a new identifier. The end result > also better differentiates both cases, so the code ends up being > cleaner; albeit the small duplications regarding the default case. > > ... > > +#ifdef CONFIG_CHECKPOINT_RESTORE > +/* > + * Specify desired id for next allocated IPC object. > + */ > +#define ipc_idr_alloc(ids, new) \ > + idr_alloc(&(ids)->ipcs_idr, (new), \ > + (ids)->next_id < 0 ? 0: ipcid_to_idx((ids)->next_id), \ > + 0, GFP_NOWAIT); > + > > ... > > +#else > +#define ipc_idr_alloc(ids, new) \ > + idr_alloc(&(ids)->ipcs_idr, (new), 0, 0, GFP_NOWAIT); > + > ... Not a fan of checkpatch, I see... --- a/ipc/util.c~sysvipc-unteach-ids-next_id-for-checkpoint_restore-checkpatch-fixes +++ a/ipc/util.c @@ -223,8 +223,8 @@ int ipc_get_maxid(struct ipc_ids *ids) */ #define ipc_idr_alloc(ids, new) \ idr_alloc(&(ids)->ipcs_idr, (new), \ - (ids)->next_id < 0 ? 0: ipcid_to_idx((ids)->next_id), \ - 0, GFP_NOWAIT); + (ids)->next_id < 0 ? 0 : ipcid_to_idx((ids)->next_id),\ + 0, GFP_NOWAIT) static inline int ipc_buildid(int id, struct ipc_ids *ids, struct kern_ipc_perm *new) @@ -243,7 +243,7 @@ static inline int ipc_buildid(int id, st #else #define ipc_idr_alloc(ids, new) \ - idr_alloc(&(ids)->ipcs_idr, (new), 0, 0, GFP_NOWAIT); + idr_alloc(&(ids)->ipcs_idr, (new), 0, 0, GFP_NOWAIT) static inline int ipc_buildid(int id, struct ipc_ids *ids, struct kern_ipc_perm *new) Did these "functions" *have* to be implemented in cpp? Wouldn't they be better in C?