When the autofs protocol version 5 packet type was added in commit5c0a32fc2cd0 ("autofs4: add new packet type for v5 communications"), itobvously tried quite hard to be word-size agnostic, and uses explicitlysized fields that are all correctly aligned.

However, with the final "char name[NAME_MAX+1]" array at the end, theactual size of the structure ends up being not very well defined:because the struct isn't marked 'packed', doing a "sizeof()" on it willalign the size of the struct up to the biggest alignment of the membersit has.

And despite all the members being the same, the alignment of them isdifferent: a "__u64" has 4-byte alignment on x86-32, but native 8-bytealignment on x86-64. And while 'NAME_MAX+1' ends up being a nice roundnumber (256), the name[] array starts out a 4-byte aligned.End result: the "packed" size of the structure is 300 bytes: 4-byte, butnot 8-byte aligned.

As a result, despite all the fields being in the same place on allarchitectures, sizeof() will round up that size to 304 bytes onarchitectures that have 8-byte alignment for u64.

Note that this is *not* a problem for 32-bit compat mode on POWER, sincethere __u64 is 8-byte aligned even in 32-bit mode. But on x86, 32-bitand 64-bit alignment is different for 64-bit entities, and as a resultthe structure that has exactly the same layout has different sizes.

So on x86-64, but no other architecture, we will just subtract 4 fromthe size of the structure when running in a compat task. That way wewill write the properly sized packet that user mode expects.

Not pretty. Sadly, this very subtle, and unnecessary, size differencehas been encoded in user space that wants to read packets of *exactly*the right size, and will refuse to touch anything else.