Date: Thu, 02 Aug 2018 20:50:16 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 230304] Malloc while lock is held in crypto code Message-ID: <bug-230304-227-Hy2liL4r9X@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230304-227@https.bugs.freebsd.org/bugzilla/> References: <bug-230304-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=3D230304 Conrad Meyer <cem@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open Assignee|bugs@FreeBSD.org |cem@freebsd.org --- Comment #1 from Conrad Meyer <cem@freebsd.org> --- The issue is that crypto_newsession() holds the normal mutex ("Crypto driver table" / CRYPTO_DRIVER_LOCK()) over the CRYPTODEV_NEWSESSION() call, and the cryptosoft driver allocates extra memory with M_WAITOK. The short term solution is to change crypto driver allocations back to M_NOWAIT unconditionally and be sure to check all error paths for bugs and memory leaks. But I don't think that's a reasonable long term approach. I think we probably want to pass a flags argument from crypto_newsession all the way down into individual driver newsessions to fix this right. That will take a decent amount of churn. crypto_newsession() also needs to be fixed to avoid deadlock when the caller allows M_WAITOK by dropping the lock over the call. --=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-230304-227-Hy2liL4r9X>