netdev - RE: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA adapter

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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <88B766C272F2C64B944B21AD078333151C964A66EF@EXMAIL.ad.emulex.com>
Date:	Thu, 22 Mar 2012 13:52:30 -0700
From:	<Parav.Pandit@...lex.Com>
To:	<David.Laight@...LAB.COM>, <roland@...estorage.com>
CC:	<linux-rdma@...r.kernel.org>, <netdev@...r.kernel.org>
Subject: RE: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA adapter



> -----Original Message-----
> From: David Laight [mailto:David.Laight@...LAB.COM]
> Sent: Wednesday, March 21, 2012 10:02 PM
> To: Roland Dreier; Pandit, Parav
> Cc: linux-rdma@...r.kernel.org; netdev@...r.kernel.org
> Subject: RE: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA
> adapter
> 
> 
> > > - 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.
> >
> 
> gcc also supports defining types that have non-standard alignment
> constraints that can be used to force the same alignment for 64bit fields
> between i386 and amd64.
> Probably __attribute__((aligned,n)) or similar.
> 
> This can be used to force 32bit alignment in amd64 code in order to match
> definitions in 32bit userspace.
> For new things it would make sense to force 64bit alignment of 64bit fields
> for 32bit code.

o.k. so I'll use aligned attribute to align user-kernel interface data structure to 8 byte boundary.
That should work for 32-bit and 64-bit user and kernel space and does't hurt performance either?

Driver-adapter structures will be aligned to 4 byte boundary using aligned attribute instead of packed.

> 
> Adding __packed (rather than 32bit alignment) forces the compiler to
> generate byte by byte accesses for all the fields on systems that can't do
> misaligned accesses in hardware (eg sparc).
> 
> 	David
> 
> 
> 	David
> 

--
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