[nvmewin] New Patch From Sandisk

Tue Apr 30 11:52:19 PDT 2013

Hi Dharani,

Thank you for putting this patch together. Please see my feedback below:

-          Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file).

-          Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters.

-          Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples.

-          Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed.

-          General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock).  So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it's pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted.

Thanks,
Ray

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte
Sent: Tuesday, April 30, 2013 11:14 AM
To: Chang, Alex; nvmewin at lists.openfabrics.org
Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk

Attaching the code with according to Alex suggestion. Passwd: sndk1234

Thanks,
Dharani.

From: Chang, Alex [mailto:Alex.Chang at idt.com]
Sent: Tuesday, April 30, 2013 9:23 AM
To: Dharani Kotte; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: New Patch From Sandisk

Hi Dharani,

I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch.

Thanks,
Alex

________________________________
From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte
Sent: Tuesday, April 30, 2013 8:37 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] New Patch From Sandisk
Hi all,

It's been almost two weeks after I sent out the patch. please let us know if you're okay with it.

Thanks,
Dharani.

From: Dharani Kotte
Sent: Friday, April 12, 2013 9:58 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: New Patch From Sandisk

Hi all,

I am attaching a new patch that includes the following changes:

1.    In nvmeSnti.c

a.       Allocate a global buffer of 256bytes size for modesense return data preparation

b.      For any mode sense this buffer is used for modesense data along with the requested pages in it.

c.       Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly

d.      In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue

Please review the changes and provide feedbacks if you have any. If nobody disagrees with the changes, I will remind Ray to merge them in two weeks.

Thanks,
Dharani.

________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20130430/adda2d05/attachment.html>