lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 21 Mar 2012 09:20:00 -0700
From:	Roland Dreier <roland@...estorage.com>
To:	parav.pandit@...lex.com
Cc:	linux-rdma@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA adapter

On Tue, Mar 20, 2012 at 3:39 PM,  <parav.pandit@...lex.com> wrote:
> From: Parav Pandit <parav.pandit@...lex.com>
>
> - Header file for userspace library and kernel driver interface.

> +struct ocrdma_alloc_ucontext_resp {
> +       u32 dev_id;
> +       u32 wqe_size;
> +       u32 max_inline_data;
> +       u32 dpp_wqe_size;
> +       u64 ah_tbl_page;
> +       u32 ah_tbl_len;
> +       u32 rsvd;
> +       u8 fw_ver[32];
> +       u32 rqe_size;
> +       u64 rsvd1;
> +} __packed;

If I'm reading this correctly, you have the 8-byte rsvd1 member at an
offset only aligned to 4 bytes, because of the __packed directive.  It
would be much better to have these structures laid out so they are
naturally the same on both 32-bit and 64-bit ABIs, and get rid of the
__packed directive, which wrecks gcc code generation in some cases.

In this particular case, it seems you could just move rqe_size into the
slot where rsvd is, and get rid of rsvd1?

> +/* user kernel communication data structures. */
> +struct ocrdma_alloc_pd_ureq {
> +       u64 rsvd1;
> +} __packed;

Similar comment -- __packed is silly for a structure with one reserved
member (and which you don't seem to use anywhere)... why not just
delete this struct?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists