Messages in this thread | | | Date | Wed, 8 Aug 2007 03:14:37 +0400 | From | Oleg Nesterov <> | Subject | Re: [NFS] 2.6.23-rc1-mm2 |
| |
On 08/07, Trond Myklebust wrote: > > On Wed, 2007-08-08 at 02:20 +0400, Oleg Nesterov wrote: > > > But. nfs4_renew_state() checks list_empty(&clp->cl_superblocks) under > > clp->cl_sem? So, if it is possible that clp->cl_renewd was scheduled > > at the time when nfs4_kill_renewd(), we can deadlock, no? Because > > nfs4_renew_state() needs clp->cl_sem to complete, but nfs4_kill_renewd() > > holds this sem, and waits for nfs4_renew_state() completion. > > They both take read locks,
Aaaaaaaaaah. Please ignore me, thanks!
> which means that they can take them > simultaneously. AFAICS, the deadlock can only occur if something manages > to insert a request for a write lock after nfs4_kill_renewd() takes its > read lock, but before nfs4_renew_state() takes its read lock: > > 1) nfs4_kill_renewd() 2) nfs4_renew_state() 3) somebody else > ------------------- ------------------ ------------- > read lock > wait on (2) to complete > write lock <waits on (1)> > read lock <waits on (3), > because rw_semaphores > don't allow a read lock > request to jump a write > lock request> > > however as I explained earlier, the only process that can take a write > lock is the reclaimer daemon, but we _know_ that cannot be running (for > one thing, the reference count on nfs_client is zero, for the other, > there are no superblocks).
Oleg.
- 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/
| |