struct nbd_reply not packed => trouble?

[Yann Droneaud]

> Hello kernel hackers,
>
>
> I noticed that in [linux]/include/uapi/linux/nbd.h the structure
>
>    struct nbd_request {
>            __be32 magic;
>            __be32 type;    /* == READ || == WRITE */
>            char handle[8];
>            __be64 from;
>            __be32 len;
>    } __attribute__((packed));
>
> is packed

Given a target where ABI requires types to be aligned on their size (1 =>
1, 2 => 2, 4 => 4, 8 => 8, etc.)


4 + 4 + 8 + 8 + 4 = 28 bytes

To satisfy __be64 alignement (the strictest), it must be aligned on a 8
bytes boundary, but 28 is not multiple of 8. 32 is. Padding is required.

[The padding is required so that in a array of struct nbd_request[],
 all members of all structures are aligned to their requirement alignement]


> but its reply counter part
>
>    struct nbd_reply {
>            __be32 magic;
>            __be32 error;    /* 0 = ok, else error */
> 	  char handle[8];  /* handle you got from request */
>    };
>

4 + 4 + 8 = 16 bytes.
To satisfy __be32 alignement (the strictest), it must be aligned on a 4
bytes boundary and 16 is a multiple of 4: no need for padding.

> is not.  Since Linux seems to read sizeof(nbd_reply) bytes from the
> network (see [1]), the number of bytes read varies with the number of
> bytes of the structure.


It won't.

>
> So my understanding is that if the size of struct nbd_reply varies from
> platform/compiler to another that means trouble.  I wonder:
>
>   - Is there anything about struct nbd_reply that would keep its size
>     equal everywhere or a reason why variance in size is no problem here?
>
>   - Any ideas for a platform where you would expect struct nbd_reply to
>     be other than 4 + 4 + 8 = 16 bytes in size?
>

Look for an ABI that require 'char' with either property:
- size > 1 byte
- alignment > 8 (16 bytes !)


Regards.

-- 
Yann Droneaud
OPTEYA