Re: locking crash using coda

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

> On 20 Jun 2016, at 06:04, Brett Lymn <blymn%internode.on.net@localhost> 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 - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)