On Wed, Feb 29, 2012 at 01:25:28PM -0600, Jonathan Nieder wrote:
> From: Ian Kent <[email protected]>
> Date: Wed, 22 Feb 2012 20:45:44 +0800
>
> commits a32744d4abae24572eff7269bc17895c41bd0085,
> 3c761ea05a8900a907f32b628611873f6bef24b2, and
> 048cd4e51d24ebf7f3552226d03c769d6ad91658 upstream.
Could I just apply these 3 patches instead of this mushed-together one?
> When the autofs protocol version 5 packet type was added in commit
> 5c0a32fc2cd0 ("autofs4: add new packet type for v5 communications"), it
> obvously tried quite hard to be word-size agnostic, and uses explicitly
> sized fields that are all correctly aligned.
>
> However, with the final "char name[NAME_MAX+1]" array at the end, the
> actual size of the structure ends up being not very well defined:
> because the struct isn't marked 'packed', doing a "sizeof()" on it will
> align the size of the struct up to the biggest alignment of the members
> it has.
>
> And despite all the members being the same, the alignment of them is
> different: a "__u64" has 4-byte alignment on x86-32, but native 8-byte
> alignment on x86-64. And while 'NAME_MAX+1' ends up being a nice round
> number (256), the name[] array starts out a 4-byte aligned.
>
> End result: the "packed" size of the structure is 300 bytes: 4-byte, but
> not 8-byte aligned.
>
> As a result, despite all the fields being in the same place on all
> architectures, sizeof() will round up that size to 304 bytes on
> architectures that have 8-byte alignment for u64.
>
> Note that this is *not* a problem for 32-bit compat mode on POWER, since
> there __u64 is 8-byte aligned even in 32-bit mode. But on x86, 32-bit
> and 64-bit alignment is different for 64-bit entities, and as a result
> the structure that has exactly the same layout has different sizes.
>
> So on x86-64, but no other architecture, we will just subtract 4 from
> the size of the structure when running in a compat task. That way we
> will write the properly sized packet that user mode expects.
>
> Not pretty. Sadly, this very subtle, and unnecessary, size difference
> has been encoded in user space that wants to read packets of *exactly*
> the right size, and will refuse to touch anything else.
>
> [jn: with compilation fixes for !COMPAT case and !COMPAT case on s390
> by Linus Torvalds and Heiko Carstens squashed in]
>
> Reported-and-tested-by: Thomas Meyer <[email protected]>
> Signed-off-by: Ian Kent <[email protected]>
> Signed-off-by: Linus Torvalds <[email protected]>
> Tested-by: Sven Joachim <[email protected]>
> Signed-off-by: Jonathan Nieder <[email protected]>
> ---
> Hi Greg,
>
> Sven Joachim wrote[1]:
>
> > Today I installed and booted (with init=/bin/systemd) systemd for the
> > first time. Alas, it does not work for me. :-( The last output on the
> > screen was from systemd-fsck which successfully checked the root
> > partition, then the boot hung without further output requiring to reboot
> > with SysRq-b.
>
> It turned out to be a 32-bit userspace/64-bit kernel compat problem.
> The broken interface was introduced in v2.6.17-rc1~444 but I guess
> the problem has become more noticeable recently because systemd uses it.
> So longterm kernels can use this fix, too.
So, back to as far as possible, right?
> Luckily the fix is in mainline:
>
> [...]
> > 3.3-rc5 works for me, as does 3.2.7 with the following changes
> > cherry-picked:
> >
> > a32744d4abae (autofs: work around unhappy compat problem on x86-64)
> > 3c761ea05a89 (Fix autofs compile without CONFIG_COMPAT)
> > 048cd4e51d24 (compat: fix compile breakage on s390)
I'd prefer to keep the same patches in stable as was in Linus's tree, to
make things easier to track overall.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
