On 23.04.2012 20:29, Michael Tokarev wrote:
> On 23.04.2012 13:19, Ian Kent wrote:
>> On Sun, 2012-04-22 at 19:22 +0400, Michael Tokarev wrote:
>>> This is JFYI for now, I only diagnozed the issue but had
>>> no time to see what's going on.
>>>
>>> The short story is that with 3.0.24 and later kernels,
>>> 32bit autofs stopped working on 64bit kernels, while
>>> it worked before just fine.
>>>
>>> The userspace is of version 5.0.4. Platform is x86.
>>>
>>> The sympthoms of the issue is that automount daemon,
>>> on every access to a (not yet mounted) autofs mount
>>> point, stalls forever, with the process trying to
>>> access it stalling forever too -- this is why the
>>> system didn't reboot, -- it stayed on an attempt to
>>> access one of automount subdirs, somewhere in the
>>> middle.
>
> This is what happens with 3.0.24+:
>
> [pid 15207] read(4, "\5\0\0\0\3\0\0\0\2\0\0\0\35\0\0\0@\17\246\3\0\0\0\0\350\3\0\0\350\3\0\0"..., 304) = 300
> [pid 15207] read(4, <unfinished ...> -- forever.
>
> It wants to read 304 bytes, but kernel only supplies 300
> bytes.
>
> $ file /usr/sbin/automount
> /usr/sbin/automount: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
> $ uname -a
> Linux gandalf 3.0.0-amd64 #3.0.27 SMP Tue Apr 3 16:23:45 MSK 2012 x86_64 GNU/Linux
>
> This is a32744d4abae24572eff7269bc17895c41bd0085
> "autofs: work around unhappy compat problem on x86-64",
> included in 3.0.24:
>
> +static noinline size_t autofs_v5_packet_size(struct autofs_sb_info *sbi)
> +{
> + size_t pktsz = sizeof(struct autofs_v5_packet);
> +#if defined(CONFIG_X86_64) && defined(CONFIG_COMPAT)
> + if (sbi->compat_daemon > 0)
> + pktsz -= 4;
> +#endif
> + return pktsz;
> +}
> +
>
> "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."
>
> So I'm not sure how it worked before this change (from the
> description of the patch it looks like it should not work).
> But it definitely worked for me, and this patch broke it
> for me.
It worked because the userspace apparently does the "rigtht"
think already compensating for the kernel bitness mismatch.
This is a bit funky too, but it should work:
static size_t get_kpkt_len(void)
{
size_t pkt_len = sizeof(struct autofs_v5_packet);
struct utsname un;
uname(&un);
if (pkt_len % 8) {
if (strcmp(un.machine, "alpha") == 0 ||
strcmp(un.machine, "ia64") == 0 ||
strcmp(un.machine, "x86_64") == 0 ||
strcmp(un.machine, "ppc64") == 0)
pkt_len += 4;
}
return pkt_len;
}
So it looks like the kernel/user interface had an error,
userspace adopted to the kernel by doing something, so
it started working. And next kernel adopted to the un-
patched userspace, thus breaking patched userspace.
That's quite messy... :( And I'm not sure what to do
about this, -- the only solution - in my opinion anyway -
is to revert this kernel patch and maybe switch to a
new protocol version.
Thanks,
/mjt
> Should 3.3 work? As far as I can see, it includes the
> same change (which has been backported!), so it may have
> the same _issue_...
--
To unsubscribe from this list: send the line "unsubscribe autofs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
