Re: 2.6.23-rc6-mm1: IPC: sleeping function called ...

[Jarek Poplawski <jarkao2@o2.pl>]

On Tue, Sep 25, 2007 at 01:47:05PM +0200, Jarek Poplawski wrote:
> On Mon, Sep 24, 2007 at 11:50:23AM +0200, Nadia Derbey wrote:
> > Jarek Poplawski wrote:
> ...
> > >2. I'm not sure this refcounting with ipc_rcu_getref/putref is SMP
> > >safe (memory barriers): it's not atomic, so locking is needed, but
> > >e.g. in do_msgsnd() kern_ipc_perm lock is used for this, while
> > >freeque() calls ipc_rcu_putref() with ipc_ids mutex only.
> > >
> > >3. Probably similar problem is possible with msr_d.r_msg which is
> > >read in do_msgrcv() under rcu_read_lock() only.
> > >
> > 
> > In think here they have avoided refcoutning by using r_msg:
> > r_msg is initialzed to -EAGAIN before releasing the msq lock. if 
> > freequeue() is called it sets r_msg to EIDRM (see expunge_all(-EIDRM)).
> > Setting r_msg is always done under the msq lock (expunge_all() / 
> > pipelined_Sned()).
> >  Since rcu_read_lock is called right after schedule, they are sure the 
> > msq pointer is still valid when they re-lock it once a msg is present in 
> > the receive queue.
> > 
> > Please tell me if I'm not clear ;-)
> 
> All clear!
> 
> Except... this r_msg is still unclear to me. Since it's read without
> msq lock I doubt this first check after schedule() is of any value. A
> comment: "Lockless receive, part 2" tells about some safety against a
> race with pipeline_send() and expunge_all() when in wake_up_process(),
> but how can we be sure this r_msg is not just to be changed and this
> wake_up_process() is running while "while" check still sees
> ERR_PTR(-EAGAIN) instead of NULL?

OOPS!

At last I've found enough time to look at this more exactly plus the
right comment in sem.c, and it looks like it's all right and really
thought up, with all variants foreseen. So, I withdraw this problem
nr 3 too.

Best regards,
Jarek P.