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)?
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'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?
Maybe it is better to revert both these commits (whole version code
thing and "adoption" for kernel>= 3.3 for the struct size) now ?
(The fact that it wont work with kernels between 3.3.0 and 3.3.5
(iirc) is not a big issue really, at this point we may just ignore
it, pretending these kernels don't exist... :)
Is there some other code which relies on linux version?
And btw, is there some public autofs userspace git/whatever repository
where one can see current state of the package?
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
