From 571dcd15e24b65783f9a5063cf81b9cc95449ffe Mon Sep 17 00:00:00 2001 From: Suleiman Souhlal Date: Fri, 1 Jul 2005 16:28:32 +0000 Subject: Fix the recent panics/LORs/hangs created by my kqueue commit by: - Introducing the possibility of using locks different than mutexes for the knlist locking. In order to do this, we add three arguments to knlist_init() to specify the functions to use to lock, unlock and check if the lock is owned. If these arguments are NULL, we assume mtx_lock, mtx_unlock and mtx_owned, respectively. - Using the vnode lock for the knlist locking, when doing kqueue operations on a vnode. This way, we don't have to lock the vnode while holding a mutex, in filt_vfsread. Reviewed by: jmg Approved by: re (scottl), scottl (mentor override) Pointyhat to: ssouhlal Will be happy: everyone --- sys/kern/vfs_aio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'sys/kern/vfs_aio.c') diff --git a/sys/kern/vfs_aio.c b/sys/kern/vfs_aio.c index 7cae398f963a..87ab064df54a 100644 --- a/sys/kern/vfs_aio.c +++ b/sys/kern/vfs_aio.c @@ -1287,7 +1287,7 @@ _aio_aqueue(struct thread *td, struct aiocb *job, struct aio_liojob *lj, int typ aiocbe->inputcharge = 0; aiocbe->outputcharge = 0; /* XXX - need a lock */ - knlist_init(&aiocbe->klist, NULL); + knlist_init(&aiocbe->klist, NULL, NULL, NULL, NULL); suword(&job->_aiocb_private.status, -1); suword(&job->_aiocb_private.error, 0); -- cgit v1.2.3