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 Gen11
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=1280 on the sd* devices resolves it on this controller
by itself. I pushed roughly 85 GB of dd bs=4M oflag=direct through it, so every
request is split at the 1280 KB boundary, with zero panics, where the uncapped
case dies almost immediately. On the MR416i-o you found the cap necessary but
not sufficient because of a second problem in the SG advance path. I did not
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 testing
with the cap applied by a udev rule at device add:

  ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd[a-z]", DRIVERS=="megaraid_sas", ATTR{queue/max_sectors_kb}="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 dmesg
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:
> 
> Hi all,
> 
> Sorry for the late reply. I was unable to follow up on this earlier because I had to prioritize other issues.
> 
> 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.
> 
> We are using KIOXIA NVMe SSDs, so we will see how it goes.
> 
> Thanks,
> Daniel
> 
> 
> 
> 
> On Sunday, July 12th, 2026 at 8:16 PM, Martin K. Petersen <[email protected]> wrote:
> 
>> 
>> Thorsten,
>> 
>>> 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.
>> 
>> I think this problem is just an unfortunate side effect of the kernel
>> being able to build bigger I/Os by default.
>> 
>> 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.
>> 
>> Since there appears to be no traction wrt. fixing the MR PRP vs. SGL
>> chaining logic, I wonder if the patch below is sufficient?
>> 
>> --
>> Martin K. Petersen
>> 
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/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_device *sdev,
>> 	mr_nvme_pg_size = max_t(u32, instance->nvme_page_size,
>> 				MR_DEFAULT_NVME_PAGE_SIZE);
>> 
>> -	lim->max_hw_sectors = max_io_size / 512;
>> +	lim->max_hw_sectors =
>> +		min(SZ_2M >> SECTOR_SHIFT, max_io_size >> SECTOR_SHIFT);
>> 	lim->virt_boundary_mask = mr_nvme_pg_size - 1;
>> }
>> 
>>