linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Davidlohr Bueso <davidlohr.bueso@hp.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Emmanuel Benisty <benisty.e@gmail.com>,
	Dave Jones <davej@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@surriel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	hhuang@redhat.com, "Low, Jason" <jason.low2@hp.com>,
	Michel Lespinasse <walken@google.com>,
	Larry Woodman <lwoodman@redhat.com>,
	"Vinod, Chegu" <chegu_vinod@hp.com>,
	Peter Hurley <peter@hurleysoftware.com>
Subject: Re: ipc,sem: sysv semaphore scalability
Date: Fri, 29 Mar 2013 19:55:06 -0700	[thread overview]
Message-ID: <1364612106.1818.14.camel@buesod1.americas.hpqcorp.net> (raw)
In-Reply-To: <CA+55aFyksNnZJTL2WSV87s2CUBXouF9KVxDddYp9r1radBfFAA@mail.gmail.com>

On Fri, 2013-03-29 at 19:09 -0700, Linus Torvalds wrote:
> On Fri, Mar 29, 2013 at 6:36 PM, Emmanuel Benisty <benisty.e@gmail.com> wrote:
> >
> > I had to slightly modify the patch since it wouldn't match the changes
> > introduced by 7-7-ipc-sem-fine-grained-locking-for-semtimedop.patch,
> > hope that was the right thing to do. So, what I tried was: original 7
> > patches + the one liner + your patch blindly modified by me on the top
> > of 3.9-rc4 and I'm still having twilight zone issues.
> 
> Ok, please send your patch so that I can double-check what you did,
> but it was simple enough that you probably did the right thing.
> 
> Sad. Your case definitely looks like a double rcu-free, as shown by
> the fact that when you enabled SLUB debugging the oops happened with
> the use-after-free pattern (it's __rcu_reclaim() doing the
> "head->func(head);" thing, and "func" is 0x6b6b6b6b6b6b6b6b, so "head"
> has already been free'd once).
> 
> So ipc_rcu_putref() and a refcounting error looked very promising.as a
> potential explanation.
> 
> The 'un' undo structure is also free'd with rcu, but the locking
> around that seems much more robust. The undo entry is on two lists
> (sma->list_id, under sma->sem_perm.lock and ulp->list_proc, under
> ulp->lock). But those locks are actually tested with
> assert_spin_locked() in all the relevant places, and the code actually
> looks sane. So I had high hopes for ipc_rcu_putref()...
> 
> Hmm. Except for exit_sem() that does odd things. You have preemption
> enabled, don't you? exit_sem() does a lookup of the first list_proc
> entry under tcy_read_lock to lookup un->semid, and then it drops the
> rcu read lock. At which point "un" is no longer reliable, I think. But
> then it still uses "un->semid", rather than the stable value it looked
> up under the rcu read lock. Which looks bogus.
> 
> So I'd like you to test a few more things:
> 
>  (a) In exit_sem(), can you change the
> 
>          sma = sem_lock_check(tsk->nsproxy->ipc_ns, un->semid);
> 
>      to use just "semid" rather than "un->semid", because I don't
> think "un" is stable here.

Well that's not really the case in the new code. We don't drop the rcu
read lock until the end of the loop, in sem_unlock(). However, I just
noticed that we're checking sma for error after trying to acquire
sma->sem_perm.lock:

		sma = sem_obtain_object_check(tsk->nsproxy->ipc_ns, un->semid);
		sem_lock(sma, NULL, -1);

		/* exit_sem raced with IPC_RMID, nothing to do */
		if (IS_ERR(sma))
			continue;

The IS_ERR(sma) check should be right after the sem_obtain_object_check() call instead.



  reply	other threads:[~2013-03-30  2:55 UTC|newest]

Thread overview: 129+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-20 19:55 ipc,sem: sysv semaphore scalability Rik van Riel
2013-03-20 19:55 ` [PATCH 1/7] ipc: remove bogus lock comment for ipc_checkid Rik van Riel
2013-03-20 19:55 ` [PATCH 2/7] ipc: introduce obtaining a lockless ipc object Rik van Riel
2013-03-20 19:55 ` [PATCH 3/7] ipc: introduce lockless pre_down ipcctl Rik van Riel
2013-03-20 19:55 ` [PATCH 4/7] ipc,sem: do not hold ipc lock more than necessary Rik van Riel
2013-03-20 19:55 ` [PATCH 5/7] ipc,sem: open code and rename sem_lock Rik van Riel
2013-03-22  1:14   ` Davidlohr Bueso
2013-03-20 19:55 ` [PATCH 6/7] ipc,sem: have only one list in struct sem_queue Rik van Riel
2013-03-22  1:14   ` Davidlohr Bueso
2013-03-20 19:55 ` [PATCH 7/7] ipc,sem: fine grained locking for semtimedop Rik van Riel
2013-03-22  1:14   ` Davidlohr Bueso
2013-03-22 23:01   ` Michel Lespinasse
2013-03-22 23:38     ` Rik van Riel
2013-03-22 23:42     ` [PATCH 7/7 part3] fix for sem_lock Rik van Riel
2013-03-20 20:49 ` ipc,sem: sysv semaphore scalability Linus Torvalds
2013-03-20 20:56   ` Linus Torvalds
2013-03-20 20:57   ` Davidlohr Bueso
2013-03-21 21:10 ` Andrew Morton
2013-03-21 21:47   ` Peter Hurley
2013-03-21 21:50   ` Peter Hurley
2013-03-21 22:01     ` Andrew Morton
2013-03-22  3:38       ` Rik van Riel
2013-03-26 19:28   ` Dave Jones
2013-03-26 19:43     ` Andrew Morton
2013-03-29 16:17       ` Dave Jones
2013-03-29 18:00         ` Linus Torvalds
2013-03-29 18:04           ` Dave Jones
2013-03-29 18:10             ` Linus Torvalds
2013-03-29 18:43         ` Linus Torvalds
2013-03-29 19:06           ` Dave Jones
2013-03-29 19:13             ` Linus Torvalds
2013-03-29 19:26             ` Linus Torvalds
2013-03-29 19:36               ` Peter Hurley
2013-04-02 16:08                 ` Sasha Levin
2013-04-02 17:24                   ` Linus Torvalds
2013-04-02 17:52                   ` Linus Torvalds
2013-04-02 19:53                     ` Sasha Levin
2013-04-02 20:00                       ` Dave Jones
2013-03-29 19:33           ` Peter Hurley
2013-03-29 19:54             ` Linus Torvalds
2013-04-01  7:40           ` Stanislav Kinsbursky
2013-03-29 20:41         ` Linus Torvalds
2013-03-29 21:12           ` Linus Torvalds
2013-03-29 23:16             ` Linus Torvalds
2013-03-30  1:36               ` Emmanuel Benisty
2013-03-30  2:08                 ` Davidlohr Bueso
2013-03-30  3:02                   ` Emmanuel Benisty
2013-03-30  3:46                     ` Linus Torvalds
2013-03-30  4:33                       ` Emmanuel Benisty
2013-03-30  5:10                         ` Linus Torvalds
2013-03-30  5:57                           ` Emmanuel Benisty
2013-03-30 17:22                             ` Linus Torvalds
2013-03-31  2:38                               ` Emmanuel Benisty
2013-03-31  5:01                         ` Davidlohr Bueso
2013-03-31 13:45                           ` Rik van Riel
2013-03-31 17:10                             ` Linus Torvalds
2013-03-31 17:02                           ` Emmanuel Benisty
2013-03-30  2:09                 ` Linus Torvalds
2013-03-30  2:55                   ` Davidlohr Bueso [this message]
2013-03-29 19:01       ` Dave Jones
2013-05-03 15:03         ` Peter Hurley
2013-03-22  1:12 ` Davidlohr Bueso
2013-03-22  1:23   ` Linus Torvalds
2013-03-22  3:40     ` Rik van Riel
2013-03-22  7:30 ` Mike Galbraith
2013-03-22 11:04 ` Emmanuel Benisty
2013-03-22 15:37   ` Linus Torvalds
2013-03-23  3:19     ` Emmanuel Benisty
2013-03-23 19:45       ` Linus Torvalds
2013-03-24 13:46         ` Emmanuel Benisty
2013-03-24 17:10           ` Linus Torvalds
2013-03-25 13:47             ` Emmanuel Benisty
2013-03-25 14:00               ` Rik van Riel
2013-03-25 14:03                 ` Rik van Riel
2013-03-25 15:20                   ` Emmanuel Benisty
2013-03-25 15:53                     ` Rik van Riel
2013-03-25 17:09                       ` Emmanuel Benisty
2013-03-25 14:01               ` Rik van Riel
2013-03-25 14:21                 ` Emmanuel Benisty
2013-03-26 17:59               ` Davidlohr Bueso
2013-03-26 18:14                 ` Rik van Riel
2013-03-26 18:35                 ` Andrew Morton
2013-04-16 23:30                   ` Andrew Morton
2013-05-04 15:55       ` Jörn Engel
2013-05-04 18:12         ` Borislav Petkov
2013-05-06 14:47           ` Jörn Engel
2013-03-22 17:51 ` Davidlohr Bueso
2013-03-25 20:21 ` Sasha Levin
2013-03-25 20:38   ` [PATCH -mm -next] ipc,sem: fix lockdep false positive Rik van Riel
2013-03-25 21:42     ` Michel Lespinasse
2013-03-25 21:51       ` Michel Lespinasse
2013-03-25 21:56         ` Sasha Levin
2013-03-25 21:52       ` Sasha Levin
2013-03-26 13:19       ` Peter Zijlstra
2013-03-26 13:40         ` Michel Lespinasse
2013-03-26 14:27           ` Peter Zijlstra
2013-03-26 15:19             ` Rik van Riel
2013-03-27  8:40               ` Peter Zijlstra
2013-03-27  8:42               ` Peter Zijlstra
2013-03-27 11:22                 ` Michel Lespinasse
2013-03-27 12:02                   ` Peter Zijlstra
2013-03-27 20:00                 ` Rik van Riel
2013-03-28 20:23                 ` [PATCH v2 " Rik van Riel
2013-03-29  2:50                   ` Michel Lespinasse
2013-03-29  9:57                     ` Peter Zijlstra
2013-03-29 13:21                       ` Michel Lespinasse
2013-03-29 12:07                     ` Rik van Riel
2013-03-29 13:08                       ` Michel Lespinasse
2013-03-29 13:24                         ` Rik van Riel
2013-03-29 13:55                     ` [PATCH v3 " Rik van Riel
2013-03-29 13:59                       ` Michel Lespinasse
2013-03-26 14:25         ` [PATCH " Rik van Riel
2013-03-26 17:33 ` ipc,sem: sysv semaphore scalability Sasha Levin
2013-03-26 17:51   ` Davidlohr Bueso
2013-03-26 18:07     ` Sasha Levin
2013-03-26 18:17       ` Rik van Riel
2013-03-26 20:00       ` [PATCH -mm -next] ipc,sem: untangle RCU locking with find_alloc_undo Rik van Riel
2013-04-05  4:38         ` Mike Galbraith
2013-04-05 13:21           ` Rik van Riel
2013-04-05 16:26             ` Mike Galbraith
2013-04-16 12:37             ` Mike Galbraith
2013-03-26 17:55   ` ipc,sem: sysv semaphore scalability Paul E. McKenney
2013-03-28 15:32   ` [PATCH -mm -next] ipc,sem: untangle RCU locking with find_alloc_undo Rik van Riel
2013-03-28 21:05     ` Davidlohr Bueso
2013-03-29  1:00     ` Michel Lespinasse
2013-03-29  1:14       ` Sasha Levin
2013-03-30 13:35     ` Sasha Levin
2013-03-31  1:30       ` Rik van Riel
2013-03-31  4:09         ` 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=1364612106.1818.14.camel@buesod1.americas.hpqcorp.net \
    --to=davidlohr.bueso@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=benisty.e@gmail.com \
    --cc=chegu_vinod@hp.com \
    --cc=davej@redhat.com \
    --cc=hhuang@redhat.com \
    --cc=jason.low2@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lwoodman@redhat.com \
    --cc=peter@hurleysoftware.com \
    --cc=riel@surriel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=walken@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).