Date: Tue, 27 Jun 2017 12:57:25 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-scsi@FreeBSD.org Subject: [Bug 220094] [scsi] sys/cam/scsi/scsi_sa.c: a sleep-under-mutex bug in saioctl Message-ID: <bug-220094-5312-HdkcIqhT9T@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-220094-5312@https.bugs.freebsd.org/bugzilla/> References: <bug-220094-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=3D220094 --- Comment #4 from commit-hook@freebsd.org --- A commit references this bug: Author: ken Date: Tue Jun 27 12:56:37 UTC 2017 New revision: 320405 URL: https://svnweb.freebsd.org/changeset/base/320405 Log: MFC r320123: Fix a potential sleep while holding a mutex in the sa(4) driver. If the user issues a MTIOCEXTGET ioctl, and the tape drive in question = has a serial number that is longer than 80 characters, we malloc a buffer in saextget() to hold the output of cam_strvis(). Since a mutex is held in that codepath, doing a M_WAITOK malloc could l= ead to sleeping while holding a mutex. Change it to a M_NOWAIT malloc and = bail out if we fail to allocate the memory. Devices with serial numbers lon= ger than 80 bytes are very rare (I don't recall seeing one), so this should be a very unusual case to hit. But it is a bug that should be fixed. sys/cam/scsi/scsi_sa.c: In saextget(), if we need to malloc a buffer to hold the output of cam_strvis(), don't wait for the memory. Fail and return an error if we can't allocate the memory immediately. PR: kern/220094 Submitted by: Jia-Ju Bai <baijiaju1990@163.com> Sponsored by: Spectra Logic Approved by: re (gjb) Changes: _U stable/11/ stable/11/sys/cam/scsi/scsi_sa.c --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-220094-5312-HdkcIqhT9T>