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

[Nadia Derbey <Nadia.Derbey@bull.net>]

Jarek Poplawski wrote:
> On Thu, Sep 20, 2007 at 03:08:42PM +0200, Nadia Derbey wrote:
>
> > Nadia Derbey wrote:
> >
> > > Jarek Poplawski wrote:
> > >
> > >
> > > > On Thu, Sep 20, 2007 at 08:24:58AM +0200, Nadia Derbey wrote:
>
> ...
>
> > > 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).
> > > So I think disabling preemption is needed, isn't it?
> > >
> > >
> > > > 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!
> >
> > So, here is the ipc_lock_by_ptr() status:
> > 1) do_msgsnd(), semctl_main(GETALL), semctl_main(SETALL) and find_undo() 
> > call it inside a refcounting.
> >  ==> no rcu read section needed.
> >
> > 2) *_exit_ns(), ipc_findkey() and sysvipc_find_ipc() call it under the 
> > ipc_ids mutex lock.
> >  ==> no rcu read section needed.
> >
> > 3) do_msgrcv() is the only path where ipc_lock_by_ptr() is not called 
> > under refcounting
> >  ==> rcu read section + some more checks needed once the spnlock is
> >      taken.
> >
> > So I completely agree with you: we might remove the rcu_read_lock() from 
> > the ipc_lock_by_ptr() and explicitley  call it when needed (actually, it 
> > is already explicitly called in do_msgrcv()).
>
>
> Yes, IMHO, it should be at least more readable when we can see where
> this RCU is really needed.
>
> But, after 3-rd look, I have a few more doubts (btw., 3 looks are
> still not enough for me with this code, so I cerainly can miss many
> things here, and, alas, I manged to see util and msg code only):
>
> 1. ipc_lock() and ipc_lock_check() are used without ipc_ids.mutex,
> but it's probably wrong: they call idr_find() with ipc_ids pointer
> which needs this mutex, just like in similar code in: ipc_findkey(),
> ipc_get_maxid() or sysvipc_find_ipc().
>
> 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?

Answers to the other questions in separate e-mails

Regards,
Nadia

-
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/