linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Charles Machalow <csm10495@gmail.com>
Cc: linux-nvme@lists.infradead.org
Subject: Re: nvme_passthru_cmd64 has a 4 byte hole
Date: Wed, 30 Oct 2019 15:32:33 +0900	[thread overview]
Message-ID: <20191030063233.GA16863@redsun51.ssa.fujisawa.hgst.com> (raw)
In-Reply-To: <CANSCoS8HakAy6zHgEjDiYQ87z83RJy-OC9ZfktRJwr+9kgnFKw@mail.gmail.com>

On Tue, Oct 29, 2019 at 09:43:20PM -0700, Charles Machalow wrote:
> Hey all,
> 
> I noticed (via some debug) that nvme_passthru_cmd64 seems to have a 4
> byte hole that isn't currently accounted for in the struct:
> From pahole:
> 
> struct nvme_passthru_cmd64 {
>         __u8                       opcode;               /*     0     1 */
>         __u8                       flags;                /*     1     1 */
>         __u16                      rsvd1;                /*     2     2 */
>         __u32                      nsid;                 /*     4     4 */
>         __u32                      cdw2;                 /*     8     4 */
>         __u32                      cdw3;                 /*    12     4 */
>         __u64                      metadata;             /*    16     8 */
>         __u64                      addr;                 /*    24     8 */
>         __u32                      metadata_len;         /*    32     4 */
>         __u32                      data_len;             /*    36     4 */
>         __u32                      cdw10;                /*    40     4 */
>         __u32                      cdw11;                /*    44     4 */
>         __u32                      cdw12;                /*    48     4 */
>         __u32                      cdw13;                /*    52     4 */
>         __u32                      cdw14;                /*    56     4 */
>         __u32                      cdw15;                /*    60     4 */
>         /* --- cacheline 1 boundary (64 bytes) --- */
>         __u32                      timeout_ms;           /*    64     4 */
> 
>         /* XXX 4 bytes hole, try to pack */
> 
>         __u64                      result;               /*    72     8 */
> 
>         /* size: 80, cachelines: 2, members: 18 */
>         /* sum members: 76, holes: 1, sum holes: 4 */
>         /* last cacheline: 16 bytes */
> };
> 
> (Since I doubt we can functionally change the structure at this
> point...) 

Well, there is no official kernel release using this structure,
so I suppose even this late in the rc cycle, we can change it with
appropriate justification. I think an alternative to padding is to make
this a __u32[2] field, which should also be backward compatible with
the 4 byte result passthrough.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

  reply	other threads:[~2019-10-30  6:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-30  4:43 nvme_passthru_cmd64 has a 4 byte hole Charles Machalow
2019-10-30  6:32 ` Keith Busch [this message]
2019-10-30 14:08   ` Charles Machalow
2019-10-31  2:56     ` Charles Machalow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191030063233.GA16863@redsun51.ssa.fujisawa.hgst.com \
    --to=kbusch@kernel.org \
    --cc=csm10495@gmail.com \
    --cc=linux-nvme@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).