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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
