src/sys/dev/mps, branch releng/14.1

mps: Handle errors from copyout() in ioctl handlers

2024-01-02T00:29:55Z

In preparation for adding a __result_use_check annotation to copyin() and related functions, start checking for errors from copyout() in the mps(4) user command handler. This should make it easier to catch bugs. Reviewed by: imp, asomers MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D43176 (cherry picked from commit bcf4a7c7ace21a01d10003de9c7692f0887526c1)

Use xpt_path_sbuf() in few drivers

2023-12-23T04:36:56Z

xpt_path_string() is now a wrapper around xpt_path_sbuf(). Using it to than concatenate result to another sbuf makes no sense. Just call xpt_path_sbuf() directly. MFC after: 1 month (cherry picked from commit 8c4ee0b22c98fc1e208dd133f617bd329cd10728)

mpr, mps: Establish busdma boundaries for memory pools

2023-12-20T15:40:42Z

Most all of the memory used by the cards in the mpr(4) and mps(4) drivers is required, according to the specs and Broadcom developers, to be within a 4GB segment of memory. This includes: System Request Message Frames pool Reply Free Queues pool ReplyDescriptorPost Queues pool Chain Segments pool Sense Buffers pool SystemReply message pool We got a bug report from Dwight Engen, who ran into data corruption in the BAE port of FreeBSD: > We have a port of the FreeBSD mpr driver to our kernel and recently > I found an issue under heavy load where a DMA may go to the wrong > address. The test system is a Supermicro X10SRH-CLN4F with the > onboard SAS3008 controller setup with 2 enterprise Micron SSDs in > RAID 0 (striped). I have debugged the issue and narrowed down that > the errant DMA is one that has a segment that crosses a 4GB > physical boundary. There are more details I can provide if you'd > like, but with the attached patch in place I can no longer > re-create the issue. > I'm not sure if this is a known limit of the card (have not found a > datasheet/programming docs for the chip) or our system is just > doing something a bit different. Any helpful info or insight would > be welcome. > Anyway, just thought this might be helpful info if you want to > apply a similar fix to FreeBSD. You can ignore/discard the commit > message as it is my internal commit (blkio is our own tool we use > to write/read every block of a device with CRC verification which > is how I found the problem). The commit message was: > [PATCH 8/9] mpr: fix memory corrupting DMA when sg segment crosses > 4GB boundary > Test case was two SSD's in RAID 0 (stripe). The logical disk was > then partitioned into two partitions. One partition had lots of > filesystem I/O and the other was initially filled using blkio with > CRCable data and then read back with blkio CRC verify in a loop. > Eventually blkio would report a bad CRC block because the physical > page being read-ahead into didn't contain the right data. If the > physical address in the arq/segs was for example 0x500003000 the > data would actually be DMAed to 0x400003000. The original patch was against mpr(4) before busdma templates were introduced, and only affected the buffer pool (sc->buffer_dmat) in the mpr(4) driver. After some discussion with Dwight and the LSI/Broadcom developers and looking through the driver, it looks like most of the queues in the driver are ok, because they limit the memory used to memory below 4GB. The buffer queue and the chain frames seem to be the exceptions. This is pretty much the same between the mpr(4) and mps(4) drivers. So, apply a 4GB boundary limitation for the buffer and chain frame pools in the mpr(4) and mps(4) drivers. Reported by: Dwight Engen Reviewed by: imp Obtained from: Dwight Engen Differential Revision: (cherry picked from commit 264610a86e14f8e123d94c3c3bd9632d75c078a3)

mprutil: "fix user reply buffer (64)..." warnings

2023-10-03T01:31:12Z

Depending on the card's firmware version, it may return different length responses for MPI2_FUNCTION_IOC_FACTS. But the first part of the response contains the length of the rest, so query it first to get the length and then use that to size the buffer for the full response. Also, correctly zero-initialize MPI2_IOC_FACTS_REQUEST. It only worked by luck before. PR: 264848 Reported by: Julien Cigar Sponsored by: Axcient Reviewed by: scottl, imp Differential Revision: https://reviews.freebsd.org/D38739 (cherry picked from commit 7d154c4dc64e61af7ca536c4e9927fa07c675a83)

sys: Remove $FreeBSD$: one-line .c pattern

2023-08-16T17:54:36Z

Remove /^[\s*]*__FBSDID$"\$FreeBSD\$"$;?\s*\n/

sys: Remove $FreeBSD$: two-line .h pattern

2023-08-16T17:54:11Z

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

2023-05-12T16:44:03Z

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix

mps: Fix a typo in a source code comment

2023-04-28T10:01:58Z

- s/feild/field/ MFC after: 3 days

Fix kernel memory disclosures in mpr and mps

2023-03-02T20:31:06Z

In every mpr and mps ioctl that copies kernel data to userland, validate that the requested length does not exceed the size of the kernel's buffer. Note that all of these ioctls already required root access. MFC after: 2 weeks Sponsored by: Axcient Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D38842

mps(4): Remove a double word in a source code comment

2022-09-04T11:48:21Z

- s/the the/the/ MFC after: 3 days