* [bug report] scsi: mpt3sas: Added support for nvme encapsulated request message.
@ 2017-11-07 11:33 Dan Carpenter
2017-11-07 17:29 ` Sathya Prakash Veerichetty
0 siblings, 1 reply; 3+ messages in thread
From: Dan Carpenter @ 2017-11-07 11:33 UTC (permalink / raw)
To: suganath-prabu.subramani; +Cc: MPT-FusionLinux.pdl, linux-scsi
Hello Suganath Prabu Subramani,
The patch aff39e61218f: "scsi: mpt3sas: Added support for nvme
encapsulated request message." from Oct 31, 2017, leads to the
following static checker warning:
drivers/scsi/mpt3sas/mpt3sas_base.c:1459 _base_build_nvme_prp()
error: buffer overflow 'nvme_encap_request->NVMe_Command' 4 <= 24
drivers/scsi/mpt3sas/mpt3sas_base.c
1453 /*
1454 * Set pointers to PRP1 and PRP2, which are in the NVMe command.
1455 * PRP1 is located at a 24 byte offset from the start of the NVMe
^^^^^^^
The ->NVMe_Command is declared as a 4 byte array so this makes static
checkers puzzled how there are more than 24 bytes in it.
1456 * command. Then set the current PRP entry pointer to PRP1.
1457 */
1458 prp1_entry = (__le64 *)(nvme_encap_request->NVMe_Command +
1459 NVME_CMD_PRP1_OFFSET);
1460 prp2_entry = (__le64 *)(nvme_encap_request->NVMe_Command +
1461 NVME_CMD_PRP2_OFFSET);
1462 prp_entry = prp1_entry;
1463 /*
1464 * For the PRP entries, use the specially allocated buffer of
1465 * contiguous memory.
1466 */
1467 prp_page = (__le64 *)mpt3sas_base_get_pcie_sgl(ioc, smid);
1468 prp_page_phys = (__le64 *)mpt3sas_base_get_pcie_sgl_dma(ioc, smid);
1469
regards,
dan carpenter
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [bug report] scsi: mpt3sas: Added support for nvme encapsulated request message.
2017-11-07 11:33 [bug report] scsi: mpt3sas: Added support for nvme encapsulated request message Dan Carpenter
@ 2017-11-07 17:29 ` Sathya Prakash Veerichetty
2017-11-08 8:07 ` Dan Carpenter
0 siblings, 1 reply; 3+ messages in thread
From: Sathya Prakash Veerichetty @ 2017-11-07 17:29 UTC (permalink / raw)
To: Dan Carpenter, Suganath Prabu Subramani; +Cc: PDL-MPT-FUSIONLINUX, linux-scsi
Dan,
The MPI structures are of variable length and can go up to a maximum of
128 bytes (a MPI frame size) and as MPI standard the variable length MPI
structures are left out with the last element as a single dword array.
Can we ignore the warning? If not we need to modify the MPI structure to
have the NVMe_Command array to the maximum size of the frame (which is
typically 128 but can change across hardware generations)
Thanks
Sathya
-----Original Message-----
From: mpt-fusionlinux.pdl@broadcom.com
[mailto:mpt-fusionlinux.pdl@broadcom.com] On Behalf Of Dan Carpenter
Sent: Tuesday, November 7, 2017 4:34 AM
To: suganath-prabu.subramani@broadcom.com
Cc: MPT-FusionLinux.pdl@broadcom.com; linux-scsi@vger.kernel.org
Subject: [bug report] scsi: mpt3sas: Added support for nvme encapsulated
request message.
Hello Suganath Prabu Subramani,
The patch aff39e61218f: "scsi: mpt3sas: Added support for nvme
encapsulated request message." from Oct 31, 2017, leads to the following
static checker warning:
drivers/scsi/mpt3sas/mpt3sas_base.c:1459 _base_build_nvme_prp()
error: buffer overflow 'nvme_encap_request->NVMe_Command' 4 <= 24
drivers/scsi/mpt3sas/mpt3sas_base.c
1453 /*
1454 * Set pointers to PRP1 and PRP2, which are in the NVMe
command.
1455 * PRP1 is located at a 24 byte offset from the start of
the NVMe
^^^^^^^ The ->NVMe_Command is
declared as a 4 byte array so this makes static checkers puzzled how there
are more than 24 bytes in it.
1456 * command. Then set the current PRP entry pointer to
PRP1.
1457 */
1458 prp1_entry = (__le64 *)(nvme_encap_request->NVMe_Command +
1459 NVME_CMD_PRP1_OFFSET);
1460 prp2_entry = (__le64 *)(nvme_encap_request->NVMe_Command +
1461 NVME_CMD_PRP2_OFFSET);
1462 prp_entry = prp1_entry;
1463 /*
1464 * For the PRP entries, use the specially allocated buffer
of
1465 * contiguous memory.
1466 */
1467 prp_page = (__le64 *)mpt3sas_base_get_pcie_sgl(ioc, smid);
1468 prp_page_phys = (__le64
*)mpt3sas_base_get_pcie_sgl_dma(ioc, smid);
1469
regards,
dan carpenter
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bug report] scsi: mpt3sas: Added support for nvme encapsulated request message.
2017-11-07 17:29 ` Sathya Prakash Veerichetty
@ 2017-11-08 8:07 ` Dan Carpenter
0 siblings, 0 replies; 3+ messages in thread
From: Dan Carpenter @ 2017-11-08 8:07 UTC (permalink / raw)
To: Sathya Prakash Veerichetty
Cc: Suganath Prabu Subramani, PDL-MPT-FUSIONLINUX, linux-scsi
On Tue, Nov 07, 2017 at 10:29:20AM -0700, Sathya Prakash Veerichetty wrote:
> Dan,
> The MPI structures are of variable length and can go up to a maximum of
> 128 bytes (a MPI frame size) and as MPI standard the variable length MPI
> structures are left out with the last element as a single dword array.
> Can we ignore the warning?
Yeah. These are a one time email but eventually other people running
static checkers are going to be confused as well.
> If not we need to modify the MPI structure to
> have the NVMe_Command array to the maximum size of the frame (which is
> typically 128 but can change across hardware generations)
To be honest, to declaring arrays as their maximum size is a pretty
common idiom...
U8 NVMe_Command[4]; /*0x20 */
What does the 4 *mean* in this context? As a human being, I would
understand that to be a 4 byte array, but it's clearly not. You're
saying it's supposed to be a single dword array but why??? Is there
something special and mandatory stored in the first 4 bytes? Why can't
it just be a zero size array?
It would help if there were at least a comment or something.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-11-08 8:07 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-11-07 11:33 [bug report] scsi: mpt3sas: Added support for nvme encapsulated request message Dan Carpenter
2017-11-07 17:29 ` Sathya Prakash Veerichetty
2017-11-08 8:07 ` Dan Carpenter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).