All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: manfred@colorfullife.com, linux-kernel@vger.kernel.org,
	Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH 1/4] sysvipc: unteach ids->next_id for !CHECKPOINT_RESTORE
Date: Tue, 3 Oct 2017 15:03:58 -0700	[thread overview]
Message-ID: <20171003150358.d9b902d2e3e1489f425fd38c@linux-foundation.org> (raw)
In-Reply-To: <20170831172049.14576-2-dave@stgolabs.net>

On Thu, 31 Aug 2017 10:20:46 -0700 Davidlohr Bueso <dave@stgolabs.net> 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?

  reply	other threads:[~2017-10-03 22:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-31 17:20 [PATCH -next 0/4] sysvipc: ipc-key management improvements Davidlohr Bueso
2017-08-31 17:20 ` [PATCH 1/4] sysvipc: unteach ids->next_id for !CHECKPOINT_RESTORE Davidlohr Bueso
2017-10-03 22:03   ` Andrew Morton [this message]
2017-08-31 17:20 ` [PATCH 2/4] sysvipc: duplicate lock comments wrt ipc_addid() Davidlohr Bueso
2017-08-31 17:20 ` [PATCH 3/4] sysvipc: properly name ipc_addid() limit parameter Davidlohr Bueso
2017-08-31 17:20 ` [PATCH 4/4] sysvipc: make get_maxid O(1) again Davidlohr Bueso
2017-08-31 17:37   ` Davidlohr Bueso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171003150358.d9b902d2e3e1489f425fd38c@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=dave@stgolabs.net \
    --cc=dbueso@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --subject='Re: [PATCH 1/4] sysvipc: unteach ids->next_id for '\!'CHECKPOINT_RESTORE' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.