Date: Thu, 05 Nov 2015 19:19:54 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-scsi@FreeBSD.org Subject: [Bug 204298] xpt_release_device() panic: mutex CAM queue lock not owned Message-ID: <bug-204298-5312-906fb7eIps@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-204298-5312@https.bugs.freebsd.org/bugzilla/> References: <bug-204298-5312@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204298 --- Comment #5 from Scott M. Ferris <smferris@gmail.com> --- (In reply to Alexander Motin from comment #3) Yes, for the patch to work we have to use the lock ordering: devq->send_mtx before bus->eb_mtx device->device_mtx before bus->eb_mtx It's a counter-intuitive ordering but seems to work given how eb_mtx is used today. Where would we violate that ordering? I don't see anyplace acquiring another lock while holding bus->eb_mtx. No, wait, I missed xpt_alloc_device() wanting the send_mtx in order to cam_devq_resize(). Can we solve that by moving the cam_devq_resize() from xpt_alloc_device() up into xpt_compile_path()? That appears to be the only caller of xport->alloc_device() and only the transports call xpt_alloc_device(). I'll see if I can make that work. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-204298-5312-906fb7eIps>