info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Bug 220094] [scsi] sys/cam/scsi/scsi_sa.c: a sleep-under-mutex bug
0 views
Skip to first unread message
bugzilla...@freebsd.org
Jun 17, 2017, 11:15:34 PM6/17/17
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220094
Jia-Ju Bai <baijia...@163.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |freebsd-...@FreeBSD.or
| |g
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardwa...@freebsd.org"
Jia-Ju Bai <baijia...@163.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |freebsd-...@FreeBSD.or
| |g
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardwa...@freebsd.org"
bugzilla...@freebsd.org
Jun 18, 2017, 1:07:04 PM6/18/17
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220094
Mark Linimon <lin...@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebs...@FreeBSD.org |freebs...@FreeBSD.org
Mark Linimon <lin...@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebs...@FreeBSD.org |freebs...@FreeBSD.org
bugzilla...@freebsd.org
Jun 19, 2017, 4:49:13 PM6/19/17
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220094
--- Comment #2 from commi...@freebsd.org ---
A commit references this bug:
Author: ken
Date: Mon Jun 19 20:48:01 UTC 2017
New revision: 320123
URL: https://svnweb.freebsd.org/changeset/base/320123
Log:
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 lead
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 longer
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 <baijia...@163.com>
MFC after: 3 days
Sponsored by: Spectra Logic
Changes:
head/sys/cam/scsi/scsi_sa.c
--- Comment #2 from commi...@freebsd.org ---
A commit references this bug:
Author: ken
Date: Mon Jun 19 20:48:01 UTC 2017
New revision: 320123
URL: https://svnweb.freebsd.org/changeset/base/320123
Log:
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 lead
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 longer
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 <baijia...@163.com>
MFC after: 3 days
Sponsored by: Spectra Logic
Changes:
head/sys/cam/scsi/scsi_sa.c
bugzilla...@freebsd.org
Jun 26, 2017, 11:24:16 AM6/26/17
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220094
--- Comment #3 from commi...@freebsd.org ---
New revision: 320361
URL: https://svnweb.freebsd.org/changeset/base/320361
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 lead
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 longer
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 <baijia...@163.com>
stable/10/sys/cam/scsi/scsi_sa.c
--- Comment #3 from commi...@freebsd.org ---
A commit references this bug:
Author: ken
Date: Mon Jun 26 15:23:12 UTC 2017
Author: ken
New revision: 320361
URL: https://svnweb.freebsd.org/changeset/base/320361
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 lead
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 longer
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 <baijia...@163.com>
Sponsored by: Spectra Logic
Changes:
_U stable/10/
Changes:
stable/10/sys/cam/scsi/scsi_sa.c
bugzilla...@freebsd.org
Jun 27, 2017, 8:57:36 AM6/27/17
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220094
--- Comment #4 from commi...@freebsd.org ---
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 lead
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 longer
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 <baijia...@163.com>
Sponsored by: Spectra Logic
Approved by: re (gjb)
Changes:
_U stable/11/
stable/11/sys/cam/scsi/scsi_sa.c
--- Comment #4 from commi...@freebsd.org ---
A commit references this bug:
Author: ken
Date: Tue Jun 27 12:56:37 UTC 2017
Author: ken
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 lead
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 longer
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 <baijia...@163.com>
Sponsored by: Spectra Logic
Changes:
_U stable/11/
stable/11/sys/cam/scsi/scsi_sa.c
0 new messages