Skip to content

ebsnvme-stats: Correct numd - #56

Open
cperciva wants to merge 1 commit into
amazonlinux:mainfrom
cperciva:main
Open

ebsnvme-stats: Correct numd#56
cperciva wants to merge 1 commit into
amazonlinux:mainfrom
cperciva:main

Conversation

@cperciva

Copy link
Copy Markdown

Per the NVMe specification:
"Number of Dwords Lower (NUMDL): This field specifies the least
significant 16 bits of the number of dwords to return unless
otherwise specified. If the host specifies a size larger than
the log page requested, the controller returns the complete log
page with undefined results for dwords beyond the end of the log
page, unless otherwise specified. The combined NUMDL field and
NUMDU field form a 0's based value."

Since the number of Dwords is 1024 (4096 / 4) and this is expressed as a 0's based value the value which must be stored in the top 16 bits of Command Dword 10 is 1024 - 1 = 1023, not 1024.

Issue #, if available:
n/a

Description of changes:
Bug fix; see commit message.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Per the NVMe specification:
  "Number of Dwords Lower (NUMDL): This field specifies the least
  significant 16 bits of the number of dwords to return unless
  otherwise specified. If the host specifies a size larger than
  the log page requested, the controller returns the complete log
  page with undefined results for dwords beyond the end of the log
  page, unless otherwise specified. The combined NUMDL field and
  NUMDU field form a 0's based value."

Since the number of Dwords is 1024 (4096 / 4) and this is expressed
as a *0's based value* the value which must be stored in the top 16
bits of Command Dword 10 is 1024 - 1 = 1023, not 1024.

Signed-off-by: Colin Percival <cperciva@FreeBSD.org>
@cperciva

Copy link
Copy Markdown
Author

I have not confirmed that EBS implements NVMe correctly (in fact, I know that it does not implement NVMe correctly in other ways...) but if EBS is bug-for-bug compatible with the previous behaviour of this command-line tool then this change should still be harmless since the only difference is whether a reserved value is copied out.

I have not tested this change, since I do not use the tool in question; this bug was found purely by code inspection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant