> On 20 Jun 2016, at 06:04, Brett Lymn <bl...@internode.on.net> wrote:
>
> On Fri, Jun 17, 2016 at 10:51:44AM +0200, J. Hannken-Illjes wrote:
>>
>> This assertion is from 2015/03/27, last change to coda was 2015/09/06.
>>
>
> What can I say? $REALLIFE has been interfering for quite some time
> (clearly) ;)
>
>> Looks like coda nearly never locks vnodes before it calls vnode
>> operations using c_ovp. This is a bug.
>>
>
> OK, so, any hints on where those locks should happen? Last thing I want
> to do is create deadlocks. I should be able to fix this but it would be
> good if I can get some guidance to speed the process up a bit.
From a quick grep and look:
1) coda_rw()
remove the VOP_UNLOCK()
check the VOP_OPEN in "cfvp == NULL && cp->c_inode == 0" case,
it opens the coda node, why?
Make sure cfvp is locked.
on exit (after VOP_READ/VOP_WRITE) call VOP_UNLOCK(cfvp)
2) coda_fsync()
if (convp) {
vn_lock(convp, LK_EXCLUSIVE | LK_RETRY);
VOP_FSYNC(convp, cred, MNT_WAIT, 0, 0);
VOP_UNLOCK(convp);
}
3) coda_readdir()
analogous to 1)
4) coda_getpages()
looks wrong in many aspects. see XXX comments
If I get it right, after VOP_OPENing a coda node we always have
"cp->c_ovp != NULL" so at least for read, write, readdir it should
be ok to "KASSERT(cp->c_ovp != NULL)".
These changes should not add deadlocks as we always lock "coda -> ffs".
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
