On Fri, Sep 21, 2007 at 12:11:15PM +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. > > OK, but freeque() freeary() and shm_destroy() are special cases: > we have the following path: > > mutex_lock(ipc_ids.mutex) > ... > ipc_lock(ipcp) > ... do whatever cleaning is needed ... > ipc_rmid(ipcp) > ipc_unlock(ipcp) > .... > ipc_rcu_putref(ipcp) > > Once the rmid has been done the ipc structure is considered as not > visible anymore from the user side ==> any syscall called with the > corresponding id will return invalid. > The only thing that could happen is that this structure be reused for a > newly allocated ipc structure. But this too cannot happen since we are > under the ipc_ids mutex lock. > > Am I wrong?
I hope not! But, then it would be probably another logical trick: ipc_rcu_getref/putref() seems to prevent kfreeing of a structure, so if it's used in do_msgsnd() there should be a risk something can do this kfree at this moment, and it seems freeque() is the only one, which both: can do this and cares for this refcount. Then, e.g., if any of them does ipc_rcu_getref() a bit later and sees old (cached) value - kfree can be skipped forever. On the other hand, if there is no such possibility because of other reasons, this all refcounting looks like a code beautifier only... Thanks, 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/
