On Thu, Sep 20, 2007 at 10:52:43AM +0200, Nadia Derbey wrote: > Jarek Poplawski wrote: ... > >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, > > Actually, ipc_lock() is called most of the time without the > ipc_ids.mutex held and without refcounting (maybe you didn't look for > the msg_lock() sem_lock() and shm_lock() too).
Yes, you are 100% right and I'm 90% lier, 10% blind (maybe backward too). > So I think disabling preemption is needed, isn't it? Do I've to tell the truth...? > > >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(). > > > > I have to check for the ipc_lock_by_ptr(): may be you're right! Since this whole locking scheme is really quite a puzzle, and needs more than one or two looks to figure it out, I'd better try stop to discredit myself more. Anyway it looks to me like the most sophisticated way of achieving locklessness I've seen so far. I hope, there is still some gain after this RCU + refcounting vs. simple locking. (It seems somebody had similar doubts writing the "Lockless receive, part 1:" comment in do_msgrcv(); and probably again I'm very wrong, but this checking of validity of RCU protected structure with an r_msg value, which is done to avoid refcounting, looks like not very different and has some cost too). Regards, 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/
