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

This is a discussion on Re: 2.6.23-rc6-mm1: IPC: sleeping function called ... - Kernel ; 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 > ...

+ Reply to Thread
Results 1 to 2 of 2

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

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

    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?

    Thanks & sorry for delay,
    Jarek P.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread