From raymond.c.robles at intel.com Tue Sep 1 11:38:52 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Tue, 1 Sep 2015 18:38:52 +0000 Subject: [nvmewin] Zero Length for Security Receive and Security Send command In-Reply-To: References: <00b101d0c675$3de1b5e0$b9a521a0$@wang@ulinktech.com> <49158E750348AA499168FD41D88983606B6EABCD@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B71B10B@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B71D689@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983606B73F7B6@fmsmsx117.amr.corp.intel.com> Thanks Tom. Now just waiting on Samsung and PMC-Sierra. Reviewing Company Status Samsung Review In Progress PMC-Sierra Review In Progress HGST Approved Intel Approved After this patch, there are two patches in queue to be reviewed: 1. NVMe fuzz test fixes (Google) 2. Namespace management (Intel) Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Monday, August 31, 2015 11:41 AM To: Robles, Raymond C; Yun Wang; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, HGST approves your patch. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, August 27, 2015 1:04 PM To: Yun Wang >; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Intel has reviewed and tested your patch and approves your patch. Just need to hear back from the other reviewing companies. Reviewing Company Status Samsung Review In Progress PMC-Sierra Review In Progress HGST Review In Progress Intel Approved Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, August 24, 2015 2:14 PM To: Yun Wang; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Yun, Your patch is now in line to be reviewed. Reviewing Companies, Please review Yun's patch for zero length Secure Send/Receive commands and provide feedback on or before September 4th. Thanks! Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, July 30, 2015 3:25 PM To: Yun Wang Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Thank you for your patch submission. There is one patch in front of yours. Once that patch has been reviewed and approved, your patch will be reviewed next. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Yun Wang Sent: Friday, July 24, 2015 6:00 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Zero Length for Security Receive and Security Send command Hi: Current OFA driver doesn't allow zero length for Security Receive and Security Send command. Per NVMe spec., "Security Receive command with the Security Protocol field set to 00h shall return information about the security protocols supported by the controller. This command is used in the security discovery process and is not associated with a Security Send command. Refer to SPC-4 for the details of Security Protocol 00h and the SP Specific field". Per SPC-4 spec., "a transfer length of zero specifies that no data transfer shall take place. This condition shall not be considered an error", zero length of data transfer for Security Protocol 00h should be allowed. On the other hand, for some practices with other Security Protocol, zero length will be needed, too. This patch is to allow zero length of data transfer for Security Receive and Security Send command. It has been tested over Win8.1 x64 platform and works as expected. Please review and help merge it into the trunk. The password for the attachment is nvme_sec. Best Regards, Yun Wang ULINK Technology, Inc. Website: www.ulinktech.com Office: +1(408) 446-8455 Email: yun.wang at ulinktech.com [ulink logo 2] DISCLAIMER: The information contained in this message is confidential and may be legally privileged. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1628 bytes Desc: image002.jpg URL: From suman.p at samsung.com Tue Sep 1 19:06:36 2015 From: suman.p at samsung.com (SUMAN PRAKASH B) Date: Wed, 02 Sep 2015 02:06:36 +0000 (GMT) Subject: [nvmewin] Zero Length for Security Receive and Security Send command Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201509020736810_Y5W7Z1SF.png Type: image/png Size: 4274 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201509020736815_QZUWXYH6.jpg Type: image/jpeg Size: 1628 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201509020736825_9220TQUP.gif Type: image/gif Size: 13168 bytes Desc: not available URL: From raymond.c.robles at intel.com Tue Sep 1 23:32:00 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Wed, 2 Sep 2015 06:32:00 +0000 Subject: [nvmewin] Zero Length for Security Receive and Security Send command Message-ID: <6irkn74hl73emw09fa9dey2n.1441175431148@email.android.com> Thanks Suman! -------- Original message -------- From: SUMAN PRAKASH B Date: 09/01/2015 7:06 PM (GMT-07:00) To: nvmewin at lists.openfabrics.org, yun.wang at ulinktech.com, "Robles, Raymond C" , "Judy Brock-SSI (judy.brock at ssi.samsung.com)" Subject: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Ray, SAMSUNG approves this patch. Thanks, Suman From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Tuesday, September 01, 2015 11:39 AM To: Thomas Freeman; Yun Wang; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Thanks Tom. Now just waiting on Samsung and PMC-Sierra. Reviewing Company Status Samsung Review In Progress PMC-Sierra Review In Progress HGST Approved Intel Approved After this patch, there are two patches in queue to be reviewed: 1. NVMe fuzz test fixes (Google) 2. Namespace management (Intel) Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Monday, August 31, 2015 11:41 AM To: Robles, Raymond C; Yun Wang; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, HGST approves your patch. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, August 27, 2015 1:04 PM To: Yun Wang >; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Intel has reviewed and tested your patch and approves your patch. Just need to hear back from the other reviewing companies. Reviewing Company Status Samsung Review In Progress PMC-Sierra Review In Progress HGST Review In Progress Intel Approved Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, August 24, 2015 2:14 PM To: Yun Wang; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Yun, Your patch is now in line to be reviewed. Reviewing Companies, Please review Yun’s patch for zero length Secure Send/Receive commands and provide feedback on or before September 4th. Thanks! Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, July 30, 2015 3:25 PM To: Yun Wang Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Thank you for your patch submission. There is one patch in front of yours. Once that patch has been reviewed and approved, your patch will be reviewed next. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Yun Wang Sent: Friday, July 24, 2015 6:00 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Zero Length for Security Receive and Security Send command Hi: Current OFA driver doesn’t allow zero length for Security Receive and Security Send command. Per NVMe spec., “Security Receive command with the Security Protocol field set to 00h shall return information about the security protocols supported by the controller. This command is used in the security discovery process and is not associated with a Security Send command. Refer to SPC-4 for the details of Security Protocol 00h and the SP Specific field”. Per SPC-4 spec., “a transfer length of zero specifies that no data transfer shall take place. This condition shall not be considered an error”, zero length of data transfer for Security Protocol 00h should be allowed. On the other hand, for some practices with other Security Protocol, zero length will be needed, too. This patch is to allow zero length of data transfer for Security Receive and Security Send command. It has been tested over Win8.1 x64 platform and works as expected. Please review and help merge it into the trunk. The password for the attachment is nvme_sec. Best Regards, Yun Wang ULINK Technology, Inc. Website: www.ulinktech.com Office: +1(408) 446-8455 Email: yun.wang at ulinktech.com [ulink logo 2] DISCLAIMER: The information contained in this message is confidential and may be legally privileged. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. [cid:_com_android_email_attachmentprovider_2_11259_RAW at sec.galaxytab] -------------- next part -------------- A non-text attachment was scrubbed... Name: 201509020736810_Y5W7Z1SF.png Type: image/png Size: 4274 bytes Desc: 201509020736810_Y5W7Z1SF.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201509020736815_QZUWXYH6.jpg Type: image/jpeg Size: 1628 bytes Desc: 201509020736815_QZUWXYH6.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201509020736825_9220TQUP.gif Type: image/gif Size: 13168 bytes Desc: 201509020736825_9220TQUP.gif URL: From per at techspot.com Wed Sep 2 11:34:36 2015 From: per at techspot.com (Per Hansson) Date: Wed, 02 Sep 2015 20:34:36 +0200 Subject: [nvmewin] Win7 x86 NVMe compiled driver is old version Message-ID: <8f2ec82818039be9a2d85858b5f76bcc@techspot.com> Hi, the version of the compiled NVMe driver for Win7 x86 is actually v1.3.0 and not v1.4.0. It for example seems to lack TRIM support. https://svn.openfabrics.org/svnrepo/nvmewin/releases/revision_1.4/installations/32-bit/Windows7/ Sincerely - Per Hansson From mikeb at bustrace.com Wed Sep 2 15:35:46 2015 From: mikeb at bustrace.com (Mike Berhan) Date: Wed, 2 Sep 2015 16:35:46 -0600 Subject: [nvmewin] Win7 x86 NVMe compiled driver is old version In-Reply-To: <8f2ec82818039be9a2d85858b5f76bcc@techspot.com> References: <8f2ec82818039be9a2d85858b5f76bcc@techspot.com> Message-ID: <016401d0e5cf$b6753530$235f9f90$@bustrace.com> In the Windows 7 storage stack, there is no UNMAP CDB sent down from the class driver. That's only in Windows 8 and above. Mike -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Per Hansson Sent: Wednesday, September 2, 2015 12:35 PM To: nvmewin at lists.openfabrics.org; nvmewin at lists.openfabrics.org Subject: [nvmewin] Win7 x86 NVMe compiled driver is old version Hi, the version of the compiled NVMe driver for Win7 x86 is actually v1.3.0 and not v1.4.0. It for example seems to lack TRIM support. https://svn.openfabrics.org/svnrepo/nvmewin/releases/revision_1.4/installati ons/32-bit/Windows7/ Sincerely - Per Hansson _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin From raymond.c.robles at intel.com Wed Sep 2 16:03:05 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Wed, 2 Sep 2015 23:03:05 +0000 Subject: [nvmewin] Win7 x86 NVMe compiled driver is old version In-Reply-To: <016401d0e5cf$b6753530$235f9f90$@bustrace.com> References: <8f2ec82818039be9a2d85858b5f76bcc@techspot.com> <016401d0e5cf$b6753530$235f9f90$@bustrace.com> Message-ID: <49158E750348AA499168FD41D88983606B7447C9@fmsmsx117.amr.corp.intel.com> Mike is correct. Win 7 does not support TRIM natively. Any IHV wanting to support TRIM on Win 7 would have to implement a method (i.e. filter driver) to handle sending TRIM requests. Win 8 and later natively supports TRIM. Thanks, Ray -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Mike Berhan Sent: Wednesday, September 02, 2015 3:36 PM To: 'Per Hansson'; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Win7 x86 NVMe compiled driver is old version In the Windows 7 storage stack, there is no UNMAP CDB sent down from the class driver. That's only in Windows 8 and above. Mike -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Per Hansson Sent: Wednesday, September 2, 2015 12:35 PM To: nvmewin at lists.openfabrics.org; nvmewin at lists.openfabrics.org Subject: [nvmewin] Win7 x86 NVMe compiled driver is old version Hi, the version of the compiled NVMe driver for Win7 x86 is actually v1.3.0 and not v1.4.0. It for example seems to lack TRIM support. https://svn.openfabrics.org/svnrepo/nvmewin/releases/revision_1.4/installati ons/32-bit/Windows7/ Sincerely - Per Hansson _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin From per at techspot.com Thu Sep 3 04:45:43 2015 From: per at techspot.com (Per Hansson) Date: Thu, 03 Sep 2015 13:45:43 +0200 Subject: [nvmewin] Win7 x86 NVMe compiled driver is old version In-Reply-To: <49158E750348AA499168FD41D88983606B7447C9@fmsmsx117.amr.corp.intel.com> References: <8f2ec82818039be9a2d85858b5f76bcc@techspot.com> <016401d0e5cf$b6753530$235f9f90$@bustrace.com> <49158E750348AA499168FD41D88983606B7447C9@fmsmsx117.amr.corp.intel.com> Message-ID: Hi, I did not know that Win7 lacks native TRIM support, thanks for the info. Question remains though why there is a compiled v1.3.0 version of the driver in the 32-bit folder of Win7 in the revision 1.4 release tree? (It's 1.4.0 for 64-bit Win7) See version string here: https://svn.openfabrics.org/svnrepo/nvmewin/releases/revision_1.4/installations/32-bit/Windows7/nvme.inf Sincerely - Per Hansson, editor @ Techspot.com On 2015-09-03 01:03, Robles, Raymond C wrote: > Mike is correct. Win 7 does not support TRIM natively. Any IHV wanting > to support TRIM on Win 7 would have to implement a method (i.e. filter > driver) to handle sending TRIM requests. Win 8 and later natively > supports TRIM. > > Thanks, > Ray > > -----Original Message----- > From: nvmewin-bounces at lists.openfabrics.org > [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Mike > Berhan > Sent: Wednesday, September 02, 2015 3:36 PM > To: 'Per Hansson'; nvmewin at lists.openfabrics.org > Subject: Re: [nvmewin] Win7 x86 NVMe compiled driver is old version > > In the Windows 7 storage stack, there is no UNMAP CDB sent down from > the class driver. That's only in Windows 8 and above. > > Mike > > -----Original Message----- > From: nvmewin-bounces at lists.openfabrics.org > [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Per Hansson > Sent: Wednesday, September 2, 2015 12:35 PM > To: nvmewin at lists.openfabrics.org; nvmewin at lists.openfabrics.org > Subject: [nvmewin] Win7 x86 NVMe compiled driver is old version > > Hi, the version of the compiled NVMe driver for Win7 x86 is actually > v1.3.0 and not v1.4.0. > It for example seems to lack TRIM support. > > https://svn.openfabrics.org/svnrepo/nvmewin/releases/revision_1.4/installati > ons/32-bit/Windows7/ > > Sincerely - Per Hansson > > _______________________________________________ > nvmewin mailing list > nvmewin at lists.openfabrics.org > http://lists.openfabrics.org/mailman/listinfo/nvmewin > > _______________________________________________ > nvmewin mailing list > nvmewin at lists.openfabrics.org > http://lists.openfabrics.org/mailman/listinfo/nvmewin From raymond.c.robles at intel.com Wed Sep 9 18:00:57 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 10 Sep 2015 01:00:57 +0000 Subject: [nvmewin] Win7 x86 NVMe compiled driver is old version In-Reply-To: References: <8f2ec82818039be9a2d85858b5f76bcc@techspot.com> <016401d0e5cf$b6753530$235f9f90$@bustrace.com> <49158E750348AA499168FD41D88983606B7447C9@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983606B74B29D@fmsmsx117.amr.corp.intel.com> Hi Per, I had to go back and check with the one of the companies who managed the releases. It appears it was an oversight in the .inf file. However, the Visual Studio project/solution has been modified such that the compiled driver will override the .inf and display 1.4.0.0 in the OS. Were you able to verify that if the driver if this driver is installed, the revision shows as 1.4.0.0? If not, and you see 1.3.0.0 or any other version in the OS, please let me know. Thanks, Ray -----Original Message----- From: Per Hansson [mailto:per at techspot.com] Sent: Thursday, September 03, 2015 4:46 AM To: Robles, Raymond C; Robles, Raymond C Cc: 'Mike Berhan'; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Win7 x86 NVMe compiled driver is old version Hi, I did not know that Win7 lacks native TRIM support, thanks for the info. Question remains though why there is a compiled v1.3.0 version of the driver in the 32-bit folder of Win7 in the revision 1.4 release tree? (It's 1.4.0 for 64-bit Win7) See version string here: https://svn.openfabrics.org/svnrepo/nvmewin/releases/revision_1.4/installations/32-bit/Windows7/nvme.inf Sincerely - Per Hansson, editor @ Techspot.com On 2015-09-03 01:03, Robles, Raymond C wrote: > Mike is correct. Win 7 does not support TRIM natively. Any IHV wanting > to support TRIM on Win 7 would have to implement a method (i.e. filter > driver) to handle sending TRIM requests. Win 8 and later natively > supports TRIM. > > Thanks, > Ray > > -----Original Message----- > From: nvmewin-bounces at lists.openfabrics.org > [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Mike > Berhan > Sent: Wednesday, September 02, 2015 3:36 PM > To: 'Per Hansson'; nvmewin at lists.openfabrics.org > Subject: Re: [nvmewin] Win7 x86 NVMe compiled driver is old version > > In the Windows 7 storage stack, there is no UNMAP CDB sent down from > the class driver. That's only in Windows 8 and above. > > Mike > > -----Original Message----- > From: nvmewin-bounces at lists.openfabrics.org > [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Per > Hansson > Sent: Wednesday, September 2, 2015 12:35 PM > To: nvmewin at lists.openfabrics.org; nvmewin at lists.openfabrics.org > Subject: [nvmewin] Win7 x86 NVMe compiled driver is old version > > Hi, the version of the compiled NVMe driver for Win7 x86 is actually > v1.3.0 and not v1.4.0. > It for example seems to lack TRIM support. > > https://svn.openfabrics.org/svnrepo/nvmewin/releases/revision_1.4/inst > allati > ons/32-bit/Windows7/ > > Sincerely - Per Hansson > > _______________________________________________ > nvmewin mailing list > nvmewin at lists.openfabrics.org > http://lists.openfabrics.org/mailman/listinfo/nvmewin > > _______________________________________________ > nvmewin mailing list > nvmewin at lists.openfabrics.org > http://lists.openfabrics.org/mailman/listinfo/nvmewin From Alex.Chang at pmcs.com Fri Sep 11 13:13:28 2015 From: Alex.Chang at pmcs.com (Alex Chang) Date: Fri, 11 Sep 2015 20:13:28 +0000 Subject: [nvmewin] Zero Length for Security Receive and Security Send command In-Reply-To: <49158E750348AA499168FD41D88983606B7486D7@fmsmsx117.amr.corp.intel.com> References: <6irkn74hl73emw09fa9dey2n.1441175431148@email.android.com> <49158E750348AA499168FD41D88983606B7486D7@fmsmsx117.amr.corp.intel.com> Message-ID: Hi Ray, Sorry for the delay. PMC approves the patch. As for reviewing the future patches, I will leave it to Kwok to make the call. Thank you! Alex From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, September 08, 2015 10:40 AM To: Kwok Kong; Alex Chang Subject: RE: [nvmewin] Zero Length for Security Receive and Security Send command Hi Kwok/Alex, Hope all is going well. I have not heard back from either of you on the approval on the last patch. We are waiting on your feedback for final approval. Will you be able to review this, and future, patche(s)? Reviewing Company Status Samsung Approved PMC-Sierra Review In Progress HGST Approved Intel Approved Thanks, Ray From: Robles, Raymond C Sent: Tuesday, September 01, 2015 11:32 PM To: suman.p at samsung.com; nvmewin at lists.openfabrics.org; yun.wang at ulinktech.com; Judy Brock-SSI (judy.brock at ssi.samsung.com) Subject: RE: [nvmewin] Zero Length for Security Receive and Security Send command Thanks Suman! -------- Original message -------- From: SUMAN PRAKASH B > Date: 09/01/2015 7:06 PM (GMT-07:00) To: nvmewin at lists.openfabrics.org, yun.wang at ulinktech.com, "Robles, Raymond C" >, "Judy Brock-SSI (judy.brock at ssi.samsung.com)" > Subject: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Ray, SAMSUNG approves this patch. Thanks, Suman From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Tuesday, September 01, 2015 11:39 AM To: Thomas Freeman; Yun Wang; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Thanks Tom. Now just waiting on Samsung and PMC-Sierra. Reviewing Company Status Samsung Review In Progress PMC-Sierra Review In Progress HGST Approved Intel Approved After this patch, there are two patches in queue to be reviewed: 1. NVMe fuzz test fixes (Google) 2. Namespace management (Intel) Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Monday, August 31, 2015 11:41 AM To: Robles, Raymond C; Yun Wang; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, HGST approves your patch. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, August 27, 2015 1:04 PM To: Yun Wang >; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Intel has reviewed and tested your patch and approves your patch. Just need to hear back from the other reviewing companies. Reviewing Company Status Samsung Review In Progress PMC-Sierra Review In Progress HGST Review In Progress Intel Approved Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, August 24, 2015 2:14 PM To: Yun Wang; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Yun, Your patch is now in line to be reviewed. Reviewing Companies, Please review Yun’s patch for zero length Secure Send/Receive commands and provide feedback on or before September 4th. Thanks! Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, July 30, 2015 3:25 PM To: Yun Wang Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Thank you for your patch submission. There is one patch in front of yours. Once that patch has been reviewed and approved, your patch will be reviewed next. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Yun Wang Sent: Friday, July 24, 2015 6:00 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Zero Length for Security Receive and Security Send command Hi: Current OFA driver doesn’t allow zero length for Security Receive and Security Send command. Per NVMe spec., “Security Receive command with the Security Protocol field set to 00h shall return information about the security protocols supported by the controller. This command is used in the security discovery process and is not associated with a Security Send command. Refer to SPC-4 for the details of Security Protocol 00h and the SP Specific field”. Per SPC-4 spec., “a transfer length of zero specifies that no data transfer shall take place. This condition shall not be considered an error”, zero length of data transfer for Security Protocol 00h should be allowed. On the other hand, for some practices with other Security Protocol, zero length will be needed, too. This patch is to allow zero length of data transfer for Security Receive and Security Send command. It has been tested over Win8.1 x64 platform and works as expected. Please review and help merge it into the trunk. The password for the attachment is nvme_sec. Best Regards, Yun Wang ULINK Technology, Inc. Website: www.ulinktech.com<%20%20> Office: +1(408) 446-8455 Email: yun.wang at ulinktech.com [ulink logo 2] DISCLAIMER: The information contained in this message is confidential and may be legally privileged. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. [cid:image003.gif at 01D0EC93.A586FFE0] [Image removed by sender.] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: ~WRD000.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1628 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.gif Type: image/gif Size: 13168 bytes Desc: image003.gif URL: From raymond.c.robles at intel.com Fri Sep 11 13:23:00 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Fri, 11 Sep 2015 20:23:00 +0000 Subject: [nvmewin] Zero Length for Security Receive and Security Send command In-Reply-To: References: <6irkn74hl73emw09fa9dey2n.1441175431148@email.android.com> <49158E750348AA499168FD41D88983606B7486D7@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983606B74D167@fmsmsx117.amr.corp.intel.com> Thanks Alex. The patch from ULINK (Yun) for zero length Security Send/Receive has been approved and will be pushed before Monday. The next review is Google’s patch (Iulius) for fuzz testing. Reviewing companies, please review Google’s patch and provide your decision by 9/25. Thanks, Ray From: Alex Chang [mailto:Alex.Chang at pmcs.com] Sent: Friday, September 11, 2015 1:13 PM To: Robles, Raymond C; Kwok Kong; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Zero Length for Security Receive and Security Send command Hi Ray, Sorry for the delay. PMC approves the patch. As for reviewing the future patches, I will leave it to Kwok to make the call. Thank you! Alex From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, September 08, 2015 10:40 AM To: Kwok Kong; Alex Chang Subject: RE: [nvmewin] Zero Length for Security Receive and Security Send command Hi Kwok/Alex, Hope all is going well. I have not heard back from either of you on the approval on the last patch. We are waiting on your feedback for final approval. Will you be able to review this, and future, patche(s)? Reviewing Company Status Samsung Approved PMC-Sierra Review In Progress HGST Approved Intel Approved Thanks, Ray From: Robles, Raymond C Sent: Tuesday, September 01, 2015 11:32 PM To: suman.p at samsung.com; nvmewin at lists.openfabrics.org; yun.wang at ulinktech.com; Judy Brock-SSI (judy.brock at ssi.samsung.com) Subject: RE: [nvmewin] Zero Length for Security Receive and Security Send command Thanks Suman! -------- Original message -------- From: SUMAN PRAKASH B > Date: 09/01/2015 7:06 PM (GMT-07:00) To: nvmewin at lists.openfabrics.org, yun.wang at ulinktech.com, "Robles, Raymond C" >, "Judy Brock-SSI (judy.brock at ssi.samsung.com)" > Subject: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Ray, SAMSUNG approves this patch. Thanks, Suman From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Tuesday, September 01, 2015 11:39 AM To: Thomas Freeman; Yun Wang; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Thanks Tom. Now just waiting on Samsung and PMC-Sierra. Reviewing Company Status Samsung Review In Progress PMC-Sierra Review In Progress HGST Approved Intel Approved After this patch, there are two patches in queue to be reviewed: 1. NVMe fuzz test fixes (Google) 2. Namespace management (Intel) Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Monday, August 31, 2015 11:41 AM To: Robles, Raymond C; Yun Wang; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, HGST approves your patch. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, August 27, 2015 1:04 PM To: Yun Wang >; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Intel has reviewed and tested your patch and approves your patch. Just need to hear back from the other reviewing companies. Reviewing Company Status Samsung Review In Progress PMC-Sierra Review In Progress HGST Review In Progress Intel Approved Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, August 24, 2015 2:14 PM To: Yun Wang; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Yun, Your patch is now in line to be reviewed. Reviewing Companies, Please review Yun’s patch for zero length Secure Send/Receive commands and provide feedback on or before September 4th. Thanks! Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, July 30, 2015 3:25 PM To: Yun Wang Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Thank you for your patch submission. There is one patch in front of yours. Once that patch has been reviewed and approved, your patch will be reviewed next. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Yun Wang Sent: Friday, July 24, 2015 6:00 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Zero Length for Security Receive and Security Send command Hi: Current OFA driver doesn’t allow zero length for Security Receive and Security Send command. Per NVMe spec., “Security Receive command with the Security Protocol field set to 00h shall return information about the security protocols supported by the controller. This command is used in the security discovery process and is not associated with a Security Send command. Refer to SPC-4 for the details of Security Protocol 00h and the SP Specific field”. Per SPC-4 spec., “a transfer length of zero specifies that no data transfer shall take place. This condition shall not be considered an error”, zero length of data transfer for Security Protocol 00h should be allowed. On the other hand, for some practices with other Security Protocol, zero length will be needed, too. This patch is to allow zero length of data transfer for Security Receive and Security Send command. It has been tested over Win8.1 x64 platform and works as expected. Please review and help merge it into the trunk. The password for the attachment is nvme_sec. Best Regards, Yun Wang ULINK Technology, Inc. Website: www.ulinktech.com<%20%20> Office: +1(408) 446-8455 Email: yun.wang at ulinktech.com [ulink logo 2] DISCLAIMER: The information contained in this message is confidential and may be legally privileged. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. [cid:image003.gif at 01D0EC94.D51A9B30] [Image removed by sender.] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1628 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.gif Type: image/gif Size: 13168 bytes Desc: image003.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 823 bytes Desc: image004.jpg URL: From raymond.c.robles at intel.com Fri Sep 11 13:29:24 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Fri, 11 Sep 2015 20:29:24 +0000 Subject: [nvmewin] FW: NVME fuzz test fixes In-Reply-To: References: Message-ID: <49158E750348AA499168FD41D88983606B74D22A@fmsmsx117.amr.corp.intel.com> All, Here is the original patch from Google (Iuliu) for the WHCK fuzz tests. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Iuliu Rus Sent: Monday, August 03, 2015 1:37 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVME fuzz test fixes Hello, I have attached the fixes we (Google) did for the several crashes / corruptions exposed by the Windows HCK fuzztest.exe. We have tested this on qemu/ Server 2012 R2. The password on the zip is "nvme" :) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fuzz_fixes.zip Type: application/zip Size: 2048110 bytes Desc: fuzz_fixes.zip URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From judy.brock at ssi.samsung.com Fri Sep 11 22:03:10 2015 From: judy.brock at ssi.samsung.com (Judy Brock-SSI) Date: Sat, 12 Sep 2015 05:03:10 +0000 Subject: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers In-Reply-To: <49158E750348AA499168FD41D88983606B71B12F@fmsmsx117.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606B63477F@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B656163@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6697AD@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B669C18@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6EA959@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B71B12F@fmsmsx117.amr.corp.intel.com> Message-ID: <36E8D38D6B771A4BBDB1C0D800158A516C13BCB7@SSIEXCH-MB3.ssi.samsung.com> Does the Fuzz test fixes patch contain the fix for the race condition/synchronization FreeQList issue? We have seen it too. Thanks, Judy From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, August 24, 2015 2:15 PM To: Iuliu Rus Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Hi Iuliu, Your patch is now next in queue to be reviewed. Once the patch from ULINK Technology has been reviewed, your patch will be next. Thanks for your patience. Thanks Ray From: Robles, Raymond C Sent: Monday, August 03, 2015 4:32 PM To: 'Iuliu Rus' Cc: nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Thanks Iuliu. Your patch is third in line right now (two patches ahead of you). I’ll go ahead and schedule an OFA meeting to discuss a few times, including migrating to github. Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Monday, August 03, 2015 1:40 PM To: Robles, Raymond C Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Thank you, I have sent the first patch containing the fuzz test fixes. We really hope you will consider patch process changes. Sending zips across is error prone as somebody will have to manually merge changes. Besides the time spent, we run the risk of regressing some earlier change and negate half of the benefits of a source control. Also, dealing with code reviews is harder than it needs to be (as github has them associated with the precise code line and so on). On Thu, Jul 30, 2015 at 2:25 PM, Robles, Raymond C > wrote: Hi Iuliu, I thought I responded to this email, but in case I didn’t…. For now, I would suggest separating the patch into smaller patches. The use of SVN is not dictated by the NVMeWin group, but rather the OFA (Open Fabrics Alliance) website, and its administrators. If there were/are enough requests to migrate to github, I could call a meeting to discuss moving to another host website. But the process would not be quick, especially since we are starting to get patches for the end of year release. Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Thursday, June 25, 2015 12:06 PM To: Robles, Raymond C Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Raymond, we are running the windows HCK fuzz test on the driver and it exposes several crashes. Also, on SCSIOP_START_STOP_UNIT it looks like SntiTransitionPowerState builds an io which it never submits, causing Windows to eventually reset the adapter. Given that some of these fuzz crashes are potential security issues, we are getting ready to submit the patch next week. However it is rather big and the current patch submission process doesn't work that well. We would like to break it into separate changes, but with zipped thrunk this is not possible. Is there any way to switch this over to github so we can use pull requests instead? Or, should we do separate submissions for now? On Tue, Jun 2, 2015 at 3:35 PM, Iuliu Rus > wrote: Raymond, given this, project we are going to wait for QEMU to accept the virtualization extensions first (http://git.infradead.org/users/kbusch/qemu-nvme.git/commit/162ec6479447abbd76308f831f36703aa3acc485), then submit our payload which includes what we previously discussed and the windows implementation for the nvme doorbell extensions. On Fri, May 15, 2015 at 11:38 AM, Robles, Raymond C > wrote: Hi Iuliu, The process for submitting a patch is quite simple (by design). The steps are as follows: 1. Download the current latest trunk source via an SVN client (i.e. TortoiseSVN). I assume you’ve already done this. 2. In the Releases folder, under a specific release, there are readme.txt files that explain the build environment needed. Insure you can compile the trunk with the recommended tool/build set. 3. Port your changes over to the trunk. 4. Unit test your changes on the trunk source. 5. Run the required testing outlined in the file attached in this email and insure all tests are passing. 6. Send an email with the trunk source zipped (with your ported changes) to this email distribution list. 7. The three reviewing companies will review your changes and also run the tests in the file. 8. If all looks good, then the source maintainer will merge your changes to the trunk, and create a tag. 9. If there are any question/comments that require a modifications to you patch, then go back to step 4 after you’ve made any changes and complete the process again. Let me know if you have any further questions. Feel free to add both patches into a single submission. You should be able to download all tools necessary outlined in the file. Let us know if you need assistance. Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Thursday, May 14, 2015 11:02 PM To: Robles, Raymond C Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Can you please point me to the instructions on how to send the patch? As for the free q list issue, we enabled driver verifier and under stress it bugchecked in RtlpCheckListEntry. On Thu, May 14, 2015 at 10:52 PM, Robles, Raymond C > wrote: Hello, We always welcome companies to submit patches for candidate features. No other company has volunteered for concurrent channels at this time. We would gladly welcome your patch at your earliest convenience. The first release for 2015 is planned for ~August/September... would you like to volunteer for this patch prior to this release? As for a race condition synchronization fix for FreeQList, could you please describe the issue you were seeing and how you addressed it? Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Thursday, May 14, 2015 7:43 PM To: Robles, Raymond C Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers Hello, We are the google compute engine team and we already have Concurrent channels working. We're still figuring out how we can integrate between our internal repo and svn. Do you still need this feature? We also have a synchronization fix for a race that corrupted FreeQList. On Thu, May 7, 2015 at 3:46 PM, Robles, Raymond C > wrote: All, I just wanted to send out a quick update on the release plans for 2015. We’ve had two more companies volunteer to submit patches this year: Samsung (Suman) and HGST (Tom). Thank you to both companies for volunteering! Here is the updated release plan for 2015. Unfortunately, some of the patch submissions will be a little later than originally planned. Therefore, I would like to ask the question: is everyone ok if we push the first release out until end of August to allow for more patches to be submitted? You can response publicly or just to me. Other alternatives would include just having smaller releases at different cadences. I’m open to any ideas since there are still many requests for features that have claimed for patch submission. 2015 Release #1 (Q2/Q3 – 2015) Feature Description Submitter Date Concurrent Channels Start I/O Concurrent Channels allows StartIo to be called in parallel resulting in improved IOPS. Perf Opts Instead of learning cores, use perf opts. Shave off 2 seconds in init code… using Storport initialize perf opts. No need for source core interrupt steering code in driver. Samsung (Suman) End of June Win 8.1 Timers Storport Notification usage. Hot plug and IOCTLs, this does not work, for Win8.1… StorportRequestTimer() function needed. Samsung (Suman) End of July CFS Bit Monitoring CFS bit monitoring and handling. Look into adding additional handling code just to monitor CSTS.CFS. EOL - Read Only Read only support for devices at EOL. Detection at init, hot plug, or run-time. Samsung (Suman) End of August Namespace Mgmt Namespace management - creation and deletion of namespaces. Intel (Carolyn) End of June WHQL WHQL test suite run (any bug fixes). 2015 Release #2 (Q4 – 2015) Feature Description Submitter Date Multi-Path Multipath feature set from 1.1 spec (Multi-path I/O, Namespace Sharing, Reservations) HGST (Tom) Mid-November RTD3 Active/idle RTD3 Temp Thresholds Temperature thresholds (Get/Set Feature and AER trigger) Live FW Update Live firmware update Atomicity Atomicity Enhancements Win 10 Win 10 support (push to Q4 release) SNTL SNTL 1.5 doc updates HGST (Tom) End of August WHQL WHQL test suite run (any bug fixes) - for each release of OFA Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, April 09, 2015 5:29 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers All, As we enter Q2, I’m happy to announce that we a have a very good feature plan in place for both Q2 and Q4 releases in 2015 of the OFA driver. The list of requested features is included below for final review. I would like to formally ask for volunteers for patch submissions. As of today, there are no volunteers for any of the below patches. Intel would like to start with the volunteering… we will volunteer to provide the namespace management patch. 2015 Release #1 (Q2/Q3 – 2015) Feature Description Submitter Date Concurrent Channels Start I/O Concurrent Channels allows StartIo to be called in parallel resulting in improved IOPS. Perf Opts Instead of learning cores, use perf opts. Shave off 2 seconds in init code… using Storport initialize perf opts. No need for source core interrupt steering code in driver. Samsung (Suman) End of June Win 8.1 Timers Storport Notification usage. Hot plug and IOCTLs, this does not work, for Win8.1… StorportRequestTimer() function needed. Samsung (Suman) End of July CFS Bit Monitoring CFS bit monitoring and handling. Look into adding additional handling code just to monitor CSTS.CFS. EOL - Read Only Read only support for devices at EOL. Detection at init, hot plug, or run-time. Samsung (Suman) End of August Namespace Mgmt Namespace management - creation and deletion of namespaces. Intel (Carolyn) End of June WHQL WHQL test suite run (any bug fixes). 2015 Release #2 (Q4 – 2015) Feature Description Submitter Date Multi-Path Multipath feature set from 1.1 spec (Multi-path I/O, Namespace Sharing, Reservations) HGST (Tom) Mid-November RTD3 Active/idle RTD3 Temp Thresholds Temperature thresholds (Get/Set Feature and AER trigger) Live FW Update Live firmware update Atomicity Atomicity Enhancements Win 10 Win 10 support (push to Q4 release) SNTL SNTL 1.5 doc updates HGST (Tom) End of August WHQL WHQL test suite run (any bug fixes) - for each release of OFA Thanks, Ray Raymond C. Robles NSG ISE Host Storage Software Intel Corporation Office: 480-554-2600 Mobile: 480-399-0645 _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin -------------- next part -------------- An HTML attachment was scrubbed... URL: From per at techspot.com Mon Sep 14 07:04:33 2015 From: per at techspot.com (Per Hansson) Date: Mon, 14 Sep 2015 16:04:33 +0200 Subject: [nvmewin] Win7 x86 NVMe compiled driver is old version In-Reply-To: <49158E750348AA499168FD41D88983606B74B29D@fmsmsx117.amr.corp.intel.com> References: <8f2ec82818039be9a2d85858b5f76bcc@techspot.com> <016401d0e5cf$b6753530$235f9f90$@bustrace.com> <49158E750348AA499168FD41D88983606B7447C9@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B74B29D@fmsmsx117.amr.corp.intel.com> Message-ID: <12662aaedc471e01153228b0188abf42@techspot.com> Hi, with a fresh Win7 SP1 install and driver chosen during installation it shows up as 1.3.0.0 in device manager. See screenshot: http://img.techpowerup.org/150914/Win7x86-NVMe_1-4-0.png Sincerely - Per Hansson On 2015-09-10 03:00, Robles, Raymond C wrote: > Hi Per, > > I had to go back and check with the one of the companies who managed > the releases. It appears it was an oversight in the .inf file. > However, the Visual Studio project/solution has been modified such > that the compiled driver will override the .inf and display 1.4.0.0 in > the OS. > > Were you able to verify that if the driver if this driver is > installed, the revision shows as 1.4.0.0? If not, and you see 1.3.0.0 > or any other version in the OS, please let me know. > > Thanks, > Ray > > -----Original Message----- > From: Per Hansson [mailto:per at techspot.com] > Sent: Thursday, September 03, 2015 4:46 AM > To: Robles, Raymond C; Robles, Raymond C > Cc: 'Mike Berhan'; nvmewin at lists.openfabrics.org > Subject: RE: [nvmewin] Win7 x86 NVMe compiled driver is old version > > Hi, I did not know that Win7 lacks native TRIM support, thanks for the > info. > Question remains though why there is a compiled v1.3.0 version of the > driver in the 32-bit folder of Win7 in the revision 1.4 release tree? > (It's 1.4.0 for 64-bit Win7) > > See version string here: > https://svn.openfabrics.org/svnrepo/nvmewin/releases/revision_1.4/installations/32-bit/Windows7/nvme.inf > > Sincerely - Per Hansson > > On 2015-09-03 01:03, Robles, Raymond C wrote: >> Mike is correct. Win 7 does not support TRIM natively. Any IHV wanting >> to support TRIM on Win 7 would have to implement a method (i.e. filter >> driver) to handle sending TRIM requests. Win 8 and later natively >> supports TRIM. >> >> Thanks, >> Ray >> >> -----Original Message----- >> From: nvmewin-bounces at lists.openfabrics.org >> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Mike >> Berhan >> Sent: Wednesday, September 02, 2015 3:36 PM >> To: 'Per Hansson'; nvmewin at lists.openfabrics.org >> Subject: Re: [nvmewin] Win7 x86 NVMe compiled driver is old version >> >> In the Windows 7 storage stack, there is no UNMAP CDB sent down from >> the class driver. That's only in Windows 8 and above. >> >> Mike >> >> -----Original Message----- >> From: nvmewin-bounces at lists.openfabrics.org >> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Per >> Hansson >> Sent: Wednesday, September 2, 2015 12:35 PM >> To: nvmewin at lists.openfabrics.org; nvmewin at lists.openfabrics.org >> Subject: [nvmewin] Win7 x86 NVMe compiled driver is old version >> >> Hi, the version of the compiled NVMe driver for Win7 x86 is actually >> v1.3.0 and not v1.4.0. >> It for example seems to lack TRIM support. >> >> https://svn.openfabrics.org/svnrepo/nvmewin/releases/revision_1.4/inst >> allati >> ons/32-bit/Windows7/ >> >> Sincerely - Per Hansson >> >> _______________________________________________ >> nvmewin mailing list >> nvmewin at lists.openfabrics.org >> http://lists.openfabrics.org/mailman/listinfo/nvmewin >> >> _______________________________________________ >> nvmewin mailing list >> nvmewin at lists.openfabrics.org >> http://lists.openfabrics.org/mailman/listinfo/nvmewin From iuliur at google.com Mon Sep 14 08:18:16 2015 From: iuliur at google.com (Iuliu Rus) Date: Mon, 14 Sep 2015 08:18:16 -0700 Subject: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch volunteers In-Reply-To: <36E8D38D6B771A4BBDB1C0D800158A516C13BCB7@SSIEXCH-MB3.ssi.samsung.com> References: <49158E750348AA499168FD41D88983606B63477F@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B656163@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6697AD@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B669C18@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B6EA959@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B71B12F@fmsmsx117.amr.corp.intel.com> <36E8D38D6B771A4BBDB1C0D800158A516C13BCB7@SSIEXCH-MB3.ssi.samsung.com> Message-ID: No, it does not. We will submit it at a later date. On Fri, Sep 11, 2015 at 10:03 PM, Judy Brock-SSI wrote: > Does the Fuzz test fixes patch contain the fix for the race > condition/synchronization FreeQList issue? We have seen it too. > > > > Thanks, > > Judy > > > > *From:* nvmewin-bounces at lists.openfabrics.org [mailto: > nvmewin-bounces at lists.openfabrics.org] *On Behalf Of *Robles, Raymond C > *Sent:* Monday, August 24, 2015 2:15 PM > *To:* Iuliu Rus > *Cc:* nvmewin at lists.openfabrics.org > *Subject:* Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for > patch volunteers > > > > Hi Iuliu, > > > > Your patch is now next in queue to be reviewed. Once the patch from ULINK > Technology has been reviewed, your patch will be next. > > > > Thanks for your patience. > > > > Thanks > > Ray > > > > *From:* Robles, Raymond C > *Sent:* Monday, August 03, 2015 4:32 PM > *To:* 'Iuliu Rus' > *Cc:* nvmewin at lists.openfabrics.org > *Subject:* RE: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for > patch volunteers > > > > Thanks Iuliu. Your patch is third in line right now (two patches ahead of > you). > > > > I’ll go ahead and schedule an OFA meeting to discuss a few times, > including migrating to github. > > > > Thanks, > Ray > > > > *From:* Iuliu Rus [mailto:iuliur at google.com ] > *Sent:* Monday, August 03, 2015 1:40 PM > *To:* Robles, Raymond C > *Cc:* nvmewin at lists.openfabrics.org > *Subject:* Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for > patch volunteers > > > > Thank you, > > I have sent the first patch containing the fuzz test fixes. > > We really hope you will consider patch process changes. Sending zips > across is error prone as somebody will have to manually merge changes. > Besides the time spent, we run the risk of regressing some earlier change > and negate half of the benefits of a source control. Also, dealing with > code reviews is harder than it needs to be (as github has them associated > with the precise code line and so on). > > > > On Thu, Jul 30, 2015 at 2:25 PM, Robles, Raymond C < > raymond.c.robles at intel.com> wrote: > > Hi Iuliu, > > > > I thought I responded to this email, but in case I didn’t…. > > > > For now, I would suggest separating the patch into smaller patches. The > use of SVN is not dictated by the NVMeWin group, but rather the OFA (Open > Fabrics Alliance) website, and its administrators. > > > > If there were/are enough requests to migrate to github, I could call a > meeting to discuss moving to another host website. But the process would > not be quick, especially since we are starting to get patches for the end > of year release. > > > > Thanks, > Ray > > > > *From:* Iuliu Rus [mailto:iuliur at google.com] > *Sent:* Thursday, June 25, 2015 12:06 PM > > > *To:* Robles, Raymond C > *Cc:* nvmewin at lists.openfabrics.org > *Subject:* Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for > patch volunteers > > > > Raymond, we are running the windows HCK fuzz test on the driver and it > exposes several crashes. Also, on SCSIOP_START_STOP_UNIT it looks > like SntiTransitionPowerState builds an io which it never submits, causing > Windows to eventually reset the adapter. > > Given that some of these fuzz crashes are potential security issues, we > are getting ready to submit the patch next week. However it is rather big > and the current patch submission process doesn't work that well. We would > like to break it into separate changes, but with zipped thrunk this is not > possible. Is there any way to switch this over to github so we can use pull > requests instead? Or, should we do separate submissions for now? > > > > On Tue, Jun 2, 2015 at 3:35 PM, Iuliu Rus wrote: > > Raymond, given this, project we are going to wait for QEMU to accept the > virtualization extensions first ( > http://git.infradead.org/users/kbusch/qemu-nvme.git/commit/162ec6479447abbd76308f831f36703aa3acc485), > then submit our payload which includes what we previously discussed and the > windows implementation for the nvme doorbell extensions. > > > > On Fri, May 15, 2015 at 11:38 AM, Robles, Raymond C < > raymond.c.robles at intel.com> wrote: > > Hi Iuliu, > > > > The process for submitting a patch is quite simple (by design). The steps > are as follows: > > > > 1. Download the current latest trunk source via an SVN client (i.e. > TortoiseSVN). I assume you’ve already done this. > > 2. In the Releases folder, under a specific release, there are > readme.txt files that explain the build environment needed. Insure you can > compile the trunk with the recommended tool/build set. > > 3. Port your changes over to the trunk. > > 4. Unit test your changes on the trunk source. > > 5. Run the required testing outlined in the file attached in this > email and insure all tests are passing. > > 6. Send an email with the trunk source zipped (with your ported > changes) to this email distribution list. > > 7. The three reviewing companies will review your changes and also > run the tests in the file. > > 8. If all looks good, then the source maintainer will merge your > changes to the trunk, and create a tag. > > 9. If there are any question/comments that require a modifications > to you patch, then go back to step 4 after you’ve made any changes and > complete the process again. > > > > Let me know if you have any further questions. Feel free to add both > patches into a single submission. > > > > You should be able to download all tools necessary outlined in the file. > Let us know if you need assistance. > > > > Thanks, > > Ray > > > > *From:* Iuliu Rus [mailto:iuliur at google.com] > *Sent:* Thursday, May 14, 2015 11:02 PM > > > *To:* Robles, Raymond C > *Cc:* nvmewin at lists.openfabrics.org > *Subject:* Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for > patch volunteers > > > > Can you please point me to the instructions on how to send the patch? > > As for the free q list issue, we enabled driver verifier and under stress > it bugchecked in RtlpCheckListEntry. > > > > On Thu, May 14, 2015 at 10:52 PM, Robles, Raymond C < > raymond.c.robles at intel.com> wrote: > > Hello, > > > > We always welcome companies to submit patches for candidate features. No > other company has volunteered for concurrent channels at this time. We > would gladly welcome your patch at your earliest convenience. The first > release for 2015 is planned for ~August/September... would you like to > volunteer for this patch prior to this release? > > > > As for a race condition synchronization fix for FreeQList, could you > please describe the issue you were seeing and how you addressed it? > > > > Thanks, > > Ray > > > > *From:* Iuliu Rus [mailto:iuliur at google.com] > *Sent:* Thursday, May 14, 2015 7:43 PM > *To:* Robles, Raymond C > *Cc:* nvmewin at lists.openfabrics.org > *Subject:* Re: [nvmewin] OFA Release Plan: Release #1 2015 -- Call for > patch volunteers > > > > Hello, > > We are the google compute engine team and we already have Concurrent > channels working. We're still figuring out how we can integrate between our > internal repo and svn. > > Do you still need this feature? > > We also have a synchronization fix for a race that corrupted FreeQList. > > > > On Thu, May 7, 2015 at 3:46 PM, Robles, Raymond C < > raymond.c.robles at intel.com> wrote: > > All, > > > > I just wanted to send out a quick update on the release plans for 2015. > We’ve had two more companies volunteer to submit patches this year: Samsung > (Suman) and HGST (Tom). Thank you to both companies for volunteering! > > > > Here is the updated release plan for 2015. Unfortunately, some of the > patch submissions will be a little later than originally planned. > Therefore, I would like to ask the question: *is everyone ok if we push > the first release out until end of August to allow for more patches to be > submitted?* You can response publicly or just to me. > > > > Other alternatives would include just having smaller releases at different > cadences. I’m open to any ideas since there are still many requests for > features that have claimed for patch submission. > > > > > > *2015 Release #1 (Q2/Q3 – 2015)* > > > > *Feature* > > *Description* > > *Submitter* > > *Date* > > Concurrent Channels > > Start I/O Concurrent Channels allows StartIo to be called in parallel > resulting in improved IOPS. > > > > > > Perf Opts > > Instead of learning cores, use perf opts. Shave off 2 seconds in init > code… using Storport initialize perf opts. No need for source core > interrupt steering code in driver. > > Samsung (Suman) > > End of June > > Win 8.1 Timers > > Storport Notification usage. Hot plug and IOCTLs, this does not work, for > Win8.1… StorportRequestTimer() function needed. > > Samsung (Suman) > > End of July > > CFS Bit Monitoring > > CFS bit monitoring and handling. Look into adding additional handling code > just to monitor CSTS.CFS. > > > > > > EOL - Read Only > > Read only support for devices at EOL. Detection at init, hot plug, or > run-time. > > Samsung (Suman) > > End of August > > Namespace Mgmt > > Namespace management - creation and deletion of namespaces. > > Intel (Carolyn) > > End of June > > WHQL > > WHQL test suite run (any bug fixes). > > > > > > > > > > *2015 Release #2 (Q4 – 2015)* > > > > *Feature* > > *Description* > > *Submitter* > > *Date* > > Multi-Path > > Multipath feature set from 1.1 spec (Multi-path I/O, Namespace Sharing, > Reservations) > > HGST (Tom) > > Mid-November > > RTD3 > > Active/idle RTD3 > > > > > > Temp Thresholds > > Temperature thresholds (Get/Set Feature and AER trigger) > > > > > > Live FW Update > > Live firmware update > > > > > > Atomicity > > Atomicity Enhancements > > > > > > Win 10 > > Win 10 support (push to Q4 release) > > > > > > SNTL > > SNTL 1.5 doc updates > > HGST (Tom) > > End of August > > WHQL > > WHQL test suite run (any bug fixes) - for each release of OFA > > > > > > > > Thanks, > > Ray > > > > *From:* nvmewin-bounces at lists.openfabrics.org [mailto: > nvmewin-bounces at lists.openfabrics.org] *On Behalf Of *Robles, Raymond C > *Sent:* Thursday, April 09, 2015 5:29 PM > *To:* nvmewin at lists.openfabrics.org > *Subject:* [nvmewin] OFA Release Plan: Release #1 2015 -- Call for patch > volunteers > > > > All, > > > > As we enter Q2, I’m happy to announce that we a have a very good feature > plan in place for both Q2 and Q4 releases in 2015 of the OFA driver. The > list of requested features is included below for final review. > > > > I would like to formally ask for volunteers for patch submissions. As of > today, there are no volunteers for any of the below patches. > > > > Intel would like to start with the volunteering… we will volunteer to > provide the namespace management patch. > > > > *2015 Release #1 (Q2/Q3 – 2015)* > > > > *Feature* > > *Description* > > *Submitter* > > *Date* > > Concurrent Channels > > Start I/O Concurrent Channels allows StartIo to be called in parallel > resulting in improved IOPS. > > > > > > Perf Opts > > Instead of learning cores, use perf opts. Shave off 2 seconds in init > code… using Storport initialize perf opts. No need for source core > interrupt steering code in driver. > > Samsung (Suman) > > End of June > > Win 8.1 Timers > > Storport Notification usage. Hot plug and IOCTLs, this does not work, for > Win8.1… StorportRequestTimer() function needed. > > Samsung (Suman) > > End of July > > CFS Bit Monitoring > > CFS bit monitoring and handling. Look into adding additional handling code > just to monitor CSTS.CFS. > > > > > > EOL - Read Only > > Read only support for devices at EOL. Detection at init, hot plug, or > run-time. > > Samsung (Suman) > > End of August > > Namespace Mgmt > > Namespace management - creation and deletion of namespaces. > > Intel (Carolyn) > > End of June > > WHQL > > WHQL test suite run (any bug fixes). > > > > > > > > > > *2015 Release #2 (Q4 – 2015)* > > > > *Feature* > > *Description* > > *Submitter* > > *Date* > > Multi-Path > > Multipath feature set from 1.1 spec (Multi-path I/O, Namespace Sharing, > Reservations) > > HGST (Tom) > > Mid-November > > RTD3 > > Active/idle RTD3 > > > > > > Temp Thresholds > > Temperature thresholds (Get/Set Feature and AER trigger) > > > > > > Live FW Update > > Live firmware update > > > > > > Atomicity > > Atomicity Enhancements > > > > > > Win 10 > > Win 10 support (push to Q4 release) > > > > > > SNTL > > SNTL 1.5 doc updates > > HGST (Tom) > > End of August > > WHQL > > WHQL test suite run (any bug fixes) - for each release of OFA > > > > > > > > > > Thanks, > > Ray > > > > *Raymond C. Robles* > > NSG ISE Host Storage Software > > Intel Corporation > > Office: 480-554-2600 > > Mobile: 480-399-0645 > > > > > _______________________________________________ > nvmewin mailing list > nvmewin at lists.openfabrics.org > http://lists.openfabrics.org/mailman/listinfo/nvmewin > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yun.wang at ulinktech.com Mon Sep 14 09:04:59 2015 From: yun.wang at ulinktech.com (Yun Wang) Date: Mon, 14 Sep 2015 09:04:59 -0700 Subject: [nvmewin] Zero Length for Security Receive and Security Send command In-Reply-To: <49158E750348AA499168FD41D88983606B74D167@fmsmsx117.amr.corp.intel.com> References: <6irkn74hl73emw09fa9dey2n.1441175431148@email.android.com> <49158E750348AA499168FD41D88983606B7486D7@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B74D167@fmsmsx117.amr.corp.intel.com> Message-ID: <011a01d0ef07$1d2bbe80$57833b80$@wang@ulinktech.com> Hi: Thanks all for the review and approval. Best Regards, Yun Wang ULINK Technology, Inc. | http://www.ulinktech.com/| +1(408) 446-8455 From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, September 11, 2015 1:23 PM To: 'Alex Chang'; Kwok Kong; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Thanks Alex. The patch from ULINK (Yun) for zero length Security Send/Receive has been approved and will be pushed before Monday. The next review is Google’s patch (Iulius) for fuzz testing. Reviewing companies, please review Google’s patch and provide your decision by 9/25. Thanks, Ray From: Alex Chang [mailto:Alex.Chang at pmcs.com] Sent: Friday, September 11, 2015 1:13 PM To: Robles, Raymond C; Kwok Kong; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Zero Length for Security Receive and Security Send command Hi Ray, Sorry for the delay. PMC approves the patch. As for reviewing the future patches, I will leave it to Kwok to make the call. Thank you! Alex From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, September 08, 2015 10:40 AM To: Kwok Kong; Alex Chang Subject: RE: [nvmewin] Zero Length for Security Receive and Security Send command Hi Kwok/Alex, Hope all is going well. I have not heard back from either of you on the approval on the last patch. We are waiting on your feedback for final approval. Will you be able to review this, and future, patche(s)? Reviewing Company Status Samsung Approved PMC-Sierra Review In Progress HGST Approved Intel Approved Thanks, Ray From: Robles, Raymond C Sent: Tuesday, September 01, 2015 11:32 PM To: suman.p at samsung.com; nvmewin at lists.openfabrics.org; yun.wang at ulinktech.com; Judy Brock-SSI (judy.brock at ssi.samsung.com) Subject: RE: [nvmewin] Zero Length for Security Receive and Security Send command Thanks Suman! -------- Original message -------- From: SUMAN PRAKASH B Date: 09/01/2015 7:06 PM (GMT-07:00) To: nvmewin at lists.openfabrics.org, yun.wang at ulinktech.com, "Robles, Raymond C" , "Judy Brock-SSI (judy.brock at ssi.samsung.com)" Subject: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Ray, SAMSUNG approves this patch. Thanks, Suman From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Tuesday, September 01, 2015 11:39 AM To: Thomas Freeman; Yun Wang; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Thanks Tom. Now just waiting on Samsung and PMC-Sierra. Reviewing Company Status Samsung Review In Progress PMC-Sierra Review In Progress HGST Approved Intel Approved After this patch, there are two patches in queue to be reviewed: 1. NVMe fuzz test fixes (Google) 2. Namespace management (Intel) Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Monday, August 31, 2015 11:41 AM To: Robles, Raymond C; Yun Wang; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, HGST approves your patch. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 HGST_Logo_email 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, August 27, 2015 1:04 PM To: Yun Wang ; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Intel has reviewed and tested your patch and approves your patch. Just need to hear back from the other reviewing companies. Reviewing Company Status Samsung Review In Progress PMC-Sierra Review In Progress HGST Review In Progress Intel Approved Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, August 24, 2015 2:14 PM To: Yun Wang; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Yun, Your patch is now in line to be reviewed. Reviewing Companies, Please review Yun’s patch for zero length Secure Send/Receive commands and provide feedback on or before September 4th. Thanks! Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, July 30, 2015 3:25 PM To: Yun Wang Cc: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Zero Length for Security Receive and Security Send command Hi Yun, Thank you for your patch submission. There is one patch in front of yours. Once that patch has been reviewed and approved, your patch will be reviewed next. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Yun Wang Sent: Friday, July 24, 2015 6:00 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Zero Length for Security Receive and Security Send command Hi: Current OFA driver doesn’t allow zero length for Security Receive and Security Send command. Per NVMe spec., “Security Receive command with the Security Protocol field set to 00h shall return information about the security protocols supported by the controller. This command is used in the security discovery process and is not associated with a Security Send command. Refer to SPC-4 for the details of Security Protocol 00h and the SP Specific field”. Per SPC-4 spec., “a transfer length of zero specifies that no data transfer shall take place. This condition shall not be considered an error”, zero length of data transfer for Security Protocol 00h should be allowed. On the other hand, for some practices with other Security Protocol, zero length will be needed, too. This patch is to allow zero length of data transfer for Security Receive and Security Send command. It has been tested over Win8.1 x64 platform and works as expected. Please review and help merge it into the trunk. The password for the attachment is nvme_sec. Best Regards, Yun Wang ULINK Technology, Inc. Website: www.ulinktech.com Office: +1(408) 446-8455 Email: yun.wang at ulinktech.com ulink logo 2 DISCLAIMER: The information contained in this message is confidential and may be legally privileged. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. Image removed by sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1628 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.gif Type: image/gif Size: 13168 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: From thomas.freeman at hgst.com Mon Sep 14 13:41:35 2015 From: thomas.freeman at hgst.com (Thomas Freeman) Date: Mon, 14 Sep 2015 20:41:35 +0000 Subject: [nvmewin] FW: NVME fuzz test fixes In-Reply-To: <49158E750348AA499168FD41D88983606B74D22A@fmsmsx117.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606B74D22A@fmsmsx117.amr.corp.intel.com> Message-ID: Iuliu, The changes look good. I have just a few comments. 1. nvmeSnti.C/Line 1157 – memset(pResponseBuffer, 0, allocLength); This was added to the comment, but it’s not clear why. I suspect it is an accidental addition. If so, this should be removed. 2. nvmeSnti.c/Line 1519 – Since the Lun value is actually written to the second byte of the entry, the comparison should be: if (lunIdDataOffset + SINGLE_LVL_LUN_OFFSET >= allocLength) As an example, test with a buffer size of 0x11. Without this change, the driver will actually write the byte after the allocated buffer. 3. nvmeSnti.c/Line 2652 & 2669. Your change handles the case where there is no data buffer. But, it does not handle the case where the buffer is smaller than sizeof(DESCRIPTOR_FORMAT_SENSE_DATA). With a small buffer allocation, these writes would access beyond the allocated buffer pSenseData->ErrorCode = FIXED_SENSE_DATA; pSenseData->SenseKey = SCSI_SENSE_NO_SENSE; pSenseData->AdditionalSenseLength = FIXED_SENSE_DATA_ADD_LENGTH; pSenseData->AdditionalSenseCode = SCSI_ADSENSE_NO_SENSE; pSenseData->AdditionalSenseCodeQualifier = 0; Regards, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, September 11, 2015 3:29 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] FW: NVME fuzz test fixes All, Here is the original patch from Google (Iuliu) for the WHCK fuzz tests. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Iuliu Rus Sent: Monday, August 03, 2015 1:37 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVME fuzz test fixes Hello, I have attached the fixes we (Google) did for the several crashes / corruptions exposed by the Windows HCK fuzztest.exe. We have tested this on qemu/ Server 2012 R2. The password on the zip is "nvme" :) HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: From Uma.Parepalli at skhms.com Mon Sep 14 17:12:32 2015 From: Uma.Parepalli at skhms.com (Uma Parepalli) Date: Tue, 15 Sep 2015 00:12:32 +0000 Subject: [nvmewin] FW: NVME fuzz test fixes In-Reply-To: References: <49158E750348AA499168FD41D88983606B74D22A@fmsmsx117.amr.corp.intel.com> Message-ID: <6497563508a04123ace3fa439cd101cd@N111XMB0240.skhms.com> Just curious, do you see the same issues if you use the standard Windows inbox driver? Thank you, Uma Uma Parepalli uma.parepalli at skhms.com Cell: 408 805 9260 SK Hynix Memory Solutions, 3103 N 1st St, San Jose, CA 95134 From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Thomas Freeman Sent: Monday, September 14, 2015 1:42 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org; uliur at google.com Subject: Re: [nvmewin] FW: NVME fuzz test fixes Iuliu, The changes look good. I have just a few comments. 1. nvmeSnti.C/Line 1157 – memset(pResponseBuffer, 0, allocLength); This was added to the comment, but it’s not clear why. I suspect it is an accidental addition. If so, this should be removed. 2. nvmeSnti.c/Line 1519 – Since the Lun value is actually written to the second byte of the entry, the comparison should be: if (lunIdDataOffset + SINGLE_LVL_LUN_OFFSET >= allocLength) As an example, test with a buffer size of 0x11. Without this change, the driver will actually write the byte after the allocated buffer. 3. nvmeSnti.c/Line 2652 & 2669. Your change handles the case where there is no data buffer. But, it does not handle the case where the buffer is smaller than sizeof(DESCRIPTOR_FORMAT_SENSE_DATA). With a small buffer allocation, these writes would access beyond the allocated buffer pSenseData->ErrorCode = FIXED_SENSE_DATA; pSenseData->SenseKey = SCSI_SENSE_NO_SENSE; pSenseData->AdditionalSenseLength = FIXED_SENSE_DATA_ADD_LENGTH; pSenseData->AdditionalSenseCode = SCSI_ADSENSE_NO_SENSE; pSenseData->AdditionalSenseCodeQualifier = 0; Regards, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, September 11, 2015 3:29 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] FW: NVME fuzz test fixes All, Here is the original patch from Google (Iuliu) for the WHCK fuzz tests. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Iuliu Rus Sent: Monday, August 03, 2015 1:37 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVME fuzz test fixes Hello, I have attached the fixes we (Google) did for the several crashes / corruptions exposed by the Windows HCK fuzztest.exe. We have tested this on qemu/ Server 2012 R2. The password on the zip is "nvme" :) HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. The information contained in this e-mail is considered confidential of SK hynix memory solutions Inc. and intended only for the persons addressed or copied in this e-mail. Any unauthorized use, dissemination of the information, or copying of this message is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: From thomas.freeman at hgst.com Tue Sep 15 08:04:10 2015 From: thomas.freeman at hgst.com (Thomas Freeman) Date: Tue, 15 Sep 2015 15:04:10 +0000 Subject: [nvmewin] FW: NVME fuzz test fixes In-Reply-To: <6497563508a04123ace3fa439cd101cd@N111XMB0240.skhms.com> References: <49158E750348AA499168FD41D88983606B74D22A@fmsmsx117.amr.corp.intel.com> <6497563508a04123ace3fa439cd101cd@N111XMB0240.skhms.com> Message-ID: Uma, With the inbox driver installed, using a variety of buffer sizes, I issued Report Luns to a device with 2 namespaces. Prior to issuing the command, I initialized my buffer with all 0xFF’s so I could see what bytes were being changed. Buffer size / Result 0x3 No data was written to the buffer – the buffer remained all 0xFF’s. 0x4, 0xF, 0x11, 0x17 Only the length field (0x00000010) was written 0x18 - All data was written as follows: 00000010 FFFFFFFF 00000000 00000000 00010000 00000000 (the rest of the buffer remained 0xFF’s) Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Uma Parepalli [mailto:Uma.Parepalli at skhms.com] Sent: Monday, September 14, 2015 7:13 PM To: Thomas Freeman ; Robles, Raymond C ; nvmewin at lists.openfabrics.org; uliur at google.com Subject: RE: [nvmewin] FW: NVME fuzz test fixes Just curious, do you see the same issues if you use the standard Windows inbox driver? Thank you, Uma Uma Parepalli uma.parepalli at skhms.com Cell: 408 805 9260 SK Hynix Memory Solutions, 3103 N 1st St, San Jose, CA 95134 From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Thomas Freeman Sent: Monday, September 14, 2015 1:42 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org; uliur at google.com Subject: Re: [nvmewin] FW: NVME fuzz test fixes Iuliu, The changes look good. I have just a few comments. 1. nvmeSnti.C/Line 1157 – memset(pResponseBuffer, 0, allocLength); This was added to the comment, but it’s not clear why. I suspect it is an accidental addition. If so, this should be removed. 2. nvmeSnti.c/Line 1519 – Since the Lun value is actually written to the second byte of the entry, the comparison should be: if (lunIdDataOffset + SINGLE_LVL_LUN_OFFSET >= allocLength) As an example, test with a buffer size of 0x11. Without this change, the driver will actually write the byte after the allocated buffer. 3. nvmeSnti.c/Line 2652 & 2669. Your change handles the case where there is no data buffer. But, it does not handle the case where the buffer is smaller than sizeof(DESCRIPTOR_FORMAT_SENSE_DATA). With a small buffer allocation, these writes would access beyond the allocated buffer pSenseData->ErrorCode = FIXED_SENSE_DATA; pSenseData->SenseKey = SCSI_SENSE_NO_SENSE; pSenseData->AdditionalSenseLength = FIXED_SENSE_DATA_ADD_LENGTH; pSenseData->AdditionalSenseCode = SCSI_ADSENSE_NO_SENSE; pSenseData->AdditionalSenseCodeQualifier = 0; Regards, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, September 11, 2015 3:29 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] FW: NVME fuzz test fixes All, Here is the original patch from Google (Iuliu) for the WHCK fuzz tests. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Iuliu Rus Sent: Monday, August 03, 2015 1:37 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVME fuzz test fixes Hello, I have attached the fixes we (Google) did for the several crashes / corruptions exposed by the Windows HCK fuzztest.exe. We have tested this on qemu/ Server 2012 R2. The password on the zip is "nvme" :) HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. The information contained in this e-mail is considered confidential of SK hynix memory solutions Inc. and intended only for the persons addressed or copied in this e-mail. Any unauthorized use, dissemination of the information, or copying of this message is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: From iuliur at google.com Tue Sep 15 10:07:55 2015 From: iuliur at google.com (Iuliu Rus) Date: Tue, 15 Sep 2015 10:07:55 -0700 Subject: [nvmewin] FW: NVME fuzz test fixes In-Reply-To: References: <49158E750348AA499168FD41D88983606B74D22A@fmsmsx117.amr.corp.intel.com> Message-ID: Thanks for the great feedback. Fixed all and attached the new zip (same password). I also reran the tests, but for 3) the Microsoft fuzz test seems to have no coverage. It keeps asking for sense data with aloc length of 0 (like 100 times). I artificially tested this by modifying the allocLength variable in kernel debugger. On Mon, Sep 14, 2015 at 1:41 PM, Thomas Freeman wrote: > Iuliu, > > The changes look good. > > I have just a few comments. > > 1. nvmeSnti.C/Line 1157 – *memset(pResponseBuffer, 0, > allocLength);* This was added to the comment, but it’s not clear why. I > suspect it is an accidental addition. If so, this should be removed. > > 2. nvmeSnti.c/Line 1519 – Since the Lun value is actually written > to the second byte of the entry, the comparison should be: > > *if (lunIdDataOffset + SINGLE_LVL_LUN_OFFSET >= allocLength*) > > > > As an example, test with a buffer size of 0x11. Without this change, the > driver will actually write the byte after the allocated buffer. > > 3. nvmeSnti.c/Line 2652 & 2669. Your change handles the case where > there is no data buffer. But, it does not handle the case where the buffer > is smaller than sizeof(DESCRIPTOR_FORMAT_SENSE_DATA). With a small buffer > allocation, these writes would access beyond the allocated buffer > > pSenseData->ErrorCode > = FIXED_SENSE_DATA; > > pSenseData->SenseKey = SCSI_SENSE_NO_SENSE; > > pSenseData->AdditionalSenseLength = > FIXED_SENSE_DATA_ADD_LENGTH; > > pSenseData->AdditionalSenseCode = > SCSI_ADSENSE_NO_SENSE; > > pSenseData->AdditionalSenseCodeQualifier = 0; > > > > > > Regards, > > *Tom Freeman* > > *Software Engineer, Device Manager and Driver Development* > > HGST, a Western Digital company > > thomas.freeman at hgst.com > > 507-322-2311 > > > > [image: HGST_Logo_email] > > 3605 Hwy 52 N > Rochester, MN 55901 > www.hgst.com > > > > > *From:* nvmewin-bounces at lists.openfabrics.org [mailto: > nvmewin-bounces at lists.openfabrics.org] *On Behalf Of *Robles, Raymond C > *Sent:* Friday, September 11, 2015 3:29 PM > *To:* nvmewin at lists.openfabrics.org > *Subject:* [nvmewin] FW: NVME fuzz test fixes > > > > All, > > > > Here is the original patch from Google (Iuliu) for the WHCK fuzz tests. > > > > Thanks, > > Ray > > > > *From:* nvmewin-bounces at lists.openfabrics.org [ > mailto:nvmewin-bounces at lists.openfabrics.org > ] *On Behalf Of *Iuliu Rus > *Sent:* Monday, August 03, 2015 1:37 PM > *To:* nvmewin at lists.openfabrics.org > *Subject:* [nvmewin] NVME fuzz test fixes > > > > Hello, > > I have attached the fixes we (Google) did for the several crashes / > corruptions exposed by the Windows HCK fuzztest.exe. > > We have tested this on qemu/ Server 2012 R2. > > The password on the zip is "nvme" :) > > *HGST E-mail Confidentiality Notice & Disclaimer:* > This e-mail and any files transmitted with it may contain confidential or > legally privileged information of HGST and are intended solely for the use > of the individual or entity to which they are addressed. If you are not the > intended recipient, any disclosure, copying, distribution or any action > taken or omitted to be taken in reliance on it, is prohibited. If you have > received this e-mail in error, please notify the sender immediately and > delete the e-mail in its entirety from your system. > > _______________________________________________ > nvmewin mailing list > nvmewin at lists.openfabrics.org > http://lists.openfabrics.org/mailman/listinfo/nvmewin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fuzz_fixes.zip Type: application/zip Size: 2048158 bytes Desc: not available URL: From raymond.c.robles at intel.com Mon Sep 21 14:03:46 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Mon, 21 Sep 2015 21:03:46 +0000 Subject: [nvmewin] FW: NVME fuzz test fixes In-Reply-To: References: <49158E750348AA499168FD41D88983606B74D22A@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983606B766FD0@fmsmsx117.amr.corp.intel.com> Intel approves this patch. Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Tuesday, September 15, 2015 10:08 AM To: Thomas Freeman Cc: Robles, Raymond C; nvmewin at lists.openfabrics.org; uliur at google.com Subject: Re: [nvmewin] FW: NVME fuzz test fixes Thanks for the great feedback. Fixed all and attached the new zip (same password). I also reran the tests, but for 3) the Microsoft fuzz test seems to have no coverage. It keeps asking for sense data with aloc length of 0 (like 100 times). I artificially tested this by modifying the allocLength variable in kernel debugger. On Mon, Sep 14, 2015 at 1:41 PM, Thomas Freeman > wrote: Iuliu, The changes look good. I have just a few comments. 1. nvmeSnti.C/Line 1157 – memset(pResponseBuffer, 0, allocLength); This was added to the comment, but it’s not clear why. I suspect it is an accidental addition. If so, this should be removed. 2. nvmeSnti.c/Line 1519 – Since the Lun value is actually written to the second byte of the entry, the comparison should be: if (lunIdDataOffset + SINGLE_LVL_LUN_OFFSET >= allocLength) As an example, test with a buffer size of 0x11. Without this change, the driver will actually write the byte after the allocated buffer. 3. nvmeSnti.c/Line 2652 & 2669. Your change handles the case where there is no data buffer. But, it does not handle the case where the buffer is smaller than sizeof(DESCRIPTOR_FORMAT_SENSE_DATA). With a small buffer allocation, these writes would access beyond the allocated buffer pSenseData->ErrorCode = FIXED_SENSE_DATA; pSenseData->SenseKey = SCSI_SENSE_NO_SENSE; pSenseData->AdditionalSenseLength = FIXED_SENSE_DATA_ADD_LENGTH; pSenseData->AdditionalSenseCode = SCSI_ADSENSE_NO_SENSE; pSenseData->AdditionalSenseCodeQualifier = 0; Regards, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, September 11, 2015 3:29 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] FW: NVME fuzz test fixes All, Here is the original patch from Google (Iuliu) for the WHCK fuzz tests. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Iuliu Rus Sent: Monday, August 03, 2015 1:37 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVME fuzz test fixes Hello, I have attached the fixes we (Google) did for the several crashes / corruptions exposed by the Windows HCK fuzztest.exe. We have tested this on qemu/ Server 2012 R2. The password on the zip is "nvme" :) HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: From thomas.freeman at hgst.com Tue Sep 22 13:01:38 2015 From: thomas.freeman at hgst.com (Thomas Freeman) Date: Tue, 22 Sep 2015 20:01:38 +0000 Subject: [nvmewin] FW: NVME fuzz test fixes In-Reply-To: References: <49158E750348AA499168FD41D88983606B74D22A@fmsmsx117.amr.corp.intel.com> Message-ID: HGST approves these changes. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Iuliu Rus [mailto:iuliur at google.com] Sent: Tuesday, September 15, 2015 12:08 PM To: Thomas Freeman Cc: Robles, Raymond C ; nvmewin at lists.openfabrics.org; uliur at google.com Subject: Re: [nvmewin] FW: NVME fuzz test fixes Thanks for the great feedback. Fixed all and attached the new zip (same password). I also reran the tests, but for 3) the Microsoft fuzz test seems to have no coverage. It keeps asking for sense data with aloc length of 0 (like 100 times). I artificially tested this by modifying the allocLength variable in kernel debugger. On Mon, Sep 14, 2015 at 1:41 PM, Thomas Freeman > wrote: Iuliu, The changes look good. I have just a few comments. 1. nvmeSnti.C/Line 1157 – memset(pResponseBuffer, 0, allocLength); This was added to the comment, but it’s not clear why. I suspect it is an accidental addition. If so, this should be removed. 2. nvmeSnti.c/Line 1519 – Since the Lun value is actually written to the second byte of the entry, the comparison should be: if (lunIdDataOffset + SINGLE_LVL_LUN_OFFSET >= allocLength) As an example, test with a buffer size of 0x11. Without this change, the driver will actually write the byte after the allocated buffer. 3. nvmeSnti.c/Line 2652 & 2669. Your change handles the case where there is no data buffer. But, it does not handle the case where the buffer is smaller than sizeof(DESCRIPTOR_FORMAT_SENSE_DATA). With a small buffer allocation, these writes would access beyond the allocated buffer pSenseData->ErrorCode = FIXED_SENSE_DATA; pSenseData->SenseKey = SCSI_SENSE_NO_SENSE; pSenseData->AdditionalSenseLength = FIXED_SENSE_DATA_ADD_LENGTH; pSenseData->AdditionalSenseCode = SCSI_ADSENSE_NO_SENSE; pSenseData->AdditionalSenseCodeQualifier = 0; Regards, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, September 11, 2015 3:29 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] FW: NVME fuzz test fixes All, Here is the original patch from Google (Iuliu) for the WHCK fuzz tests. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Iuliu Rus Sent: Monday, August 03, 2015 1:37 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVME fuzz test fixes Hello, I have attached the fixes we (Google) did for the several crashes / corruptions exposed by the Windows HCK fuzztest.exe. We have tested this on qemu/ Server 2012 R2. The password on the zip is "nvme" :) HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: From Alex.Chang at pmcs.com Tue Sep 22 14:27:56 2015 From: Alex.Chang at pmcs.com (Alex Chang) Date: Tue, 22 Sep 2015 21:27:56 +0000 Subject: [nvmewin] FW: NVME fuzz test fixes In-Reply-To: References: <49158E750348AA499168FD41D88983606B74D22A@fmsmsx117.amr.corp.intel.com> Message-ID: PMC approves the patch. Thank you! Alex From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Thomas Freeman Sent: Tuesday, September 22, 2015 1:02 PM To: Iuliu Rus Cc: nvmewin at lists.openfabrics.org; uliur at google.com Subject: Re: [nvmewin] FW: NVME fuzz test fixes HGST approves these changes. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Iuliu Rus [mailto:iuliur at google.com] Sent: Tuesday, September 15, 2015 12:08 PM To: Thomas Freeman > Cc: Robles, Raymond C >; nvmewin at lists.openfabrics.org; uliur at google.com Subject: Re: [nvmewin] FW: NVME fuzz test fixes Thanks for the great feedback. Fixed all and attached the new zip (same password). I also reran the tests, but for 3) the Microsoft fuzz test seems to have no coverage. It keeps asking for sense data with aloc length of 0 (like 100 times). I artificially tested this by modifying the allocLength variable in kernel debugger. On Mon, Sep 14, 2015 at 1:41 PM, Thomas Freeman > wrote: Iuliu, The changes look good. I have just a few comments. 1. nvmeSnti.C/Line 1157 – memset(pResponseBuffer, 0, allocLength); This was added to the comment, but it’s not clear why. I suspect it is an accidental addition. If so, this should be removed. 2. nvmeSnti.c/Line 1519 – Since the Lun value is actually written to the second byte of the entry, the comparison should be: if (lunIdDataOffset + SINGLE_LVL_LUN_OFFSET >= allocLength) As an example, test with a buffer size of 0x11. Without this change, the driver will actually write the byte after the allocated buffer. 3. nvmeSnti.c/Line 2652 & 2669. Your change handles the case where there is no data buffer. But, it does not handle the case where the buffer is smaller than sizeof(DESCRIPTOR_FORMAT_SENSE_DATA). With a small buffer allocation, these writes would access beyond the allocated buffer pSenseData->ErrorCode = FIXED_SENSE_DATA; pSenseData->SenseKey = SCSI_SENSE_NO_SENSE; pSenseData->AdditionalSenseLength = FIXED_SENSE_DATA_ADD_LENGTH; pSenseData->AdditionalSenseCode = SCSI_ADSENSE_NO_SENSE; pSenseData->AdditionalSenseCodeQualifier = 0; Regards, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, September 11, 2015 3:29 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] FW: NVME fuzz test fixes All, Here is the original patch from Google (Iuliu) for the WHCK fuzz tests. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Iuliu Rus Sent: Monday, August 03, 2015 1:37 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVME fuzz test fixes Hello, I have attached the fixes we (Google) did for the several crashes / corruptions exposed by the Windows HCK fuzztest.exe. We have tested this on qemu/ Server 2012 R2. The password on the zip is "nvme" :) HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: From raymond.c.robles at intel.com Tue Sep 22 17:40:27 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Wed, 23 Sep 2015 00:40:27 +0000 Subject: [nvmewin] FW: NVME fuzz test fixes In-Reply-To: References: <49158E750348AA499168FD41D88983606B74D22A@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983606B769A36@fmsmsx117.amr.corp.intel.com> Thanks Tom! From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Tuesday, September 22, 2015 1:02 PM To: Iuliu Rus Cc: Robles, Raymond C; nvmewin at lists.openfabrics.org; uliur at google.com Subject: RE: [nvmewin] FW: NVME fuzz test fixes HGST approves these changes. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Iuliu Rus [mailto:iuliur at google.com] Sent: Tuesday, September 15, 2015 12:08 PM To: Thomas Freeman > Cc: Robles, Raymond C >; nvmewin at lists.openfabrics.org; uliur at google.com Subject: Re: [nvmewin] FW: NVME fuzz test fixes Thanks for the great feedback. Fixed all and attached the new zip (same password). I also reran the tests, but for 3) the Microsoft fuzz test seems to have no coverage. It keeps asking for sense data with aloc length of 0 (like 100 times). I artificially tested this by modifying the allocLength variable in kernel debugger. On Mon, Sep 14, 2015 at 1:41 PM, Thomas Freeman > wrote: Iuliu, The changes look good. I have just a few comments. 1. nvmeSnti.C/Line 1157 – memset(pResponseBuffer, 0, allocLength); This was added to the comment, but it’s not clear why. I suspect it is an accidental addition. If so, this should be removed. 2. nvmeSnti.c/Line 1519 – Since the Lun value is actually written to the second byte of the entry, the comparison should be: if (lunIdDataOffset + SINGLE_LVL_LUN_OFFSET >= allocLength) As an example, test with a buffer size of 0x11. Without this change, the driver will actually write the byte after the allocated buffer. 3. nvmeSnti.c/Line 2652 & 2669. Your change handles the case where there is no data buffer. But, it does not handle the case where the buffer is smaller than sizeof(DESCRIPTOR_FORMAT_SENSE_DATA). With a small buffer allocation, these writes would access beyond the allocated buffer pSenseData->ErrorCode = FIXED_SENSE_DATA; pSenseData->SenseKey = SCSI_SENSE_NO_SENSE; pSenseData->AdditionalSenseLength = FIXED_SENSE_DATA_ADD_LENGTH; pSenseData->AdditionalSenseCode = SCSI_ADSENSE_NO_SENSE; pSenseData->AdditionalSenseCodeQualifier = 0; Regards, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, September 11, 2015 3:29 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] FW: NVME fuzz test fixes All, Here is the original patch from Google (Iuliu) for the WHCK fuzz tests. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Iuliu Rus Sent: Monday, August 03, 2015 1:37 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVME fuzz test fixes Hello, I have attached the fixes we (Google) did for the several crashes / corruptions exposed by the Windows HCK fuzztest.exe. We have tested this on qemu/ Server 2012 R2. The password on the zip is "nvme" :) HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: From raymond.c.robles at intel.com Tue Sep 22 17:40:46 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Wed, 23 Sep 2015 00:40:46 +0000 Subject: [nvmewin] FW: NVME fuzz test fixes In-Reply-To: References: <49158E750348AA499168FD41D88983606B74D22A@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983606B769A4B@fmsmsx117.amr.corp.intel.com> Thanks Alex! From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang Sent: Tuesday, September 22, 2015 2:28 PM To: Thomas Freeman; Iuliu Rus Cc: nvmewin at lists.openfabrics.org; uliur at google.com Subject: Re: [nvmewin] FW: NVME fuzz test fixes PMC approves the patch. Thank you! Alex From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Thomas Freeman Sent: Tuesday, September 22, 2015 1:02 PM To: Iuliu Rus Cc: nvmewin at lists.openfabrics.org; uliur at google.com Subject: Re: [nvmewin] FW: NVME fuzz test fixes HGST approves these changes. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Iuliu Rus [mailto:iuliur at google.com] Sent: Tuesday, September 15, 2015 12:08 PM To: Thomas Freeman > Cc: Robles, Raymond C >; nvmewin at lists.openfabrics.org; uliur at google.com Subject: Re: [nvmewin] FW: NVME fuzz test fixes Thanks for the great feedback. Fixed all and attached the new zip (same password). I also reran the tests, but for 3) the Microsoft fuzz test seems to have no coverage. It keeps asking for sense data with aloc length of 0 (like 100 times). I artificially tested this by modifying the allocLength variable in kernel debugger. On Mon, Sep 14, 2015 at 1:41 PM, Thomas Freeman > wrote: Iuliu, The changes look good. I have just a few comments. 1. nvmeSnti.C/Line 1157 – memset(pResponseBuffer, 0, allocLength); This was added to the comment, but it’s not clear why. I suspect it is an accidental addition. If so, this should be removed. 2. nvmeSnti.c/Line 1519 – Since the Lun value is actually written to the second byte of the entry, the comparison should be: if (lunIdDataOffset + SINGLE_LVL_LUN_OFFSET >= allocLength) As an example, test with a buffer size of 0x11. Without this change, the driver will actually write the byte after the allocated buffer. 3. nvmeSnti.c/Line 2652 & 2669. Your change handles the case where there is no data buffer. But, it does not handle the case where the buffer is smaller than sizeof(DESCRIPTOR_FORMAT_SENSE_DATA). With a small buffer allocation, these writes would access beyond the allocated buffer pSenseData->ErrorCode = FIXED_SENSE_DATA; pSenseData->SenseKey = SCSI_SENSE_NO_SENSE; pSenseData->AdditionalSenseLength = FIXED_SENSE_DATA_ADD_LENGTH; pSenseData->AdditionalSenseCode = SCSI_ADSENSE_NO_SENSE; pSenseData->AdditionalSenseCodeQualifier = 0; Regards, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, September 11, 2015 3:29 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] FW: NVME fuzz test fixes All, Here is the original patch from Google (Iuliu) for the WHCK fuzz tests. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Iuliu Rus Sent: Monday, August 03, 2015 1:37 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVME fuzz test fixes Hello, I have attached the fixes we (Google) did for the several crashes / corruptions exposed by the Windows HCK fuzztest.exe. We have tested this on qemu/ Server 2012 R2. The password on the zip is "nvme" :) HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: From suman.p at samsung.com Wed Sep 23 04:49:17 2015 From: suman.p at samsung.com (SUMAN PRAKASH B) Date: Wed, 23 Sep 2015 11:49:17 +0000 (GMT) Subject: [nvmewin] FW: NVME fuzz test fixes Message-ID: <9B.5A.04958.DB192065@epcpsbgx3.samsung.com> An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Mon Sep 28 16:16:12 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Mon, 28 Sep 2015 23:16:12 +0000 Subject: [nvmewin] FW: NVME fuzz test fixes In-Reply-To: References: Message-ID: <49158E750348AA499168FD41D88983606B76EEC6@fmsmsx117.amr.corp.intel.com> Thanks Suman! I'll push the patch today and it should be ready by tomorrow. Intel is up next with the Namespace Management patch. However, we are not fully done with unit testing. Suman, is Samsung ready to push any of its patches next? Thanks, Ray From: SUMAN PRAKASH B [mailto:suman.p at samsung.com] Sent: Wednesday, September 23, 2015 4:49 AM To: nvmewin-request at lists.openfabrics.org; nvmewin at lists.openfabrics.org; Robles, Raymond C Subject: Re: FW: NVME fuzz test fixes SAMSUNG approves the patch. Thanks, Suman ------- Original Message ------- Sender : nvmewin-request at lists.openfabrics.org> Date : Sep 23, 2015 06:10 (GMT+05:30) Title : nvmewin Digest, Vol 45, Issue 21 Send nvmewin mailing list submissions to nvmewin at lists.openfabrics.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openfabrics.org/mailman/listinfo/nvmewin or, via email, send a message with subject or body 'help' to nvmewin-request at lists.openfabrics.org You can reach the person managing the list at nvmewin-owner at lists.openfabrics.org When replying, please edit your Subject line so it is more specific than "Re: Contents of nvmewin digest..." Today's Topics: 1. Re: FW: NVME fuzz test fixes (Robles, Raymond C) ---------------------------------------------------------------------- Message: 1 Date: Wed, 23 Sep 2015 00:40:46 +0000 From: "Robles, Raymond C" > To: Alex Chang >, Thomas Freeman >, Iuliu Rus > Cc: "nvmewin at lists.openfabrics.org" > Subject: Re: [nvmewin] FW: NVME fuzz test fixes Message-ID: <49158E750348AA499168FD41D88983606B769A4B at fmsmsx117.amr.corp.intel.com> Content-Type: text/plain; charset="utf-8" Thanks Alex! From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang Sent: Tuesday, September 22, 2015 2:28 PM To: Thomas Freeman; Iuliu Rus Cc: nvmewin at lists.openfabrics.org; uliur at google.com Subject: Re: [nvmewin] FW: NVME fuzz test fixes PMC approves the patch. Thank you! Alex From: nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Thomas Freeman Sent: Tuesday, September 22, 2015 1:02 PM To: Iuliu Rus Cc: nvmewin at lists.openfabrics.org>; uliur at google.com> Subject: Re: [nvmewin] FW: NVME fuzz test fixes HGST approves these changes. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com> 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com> From: Iuliu Rus [mailto:iuliur at google.com] Sent: Tuesday, September 15, 2015 12:08 PM To: Thomas Freeman >> Cc: Robles, Raymond C >>; nvmewin at lists.openfabrics.org>; uliur at google.com> Subject: Re: [nvmewin] FW: NVME fuzz test fixes Thanks for the great feedback. Fixed all and attached the new zip (same password). I also reran the tests, but for 3) the Microsoft fuzz test seems to have no coverage. It keeps asking for sense data with aloc length of 0 (like 100 times). I artificially tested this by modifying the allocLength variable in kernel debugger. On Mon, Sep 14, 2015 at 1:41 PM, Thomas Freeman >> wrote: Iuliu, The changes look good. I have just a few comments. 1. nvmeSnti.C/Line 1157 ? memset(pResponseBuffer, 0, allocLength); This was added to the comment, but it?s not clear why. I suspect it is an accidental addition. If so, this should be removed. 2. nvmeSnti.c/Line 1519 ? Since the Lun value is actually written to the second byte of the entry, the comparison should be: if (lunIdDataOffset + SINGLE_LVL_LUN_OFFSET >= allocLength) As an example, test with a buffer size of 0x11. Without this change, the driver will actually write the byte after the allocated buffer. 3. nvmeSnti.c/Line 2652 & 2669. Your change handles the case where there is no data buffer. But, it does not handle the case where the buffer is smaller than sizeof(DESCRIPTOR_FORMAT_SENSE_DATA). With a small buffer allocation, these writes would access beyond the allocated buffer pSenseData->ErrorCode = FIXED_SENSE_DATA; pSenseData->SenseKey = SCSI_SENSE_NO_SENSE; pSenseData->AdditionalSenseLength = FIXED_SENSE_DATA_ADD_LENGTH; pSenseData->AdditionalSenseCode = SCSI_ADSENSE_NO_SENSE; pSenseData->AdditionalSenseCodeQualifier = 0; Regards, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com> 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com> From: nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, September 11, 2015 3:29 PM To: nvmewin at lists.openfabrics.org> Subject: [nvmewin] FW: NVME fuzz test fixes All, Here is the original patch from Google (Iuliu) for the WHCK fuzz tests. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Iuliu Rus Sent: Monday, August 03, 2015 1:37 PM To: nvmewin at lists.openfabrics.org> Subject: [nvmewin] NVME fuzz test fixes Hello, I have attached the fixes we (Google) did for the several crashes / corruptions exposed by the Windows HCK fuzztest.exe. We have tested this on qemu/ Server 2012 R2. The password on the zip is "nvme" :) HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org> http://lists.openfabrics.org/mailman/listinfo/nvmewin HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: ------------------------------ _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin End of nvmewin Digest, Vol 45, Issue 21 ***************************************

 

 

[http://ext.samsung.net/mailcheck/SeenTimeChecker?do=36652d682e3669a8058afc1f1dafb9f39cd05f6ab872f9f6313cb48408a29da1bbef98290b9ea6844a835b19b8ec809fc7b41e955949e5c8a728c55b39cc59eacf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Tue Sep 29 00:24:37 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Tue, 29 Sep 2015 07:24:37 +0000 Subject: [nvmewin] FW: NVME fuzz test fixes In-Reply-To: <49158E750348AA499168FD41D88983606B76EEC6@fmsmsx117.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606B76EEC6@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983606B76FCC8@fmsmsx117.amr.corp.intel.com> Hi Iuliu, As I was getting ready to merge your patch, I did a diff of your patch with the current OFA trunk and noticed that you don't have the latest updates from the OFA trunk within your patch. I did not want to do a manual merge of your patch on top of the current source in case there was any overlap. Could you please rebase your patch with the latest OFA trunk? Thanks! This also brings up another point that you had previously raised to me... patch submission. I spoke with Ken Strandberg (OFA admin) and he reminded me that all SVN clients have a "create patch" and "apply patch" option. So, if you don't mind, once you are done with rebasing your code with the latest trunk, could you please create a patch using the SVN tools? I use TortoiseSVN and it's pretty straightforward. You just need to copy your files over your working copy of the trunk and select "create branch". You should then just be able to send me the patch. Thanks for being the guinea pig for this, but I think it makes sense to use a patch tool as you recommended. Let me know if you have any questions. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, September 28, 2015 4:16 PM To: suman.p at samsung.com; nvmewin-request at lists.openfabrics.org; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] FW: NVME fuzz test fixes Thanks Suman! I'll push the patch today and it should be ready by tomorrow. Intel is up next with the Namespace Management patch. However, we are not fully done with unit testing. Suman, is Samsung ready to push any of its patches next? Thanks, Ray From: SUMAN PRAKASH B [mailto:suman.p at samsung.com] Sent: Wednesday, September 23, 2015 4:49 AM To: nvmewin-request at lists.openfabrics.org; nvmewin at lists.openfabrics.org; Robles, Raymond C Subject: Re: FW: NVME fuzz test fixes SAMSUNG approves the patch. Thanks, Suman ------- Original Message ------- Sender : nvmewin-request at lists.openfabrics.org> Date : Sep 23, 2015 06:10 (GMT+05:30) Title : nvmewin Digest, Vol 45, Issue 21 Send nvmewin mailing list submissions to nvmewin at lists.openfabrics.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openfabrics.org/mailman/listinfo/nvmewin or, via email, send a message with subject or body 'help' to nvmewin-request at lists.openfabrics.org You can reach the person managing the list at nvmewin-owner at lists.openfabrics.org When replying, please edit your Subject line so it is more specific than "Re: Contents of nvmewin digest..." Today's Topics: 1. Re: FW: NVME fuzz test fixes (Robles, Raymond C) ---------------------------------------------------------------------- Message: 1 Date: Wed, 23 Sep 2015 00:40:46 +0000 From: "Robles, Raymond C" > To: Alex Chang >, Thomas Freeman >, Iuliu Rus > Cc: "nvmewin at lists.openfabrics.org" > Subject: Re: [nvmewin] FW: NVME fuzz test fixes Message-ID: <49158E750348AA499168FD41D88983606B769A4B at fmsmsx117.amr.corp.intel.com> Content-Type: text/plain; charset="utf-8" Thanks Alex! From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang Sent: Tuesday, September 22, 2015 2:28 PM To: Thomas Freeman; Iuliu Rus Cc: nvmewin at lists.openfabrics.org; uliur at google.com Subject: Re: [nvmewin] FW: NVME fuzz test fixes PMC approves the patch. Thank you! Alex From: nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Thomas Freeman Sent: Tuesday, September 22, 2015 1:02 PM To: Iuliu Rus Cc: nvmewin at lists.openfabrics.org>; uliur at google.com> Subject: Re: [nvmewin] FW: NVME fuzz test fixes HGST approves these changes. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com> 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com> From: Iuliu Rus [mailto:iuliur at google.com] Sent: Tuesday, September 15, 2015 12:08 PM To: Thomas Freeman >> Cc: Robles, Raymond C >>; nvmewin at lists.openfabrics.org>; uliur at google.com> Subject: Re: [nvmewin] FW: NVME fuzz test fixes Thanks for the great feedback. Fixed all and attached the new zip (same password). I also reran the tests, but for 3) the Microsoft fuzz test seems to have no coverage. It keeps asking for sense data with aloc length of 0 (like 100 times). I artificially tested this by modifying the allocLength variable in kernel debugger. On Mon, Sep 14, 2015 at 1:41 PM, Thomas Freeman >> wrote: Iuliu, The changes look good. I have just a few comments. 1. nvmeSnti.C/Line 1157 ? memset(pResponseBuffer, 0, allocLength); This was added to the comment, but it?s not clear why. I suspect it is an accidental addition. If so, this should be removed. 2. nvmeSnti.c/Line 1519 ? Since the Lun value is actually written to the second byte of the entry, the comparison should be: if (lunIdDataOffset + SINGLE_LVL_LUN_OFFSET >= allocLength) As an example, test with a buffer size of 0x11. Without this change, the driver will actually write the byte after the allocated buffer. 3. nvmeSnti.c/Line 2652 & 2669. Your change handles the case where there is no data buffer. But, it does not handle the case where the buffer is smaller than sizeof(DESCRIPTOR_FORMAT_SENSE_DATA). With a small buffer allocation, these writes would access beyond the allocated buffer pSenseData->ErrorCode = FIXED_SENSE_DATA; pSenseData->SenseKey = SCSI_SENSE_NO_SENSE; pSenseData->AdditionalSenseLength = FIXED_SENSE_DATA_ADD_LENGTH; pSenseData->AdditionalSenseCode = SCSI_ADSENSE_NO_SENSE; pSenseData->AdditionalSenseCodeQualifier = 0; Regards, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com> 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com> From: nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, September 11, 2015 3:29 PM To: nvmewin at lists.openfabrics.org> Subject: [nvmewin] FW: NVME fuzz test fixes All, Here is the original patch from Google (Iuliu) for the WHCK fuzz tests. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Iuliu Rus Sent: Monday, August 03, 2015 1:37 PM To: nvmewin at lists.openfabrics.org> Subject: [nvmewin] NVME fuzz test fixes Hello, I have attached the fixes we (Google) did for the several crashes / corruptions exposed by the Windows HCK fuzztest.exe. We have tested this on qemu/ Server 2012 R2. The password on the zip is "nvme" :) HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org> http://lists.openfabrics.org/mailman/listinfo/nvmewin HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: ------------------------------ _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin End of nvmewin Digest, Vol 45, Issue 21 ***************************************

 

 

[http://ext.samsung.net/mailcheck/SeenTimeChecker?do=36652d682e3669a8058afc1f1dafb9f39cd05f6ab872f9f6313cb48408a29da1bbef98290b9ea6844a835b19b8ec809fc7b41e955949e5c8a728c55b39cc59eacf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: