[Buildroot] RFC: Revert uClibc pread/pwrite patches?

Peter Korsgaard jacmet at uclibc.org
Fri Jan 17 15:15:25 UTC 2014


As you probably are all aware of, there hasn't been any uClibc release
in quite a while. Back in September an issue was reported (on IRC I
believe) and the fact that a fix for this and other issues were already
lined up in uClibc git for a release, so I ended up adding
those fixes to BR:

commit 055f1c02d35068d0b089f3b29ffdd4fb2717bb5c
Author: Peter Korsgaard <jacmet at sunsite.dk>
Date:   Fri Sep 6 15:28:51 2013 +0200

    uclibc: add upstream 0.9.33 fixes
    Upstream has a large number of patches lined up for the next 0.9.33.x bugfix
    Add them here, as atleast some of them are quite critical (E.G. the eventfd
    issue gets triggered by recent glib versions).
    I've skipped the microblaze and xtensa fixes as we don't currently support
    those with
    Drop uclibc-0002-Add-definition-of-MSG_WAITFORONE-and-MSG_CMSG_CMSG_CLOEXE.patch
    as that is a subset of uclibc-0035-socket.h-pull-socket_type.h-from-eglibc.patch
    Signed-off-by: Peter Korsgaard <jacmet at sunsite.dk>

One of the issues fixed was that uClibc was still using a pread/pwrite
emulation (using lseek+read/write), even though pread/pwrite has been
natively supported by the kernel since the 2.1.x days - And this
implementation is racy in multithreaded applications.

The system call uses 64bit for the offset parameter, and the
implementation on the 0.9.33 branch unfortunately doesn't take into
consideration architectures with an ABI requiring natural alignment for
64bit arguments (afaik ARM EABI, MIPS O32, PPC, SH and Xtensa), causing
havoc when pread/pwrite is used.

I brought the issue up on the uClibc list back in October, but so far it
hasn't been fixed:


It IS fixed on the main branch, but it looks nontrivial to backport it.

So what do we do?

- Remove the uClibc patches (14, 21, 32 and 54), and tell people running
  into the race condition to use uClibc master / Glibc?

- Backport fix from uClibc master?

- Deprecate and instead use a git snapshot of master?

What do you think?

Bye, Peter Korsgaard

More information about the buildroot mailing list