[openib-general] [PATCH] IB/core - ib_umad can cause address alignment fault onia64
Jason Gunthorpe
jgunthorpe at obsidianresearch.com
Thu Jan 18 10:41:54 PST 2007
On Thu, Jan 18, 2007 at 07:50:35PM +0200, Michael S. Tsirkin wrote:
> > The int -> long change is needed because struct ib_umad_packet
> > includes struct ib_user_mad (which has 4 byte alignment) but
> > is then cast to struct ib_mad_hdr which has 8 byte alignment.
> But I thought it is the data field which is cast to ib_mad_hdr
> and not ib_user_mad? If so Jason's suggestion of using
> u64 data[0]
> makes more sense.
I'm not sure why, but on closer inspection the code in user_mad.c
actually casts both mad.data[0] and mad to ib_mad_hdr (it looks
'correct' but inconsistent, see the last copy_from_user in
ib_umad_write)
So, changing the data[0] to u64 should still fix both since it will
place the .data casting region on the correct alignment and increase
the alignment requirement of ib_user_mad - but it is indirect that the
2nd cast is corrected..
> > Plus you only get the pad if you actually need it.
> You mean, no pad if ib_user_mad_hdr is used separately?
That and platforms that don't require 8 byte alignment for u64 will
not generate pads.
John:
Open ended structures always require care when selecting the type used
for the 0 size array so that it 'matches' the structures you intend to
cast it to. Unless you are using it for a string, u8 is always a bad
choice :>
Jason
More information about the general
mailing list