Re: [PATCH] scsi: megaraid_sas: fix PRP list out-of-bounds write

Hi all,

Adding a data point from an HPE ProLiant DL360 Gen11 with the MR408i-o Gen1=
1
controller (megaraid_sas), 960 GB SAS SSDs presented as sd*, running kernel
6.18.32 (Talos Linux v1.12.8). Without a cap the node panics within seconds=
 of
sustained block I/O to the controller, with the same megasas_make_prp_nvme
signature discussed in this thread.

Capping max_sectors_kb=3D1280 on the sd* devices resolves it on this contro=
ller
by itself. I pushed roughly 85 GB of dd bs=3D4M oflag=3Ddirect through it, =
so every
request is split at the 1280 KB boundary, with zero panics, where the uncap=
ped
case dies almost immediately. On the MR416i-o you found the cap necessary b=
ut
not sufficient because of a second problem in the SG advance path. I did no=
t
reach that second failure on the MR408i-o; the cap alone was enough here.

Both of our worker nodes have now run on kernel 6.18 throughout this testin=
g
with the cap applied by a udev rule at device add:

  ACTION=3D=3D"add|change", SUBSYSTEM=3D=3D"block", KERNEL=3D=3D"sd[a-z]", =
DRIVERS=3D=3D"megaraid_sas", ATTR{queue/max_sectors_kb}=3D"1280"

This lines up with Martin's suggestion to cap max_hw_sectors on the driver =
side
for NVMe behind MR. If a driver side patch would help, I am happy to build =
and
test it on this exact hardware and report back, and I can provide a full dm=
esg
or a serial panic capture from the uncapped case if that is useful.

Thanks,
Mats

> On 13 Jul 2026, at 23:07, Daniel Fernau <[email protected]> wrote:
>=20
> Hi all,
>=20
> Sorry for the late reply. I was unable to follow up on this earlier becau=
se I had to prioritize other issues.
>=20
> In the meantime, we pinned our kernel to version 6.8.12-4-pve on Proxmox,=
 which has been stable for our use case and hardware. Given the recent 7.x =
release, I will take another look this week and report back.
>=20
> We are using KIOXIA NVMe SSDs, so we will see how it goes.
>=20
> Thanks,
> Daniel
>=20
>=20
>=20
>=20
> On Sunday, July 12th, 2026 at 8:16 PM, Martin K. Petersen <martin.peterse=
[email protected]> wrote:
>=20
>>=20
>> Thorsten,
>>=20
>>> Martin, do you know if someone there ever looked into this regression
>>> and the proposed fix? I'm wondering because Daniel and Mats reported
>>> problems under the same subject line (in new threads), but also didn't
>>> get a reply.
>>=20
>> I think this problem is just an unfortunate side effect of the kernel
>> being able to build bigger I/Os by default.
>>=20
>> Typically NVMe SSDs report fairly modest maximum I/O sizes compared to
>> SCSI devices. I suspect this is why we only see this issue with a few
>> select models. My hunch is that these drives advertise a fairly large
>> MDTS.
>>=20
>> Since there appears to be no traction wrt. fixing the MR PRP vs. SGL
>> chaining logic, I wonder if the patch below is sufficient?
>>=20
>> --
>> Martin K. Petersen
>>=20
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/me=
garaid/megaraid_sas_base.c
>> index ecd365d78ae3..b93a6d1180ff 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -1978,7 +1978,8 @@ megasas_set_nvme_device_properties(struct scsi_dev=
ice *sdev,
>> 	mr_nvme_pg_size =3D max_t(u32, instance->nvme_page_size,
>> 				MR_DEFAULT_NVME_PAGE_SIZE);
>>=20
>> -	lim->max_hw_sectors =3D max_io_size / 512;
>> +	lim->max_hw_sectors =3D
>> +		min(SZ_2M >> SECTOR_SHIFT, max_io_size >> SECTOR_SHIFT);
>> 	lim->virt_boundary_mask =3D mr_nvme_pg_size - 1;
>> }
>>=20
>>=20