Date: Wed, 23 Aug 2023 14:23:50 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 273289] smartpqi: fix panic on removal of SAS drive Message-ID: <bug-273289-227-5Vo64uFrfi@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-273289-227@https.bugs.freebsd.org/bugzilla/> References: <bug-273289-227@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=3D273289 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bcr@FreeBSD.org, | |markj@FreeBSD.org Status|New |Open --- Comment #2 from Mark Johnston <markj@FreeBSD.org> --- (In reply to John F. Carr from comment #1) Yes, there doesn't seem to be any particular reason to hold the lock across= the free() calls. Though, I cannot see a reason to use a MTX_SPIN lock here at all. It looks like softs->devlist_lock should be a MTX_DEF mutex. Spin mutexes are only needed when synchronizing with interrupt handlers, and it doesn't look like this mutex has to deal with that. Though, fixing that would be more involv= ed and would require some modification to this OS abstraction layer in the dri= ver. --=20 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-273289-227-5Vo64uFrfi>