----- Original Message ----- | On Wed, Mar 15, 2017 at 7:32 AM, Bob Peterson <rpete...@redhat.com> wrote: | > | > Andreas Gruenbacher (1): | > gfs2: Avoid alignment hole in struct lm_lockname | | So I've pulled this because I think it fixes a real bug, but honestly | I think it's the wrong fix. | | Marking that lm_lockname structure "packed, aligned(4)" means that the | compiler will now think that the 64-bit fields in it may be unaligned | - including on architectures where that can be very expensive and the | compiler now might generate stupid unaligned instruction sequences to | load those values. | | So the *correct* fix, I think, would have been: | | - add a comment about not having holes in the struct due to the hashing | | - sort the fields by size (so "ln_number" first, then "ln_sbd", then | "ln_type") | | - use offsetofend(struct lm_lockname, ln_type) instead of sizeof() when | hashing | | which avoids the "possibly generate garbage code" issue due to the | quick-and-dirty one-liner approach. | | Hmm? | | Linus
Hi Linus, Thanks. Yes, good ideas. I see your point and I'll see if we can get that fixed up for the next merge window. Bob Peterson
