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"