Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <20180709151019.1336-13-manfred@colorfullife.com>
References: <20180709151019.1336-1-manfred@colorfullife.com> <20180709151019.1336-13-manfred@colorfullife.com>
From:   Dmitry Vyukov <dvyukov@google.com>
Date:   Mon, 9 Jul 2018 19:05:29 +0200
Message-ID: <CACT4Y+ZVuhHmrdhVou5KWkV2v2s-jEq4+fz+=6WxK3JJaK087A@mail.gmail.com>
Subject: Re: [PATCH 12/12] ipc/util.c: Further ipc_idr_alloc cleanups.
To:     Manfred Spraul <manfred@colorfullife.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Davidlohr Bueso <dave@stgolabs.net>,
        LKML <linux-kernel@vger.kernel.org>, 1vier1@web.de,
        Kees Cook <keescook@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Jul 9, 2018 at 5:10 PM, Manfred Spraul <manfred@colorfullife.com> wrote:
> If idr_alloc within ipc_idr_alloc fails, then the return value (-ENOSPC)
> is used to calculate new->id.
> Technically, this is not a bug, because new->id is never accessed.
>
> But: Clean it up anyways: On error, just return, do not set new->id.
> And improve the documentation.
>
> Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> ---
>  ipc/util.c | 22 ++++++++++++++++------
>  1 file changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/ipc/util.c b/ipc/util.c
> index d474f2b3b299..302c18fc846b 100644
> --- a/ipc/util.c
> +++ b/ipc/util.c
> @@ -182,11 +182,20 @@ static struct kern_ipc_perm *ipc_findkey(struct ipc_ids *ids, key_t key)
>  }
>
>  /*
> - * Specify desired id for next allocated IPC object.
> + * Insert new IPC object into idr tree, and set sequence number and id
> + * in the correct order.
> + * Especially:
> + * - the sequence number must be set before inserting the object into the idr,
> + *   because the sequence number is accessed without a lock.
> + * - the id can/must be set after inserting the object into the idr.
> + *   All accesses must be done after getting kern_ipc_perm.lock.
> + *
> + * The caller must own kern_ipc_perm.lock.of the new object.
> + * On error, the function returns a (negative) error code.
>   */
>  static inline int ipc_idr_alloc(struct ipc_ids *ids, struct kern_ipc_perm *new)
>  {
> -       int key, next_id = -1;
> +       int id, next_id = -1;

/\/\/\/\
Looks good to me. I was also confused by how key transforms into id,
and then key name is used for something else.

>  #ifdef CONFIG_CHECKPOINT_RESTORE
>         next_id = ids->next_id;
> @@ -197,14 +206,15 @@ static inline int ipc_idr_alloc(struct ipc_ids *ids, struct kern_ipc_perm *new)
>                 new->seq = ids->seq++;
>                 if (ids->seq > IPCID_SEQ_MAX)
>                         ids->seq = 0;
> -               key = idr_alloc(&ids->ipcs_idr, new, 0, 0, GFP_NOWAIT);
> +               id = idr_alloc(&ids->ipcs_idr, new, 0, 0, GFP_NOWAIT);
>         } else {
>                 new->seq = ipcid_to_seqx(next_id);
> -               key = idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id),
> +               id = idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id),
>                                 0, GFP_NOWAIT);
>         }
> -       new->id = SEQ_MULTIPLIER * new->seq + key;
> -       return key;
> +       if (id >= 0)
> +               new->id = SEQ_MULTIPLIER * new->seq + id;

We still initialize seq in this case. I guess it's ok because the
object is not published at all. But if we are doing this, then perhaps
store seq into a local var first and then:

      if (id >= 0) {
              new->id = SEQ_MULTIPLIER * seq + id;
              new->seq = seq:
      }

?
But I don't have a strong preference, so if it's the only reason to
resend series then perhaps it's not worth it.

Thanks


> +       return id;
>  }
>
>  /**
> --
> 2.17.1
>