https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222066
Bug ID: 222066
Summary: mpt crash in virtualbox
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs@FreeBSD.org
Reporter: a...@freebsd.org
We are seeing a kernel crash in mpt driver while running FreeBSD as a guest in
Virtualbox.
The problem seems to be caused by Virtualbox setting the request frame size
parameter to 512 bytes:
pReply->IOCFacts.u16RequestFrameSize = 128; /* @todo Figure out where it is
needed. */
The driver does not seem to be able to cope with such a large frame size.
It could be argued that the bug is on the Virtualbox side. I am not sure if it
really needs such a size (especially, given the comment).
Anyway, it could be useful to be able to handle that value in mpt.
A bit of code analysis follows.
In the code we have the following important definitions:
/* MPT_RQSL- size of request frame, in bytes */
#define MPT_RQSL(mpt) (mpt->ioc_facts.RequestFrameSize << 2)
#define MPT_MAX_REQUESTS(mpt) 512
#define MPT_REQUEST_AREA 512
#define MPT_SENSE_SIZE 32 /* included in MPT_REQUEST_AREA */
#define MPT_REQ_MEM_SIZE(mpt) (MPT_MAX_REQUESTS(mpt) * MPT_REQUEST_AREA)
So, the code allocates 512 request buffers of 512 bytes each as a single
contiguous (both physically and virtually) buffer suitable for DMA between the
driver and the hardware (see mpt_dma_buf_alloc).
When the crash happens, it's a page fault here:
memcpy <= mpt_read_cfg_page <= mpt_action
The problematic request:
(kgdb) p *req
$1 = {links = {tqe_next = 0xfffffe000179c390, tqe_prev = 0xfffffe0001798438},
state = 10, index = 511, IOCStatus = 0, ResponseCode = 0,
serno = 37161, ccb = 0x0, req_vbuf = 0xfffffe0000286e00, sense_vbuf =
0xfffffe0000286fe0, req_pbuf = 2089315840, sense_pbuf = 2089316320,
dmap = 0x0, chain = 0x0, callout = {c_links = {le = {le_next = 0x0, le_prev =
0xfffffe0001522df8}, sle = {sle_next = 0x0}, tqe = {
tqe_next = 0x0, tqe_prev = 0xfffffe0001522df8}}, c_time =
3787081006447, c_precision = 1342177187, c_arg = 0xfffff80038870000,
c_func = 0xffffffff804a4c30 <mpt_timeout>, c_lock = 0xfffffe0001798008,
c_flags = 0, c_iflags = 0, c_cpu = 0}}
We see that index is 511, so this is the last request object with its buffer in
the last 512 bytes of the contiguous buffer.
We see that the page fault happens right beyond the allocated buffer region.
So, my interpretation is that RequestFrameSize that's reported by the
[emulated] hardware is too large to be handled by the hardcoded request buffer
size. The problem is masked for all buffers but the last, because the hardware
would simply overwrite the next request buffer and the driver would read from
it. So, no page fault although there is a chance of silent data corruption.
For the last buffer there is obviously no next buffer and we get the page
fault.
Conclusions:
- first of all, the driver should check MPT_RQSL against MPT_REQUEST_AREA and
refuse to attach if the request frame size is too large
- we can consider bumping MPT_REQUEST_AREA to, e.g., 1024... probably better to
check
- Linux driver seems to cap the request size at 128 bytes:
http://elixir.free-electrons.com/linux/latest/source/drivers/message/fusion/mptbase.c#L3214
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
