All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarek Poplawski <jarkao2@o2.pl>
To: Nadia Derbey <Nadia.Derbey@bull.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Alexey Dobriyan <adobriyan@sw.ru>,
	linux-kernel@vger.kernel.org
Subject: Re: 2.6.23-rc6-mm1: IPC: sleeping function called ...
Date: Thu, 20 Sep 2007 09:28:21 +0200	[thread overview]
Message-ID: <20070920072821.GA2065@ff.dom.local> (raw)
In-Reply-To: <46F2123A.9070201@bull.net>

On Thu, Sep 20, 2007 at 08:24:58AM +0200, Nadia Derbey wrote:
> Jarek Poplawski wrote:
> >On 18-09-2007 16:55, Nadia Derbey wrote:
> >...
> >
> >>Well, reviewing the code I found another place where the 
> >>rcu_read_unlock() was missing.
> >>I'm so sorry for the inconvenience. It's true that I should have tested 
> >>with CONFIG_PREEMPT=y :-(
> >>Now, the ltp tests pass even with this option set...
> >>
> >>In attachment you'll find a patch thhat
> >>1) adds the missing rcu_read_unlock()
> >>2) replaces Andrew's fix with a new one: the rcu_read_lock() is now 
> >>taken in ipc_lock() / ipc_lock_by_ptr() and released in ipc_unlock(), 
> >>exactly as it was done in the ref code.
> >
> >
> >BTW, probably I miss something, but I wonder, how this RCU is working
> >here. E.g. in msg.c do_msgsnd() there is:
> >
> >msq = msg_lock_check(ns, msqid);
> >...
> >
> >msg_unlock(msq);
> >schedule();
> >
> >ipc_lock_by_ptr(&msq->q_perm);
> >
> >Since msq_lock_check() gets msq with ipc_lock_check() under
> >rcu_read_lock(), and then goes msg_unlock(msq) (i.e. ipc_unlock())
> >with rcu_read_unlock(), is it valid to use this with
> >ipc_lock_by_ptr() yet?
> 
> Before Calling msg_unlock() they call ipc_rcu_getref() that increments a 
> refcount in the rcu header for the msg structure. This guarantees that 
> the the structure won't be freed before they relock it. Once the 
> structure is relocked by ipc_lock_by_ptr(), they do the symmetric 
> operation i.e. ipc_rcu_putref().

Yes, I've found this later too - sorry for bothering. I was mislead
by the code like this:

struct kern_ipc_perm *ipc_lock(struct ipc_ids *ids, int id)
{
        struct kern_ipc_perm *out;
        int lid = ipcid_to_idx(id);

        rcu_read_lock();
        out = idr_find(&ids->ipcs_idr, lid);
        if (out == NULL) {
                rcu_read_unlock();
                return ERR_PTR(-EINVAL);
        }

which seems to suggest "out" is an RCU protected pointer, so, I
thought these refcounts were for something else. But, after looking
at how it's used it turns out to be ~90% wrong: probably 9 out of 10
places use refcouning around this, so, these rcu_read_locks() don't
work here at all. So, probably I miss something again, but IMHO,
these rcu_read_locks/unlocks could be removed here or in
ipc_lock_by_ptr() and it should be enough to use them directly, where
really needed, e.g., in msg.c do_msgrcv().

BTW, I've found this comment, which, at least for me, explains very
good, what's going on here:

/* Lockless receive, part 3:
 * Acquire the queue spinlock.
 */
 ipc_lock_by_ptr(&msq->q_perm);

Thanks,
Jarek P.

  reply	other threads:[~2007-09-20  7:26 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-18  9:17 2.6.23-rc6-mm1: IPC: sleeping function called Alexey Dobriyan
2007-09-18  9:42 ` Andrew Morton
2007-09-18 10:17 ` Andrew Morton
2007-09-18 10:30   ` Nadia Derbey
2007-09-18 10:34     ` Andrew Morton
     [not found]       ` <20070918142451.418b3b51@twins>
2007-09-18 16:13         ` Paul E. McKenney
2007-09-18 16:57           ` Andrew Morton
2007-09-18 18:29             ` Paul E. McKenney
2007-09-18 19:41               ` Peter Zijlstra
2007-09-18 20:26               ` [PATCH 1/2] lockdep: annotate rcu_read_lock() Peter Zijlstra
2007-09-18 20:27               ` [RFC][PATCH 2/2] lockdep: rcu_dereference() vs rcu_read_lock() Peter Zijlstra
2007-09-18 21:21                 ` Paul E. McKenney
2007-09-18 10:27 ` 2.6.23-rc6-mm1: IPC: sleeping function called Andrew Morton
2007-09-18 10:32   ` Alexey Dobriyan
2007-09-18 14:55   ` Nadia Derbey
2007-09-18 17:01     ` Andrew Morton
2007-09-21  9:18       ` Nadia Derbey
2007-09-19 14:07     ` Jarek Poplawski
2007-09-20  6:24       ` Nadia Derbey
2007-09-20  7:28         ` Jarek Poplawski [this message]
2007-09-20  8:21           ` Jarek Poplawski
2007-09-20  8:52           ` Nadia Derbey
2007-09-20 13:08             ` Nadia Derbey
2007-09-20 13:26               ` Jarek Poplawski
2007-09-21  8:44               ` Jarek Poplawski
2007-09-21 10:11                 ` Nadia Derbey
2007-09-21 11:03                   ` Jarek Poplawski
2007-09-21 11:15                     ` Jarek Poplawski
2007-09-24  6:54                     ` Jarek Poplawski
2007-09-24  7:43                       ` Jarek Poplawski
2007-09-24  8:18                       ` Nadia Derbey
2007-09-24  9:50                 ` Nadia Derbey
2007-09-25 11:47                   ` Jarek Poplawski
2007-09-26  6:13                     ` Jarek Poplawski
2007-09-20 13:19             ` Jarek Poplawski

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=20070920072821.GA2065@ff.dom.local \
    --to=jarkao2@o2.pl \
    --cc=Nadia.Derbey@bull.net \
    --cc=adobriyan@sw.ru \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.