On Sun, 2012-05-06 at 22:47 +0400, Michael Tokarev wrote:
> Now when kernel has more or less nice interface which works
> with all variants of userspace to date, maybe it's time to
> revert the commit which enables different struct size for
> kernels > 3.3, especially since that commit was initially
> wrong (since it does not take into account any stable trees
> and possible backports to other previous versions)?
We will need to use something similar to the patch I already sent you as
kernel releases don't get unreleased so I will need to cater for it.
>
> And as I already pointed out, why the newly introduced linux
> version code is buggy and expects that the version string is
> always 3-component? We have a timeout, so to say, to fix this
> assumption in userspace, and almost all software already did
> so, and now we introduce _new_ code which has the same bug.
I'll fix that.
Actually it's worse than that. automount is threaded so I should be
using strtok_r().
> I'm talking about this piece:
>
> static inline unsigned int linux_version_code(void)
> {
> struct utsname my_utsname;
> unsigned int p, q, r;
>
> if (uname(&my_utsname))
> return 0;
>
> p = (unsigned int)atoi(strtok(my_utsname.release, "."));
> q = (unsigned int)atoi(strtok(NULL, "."));
> r = (unsigned int)atoi(strtok(NULL, "."));
> return KERNEL_VERSION(p, q, r);
> }
>
> This is wrong, since last strtok() may return NULL, and atoi() will
> crash with SIGSEGV. Strictly speaking even the second strtok may
> return NULL already, but that is much, much less likely.
>
> But really, why this piece of code is _ever_ needed, why we need
> information about linux version?
Because mount.nfs changed to use the kernel to parse nfs mount options
based on kernel version. The kernel RPC code works very differently to
the user space RPC code, since it must wait if a host doesn't respond
where that isn't so important for user space, which leads to long
timeout delays. That's the way it should be done, of course, but for an
interactive application like automount everyone complains about it.
Basically, automount must RPC ping hosts at some point in the mount
trigger to mitigate this.
snip ...
>
> And btw, is there some public autofs userspace git/whatever repository
> where one can see current state of the package?
git clone git://git.kernel.org/pub/scm/linux/storage/autofs/autofs
>
> Thank you!
>
> /mjt
> --
> 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
--
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
