glibc issues with --enable-kernel=2.6.22.5

Bryan Kadzban bryan at kadzban.is-a-geek.net
Sat Jan 22 10:02:16 PST 2011


Matthew Burgess wrote:
> On Fri, 21 Jan 2011 20:52:56 -0800, Bryan Kadzban
> <bryan at kadzban.is-a-geek.net> wrote:
>> Matthew Burgess wrote:
>>> If we set it to 2.6.30 (there's no point in adding the stable
>>> version as Glibc only checks the major.minor.patch level), we'll
>>> miss out on F_GETOWN_EX (new in 2.6.32 - see
>>> http://lwn.net/Articles/354842/) and recvmmsg (new in 2.6.33 -
>>> see http://lwn.net/Articles/334854/) support.
>> We won't actually miss out on either of those, because that's not
>> what --enable-kernel= changes.  It only removes compatibility code
>> for older kernels; it does *not* cause glibc to omit support for
>> newer syscalls or newer flags (assuming they're in the headers it
>> was built against, and assuming it knows about them at all).  If a
>> program is running against such a glibc on a too-old kernel (that
>> doesn't support those syscalls or flags), it will generally get
>> ENOSYS or EINVAL errors.
> 
> Ah, thanks for the correction.  So while the build won't be the same 
> byte-for-byte (as you say, compat code will be included/omitted
> dependent on the --enable-kernel value), it will be the same
> feature-wise.  If a reader decides to build using an old host kernel,
> they may get ENOSYS/EINVAL with certain Glibc calls, but once they've
> rebooted into the LFS system those same calls will then work.

(And if there's a compatibility shim in glibc, then the library call
will still succeed, but using the shim instead of the real syscall.
Here I'm thinking about functions like pselect() / ppoll(); sometimes
the shim is good enough, and sometimes not.)

But yes.

>> So I don't see a need, feature-wise, to raise the minimum kernel
>> version at all.  :-)
>> 
>> Except for the glibc failures -- but it seems to me that these are 
>> likely due to a bug in glibc.  When the two __ASSUME_BLAHBLAH
>> symbols are defined to different values, I think it's generating
>> incorrect code. But I haven't been able to reproduce it, or strace
>> the test file, or gdb the test file, so I can't tell what the bug
>> is yet.  :-(
> 
> Whilst I don't want to drag this discussion on for too long, I'm not
> sure I follow this though.  I'm sure some of the Glibc failures could
> be due to the fact that those tests are testing for features that the
> host's kernel simply doesn't support, so instead of the expected
> output/return value, they'll be returning ENOSYS/EINVAL.

Well, I'm remembering the previous glibc bug related to __ASSUME_BLAH,
which java tickled.  There, glibc was passing the wrong flags to the
kernel calls under a certain combination of __ASSUME_BLAH symbols,
causing something bad to happen.  (I think it was looping forever on a
futex call?  Something like that.  There was something related to 32-bit
as well, I think.  Anyway.)

(Also note that I'm pretty sure the only thing that --enable-kernel=xxxx
does is change the set of __ASSUME_BLAH symbols that are set.  And I'm
pretty sure that's the only way to change them, too.)

But from looking at the test code, it doesn't appear to be directly
dealing with any of these __ASSUME_BLAH symbols.  It appears to be using
standard pthread_blahblah() functions, so if the test is segfaulting, or
getting the wrong result back, I'd expect that user programs calling the
various pthread APIs would do the same.  So I *think* the cause of the
failure is in the implementation of these functions.

The test seemed to be handling error returns properly (by printing an
error to the log and failing), but that depends on whether the pthread_*
functions were returning errors, too.

Certainly a quick workaround would be to set --enable-kernel=2.6.30 or
so.  If I can get some time later today or tomorrow, I might be able to
find something digging into glibc, but I'm guessing it isn't worth
waiting for me to do so to put a workaround into the book.  :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20110122/d6503bd0/attachment.sig>


More information about the lfs-dev mailing list