All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rafael Aquini <aquini@redhat.com>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Davidlohr Bueso <davidlohr@hp.com>,
	Rik van Riel <riel@redhat.com>, Greg Thelen <gthelen@google.com>
Subject: Re: [PATCH v2] ipc: introduce ipc_valid_object() helper to sort out IPC_RMID races
Date: Wed, 18 Dec 2013 11:12:06 -0200	[thread overview]
Message-ID: <20131218131206.GG19025@localhost.localdomain> (raw)
In-Reply-To: <20131218125059.GF19025@localhost.localdomain>

On Wed, Dec 18, 2013 at 10:50:59AM -0200, Rafael Aquini wrote:
> On Wed, Dec 18, 2013 at 01:11:29PM +0100, Manfred Spraul wrote:
> > On 12/18/2013 12:28 AM, Rafael Aquini wrote:
> > >After the locking semantics for the SysV IPC API got improved, a couple of
> > >IPC_RMID race windows were opened because we ended up dropping the
> > >'kern_ipc_perm.deleted' check performed way down in ipc_lock().
> > >The spotted races got sorted out by re-introducing the old test within
> > >the racy critical sections.
> > >
> > >This patch introduces ipc_valid_object() to consolidate the way we cope with
> > >IPC_RMID races by using the same abstraction across the API implementation.
> > >
> > >Signed-off-by: Rafael Aquini <aquini@redhat.com>
> > >Acked-by: Rik van Riel <riel@redhat.com>
> > >Acked-by: Greg Thelen <gthelen@google.com>
> > >---
> > >Changelog:
> > >* v2:
> > >  - drop assert_spin_locked() from ipc_valid_object() for less overhead
> > a) sysv ipc is lockless whereever possible, without writing to any
> > shared cachelines.
> > Therefore my first reaction was: No, please leave the assert in. It
> > will help us to catch bugs.
> > 
> > b) then I noticed: the assert would be a bug, the comment in front
> > of ipc_valid_object() that the caller must hold _perm.lock is wrong:
> > >@@ -1846,7 +1846,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf __user *, tsops,
> > >  	error = -EIDRM;
> > >  	locknum = sem_lock(sma, sops, nsops);
> > >-	if (sma->sem_perm.deleted)
> > >+	if (!ipc_valid_object(&sma->sem_perm))
> > >  		goto out_unlock_free;
> > simple semtimedop() operation do not acquire sem_perm.lock, they
> > only acquire the per-semaphore lock and check that sem_perm.lock is
> > not held. This is sufficient to prevent races with RMID.
> > 
> > Could you update the comment?
> 
> The comment for ipc_valid_object() is not entirely wrong, as holding the spinlock 
> is clearly necessary for all cases except for this one you pointed above. 
> When I dropped the assert as Davilohr suggested, I then could have this one exception 
> case (where the check can, eventually, be done lockless) converted too, but I did not include 
> an exception comment at that particular checkpoint. Perhaps, that's what I should have done, or
> perhaps the best thing is to just let all that as is sits right now.
>

Or, as a second thought, we could perhaps re-instate the assert in
ipc_valid_object(), and change only this exception checkpoint back to a
if (sma->sem_perm.deleted) case, adding a comment there on why it's different
from the others.


Looking up to hear your thoughts here!

Thanks!
-- Rafael

> 
> > [...]
> > >@@ -1116,7 +1116,7 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr,
> > >  	ipc_lock_object(&shp->shm_perm);
> > >  	/* check if shm_destroy() is tearing down shp */
> > >-	if (shp->shm_file == NULL) {
> > >+	if (!ipc_valid_object(&shp->shm_perm)) {
> > >  		ipc_unlock_object(&shp->shm_perm);
> > >  		err = -EIDRM;
> > >  		goto out_unlock;
> > Please mention the change from "shm_file == NULL" to perm.deleted in
> > the changelog.
> > With regards to the impact of this change: No idea, I've never
> > worked on the shm code.
> 
> This change is, essentially, the proper way to cope with such races. Please
> refer to the following reply on this same trhead, for further info:
> https://lkml.org/lkml/2013/12/17/704
> 
> Thanks!
> -- Rafael
> 

  reply	other threads:[~2013-12-18 13:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-17 19:03 [PATCH] ipc: introduce ipc_valid_object() helper to sort out IPC_RMID races Rafael Aquini
2013-12-17 19:31 ` Rik van Riel
2013-12-17 20:41 ` Greg Thelen
2013-12-17 21:27 ` Davidlohr Bueso
2013-12-17 21:46   ` Rafael Aquini
2013-12-17 22:18     ` Davidlohr Bueso
2013-12-17 22:50       ` Rafael Aquini
2013-12-17 23:28 ` [PATCH v2] " Rafael Aquini
2013-12-18 12:11   ` Manfred Spraul
2013-12-18 12:51     ` Rafael Aquini
2013-12-18 13:12       ` Rafael Aquini [this message]
2013-12-18 15:46       ` Davidlohr Bueso
2013-12-18 15:53         ` Rafael Aquini
2013-12-18 17:34         ` Rafael Aquini
2013-12-18 19:00           ` Manfred Spraul
2013-12-18 20:33 ` [PATCH v3] " Rafael Aquini
2013-12-19  0:38   ` Davidlohr Bueso
2013-12-19  0:42     ` Rafael Aquini

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=20131218131206.GG19025@localhost.localdomain \
    --to=aquini@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=davidlohr@hp.com \
    --cc=gthelen@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=riel@redhat.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.