[Buildroot] Broken pread() on ARM

[Buildroot] Broken pread() on ARM

[Justin Maggard]

I'm using buildroot on a 32-bit ARM platform, and I have run into
pread issues after recently switching from buildroot-2013.05 to
buildroot-2013.11.  In both cases I'm using a generated uClibc
toolchain, and uClibc 0.9.33.2.  Comparing the strace outputs of both,
the offset shows up differently.  As an extra data point, I tried the
latest uClibc snapshot instead of 0.9.33.2, and it worked fine again.

I see there are a number of extra uClibc patches that were added
between 2013.05 and 2013.11.  Perhaps we have just the right
combination of backports to make some platforms work, while breaking
others?

-Justin

[Buildroot] Broken pread() on ARM

[Justin Maggard]

On Tue, Feb 4, 2014 at 2:26 PM, Justin Maggard <jmaggard10@gmail.com> wrote:
> I'm using buildroot on a 32-bit ARM platform, and I have run into
> pread issues after recently switching from buildroot-2013.05 to
> buildroot-2013.11.  In both cases I'm using a generated uClibc
> toolchain, and uClibc 0.9.33.2.  Comparing the strace outputs of both,
> the offset shows up differently.  As an extra data point, I tried the
> latest uClibc snapshot instead of 0.9.33.2, and it worked fine again.
>
> I see there are a number of extra uClibc patches that were added
> between 2013.05 and 2013.11.  Perhaps we have just the right
> combination of backports to make some platforms work, while breaking
> others?
>

Okay, it looks like some of the pread/pwrite changes that have made
their way into the uClibc 0.9.33 branch fail to consider some
architectures.  I have made a rather odd-looking change locally that
makes it work for me on my ARM platform, which uses _syscall6() for
pread() and pread64() if __UCLIBC_TRUNCATE64_HAS_4_ARGS__ is defined.
Would that be worth sending to the list, or would it be better to fix
it some other way?

-Justin

[Buildroot] Broken pread() on ARM

[Peter Korsgaard]

>>>>> "Justin" == Justin Maggard <jmaggard10@gmail.com> writes:

 > I'm using buildroot on a 32-bit ARM platform, and I have run into
 > pread issues after recently switching from buildroot-2013.05 to
 > buildroot-2013.11.  In both cases I'm using a generated uClibc
 > toolchain, and uClibc 0.9.33.2.  Comparing the strace outputs of both,
 > the offset shows up differently.  As an extra data point, I tried the
 > latest uClibc snapshot instead of 0.9.33.2, and it worked fine again.

 > I see there are a number of extra uClibc patches that were added
 > between 2013.05 and 2013.11.  Perhaps we have just the right
 > combination of backports to make some platforms work, while breaking
 > others?

Yes, unfortunately. See
http://lists.busybox.net/pipermail/buildroot/2014-January/087050.html
for details.

uClibc upstream is unfortunately not very active at the moment, so for
2014.02 I will simply revert patch 14, 21, 32 and 54.

-- 
Bye, Peter Korsgaard

[Buildroot] Broken pread() on ARM

[Peter Korsgaard]

>>>>> "Justin" == Justin Maggard <jmaggard10@gmail.com> writes:

Hi,

 > Okay, it looks like some of the pread/pwrite changes that have made
 > their way into the uClibc 0.9.33 branch fail to consider some
 > architectures.  I have made a rather odd-looking change locally that
 > makes it work for me on my ARM platform, which uses _syscall6() for
 > pread() and pread64() if __UCLIBC_TRUNCATE64_HAS_4_ARGS__ is defined.
 > Would that be worth sending to the list, or would it be better to fix
 > it some other way?

The best approach would be to get it fixed in uClibc git (and preferably
to get them to finally release 0.9.33.3).

This particular issue also fixed on the uClibc master branch (E.G. what
should become 0.9.34) - But when I had a look at it, it didn't seem
trivial to backport.

-- 
Bye, Peter Korsgaard

[Buildroot] Broken pread() on ARM

[Justin Maggard]

On Tue, Feb 4, 2014 at 11:49 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Justin" == Justin Maggard <jmaggard10@gmail.com> writes:
>
> Hi,
>
>  > Okay, it looks like some of the pread/pwrite changes that have made
>  > their way into the uClibc 0.9.33 branch fail to consider some
>  > architectures.  I have made a rather odd-looking change locally that
>  > makes it work for me on my ARM platform, which uses _syscall6() for
>  > pread() and pread64() if __UCLIBC_TRUNCATE64_HAS_4_ARGS__ is defined.
>  > Would that be worth sending to the list, or would it be better to fix
>  > it some other way?
>
> The best approach would be to get it fixed in uClibc git (and preferably
> to get them to finally release 0.9.33.3).
>
> This particular issue also fixed on the uClibc master branch (E.G. what
> should become 0.9.34) - But when I had a look at it, it didn't seem
> trivial to backport.
>

Thanks for your answer.  A workable backport doesn't look all that
difficult -- just a bit ugly.  I submitted a kinda-sort backport at
http://lists.uclibc.org/pipermail/uclibc/2014-February/048220.html .
But I can't argue with just reverting those patches in the next
busybox.  I never had a problem with the old pread/pwrite emulation in
the first place.  Hopefully uClibc 0.9.33.3 doesn't get released with
this problem though.

-Justin

[Buildroot] Broken pread() on ARM

[Peter Korsgaard]

>>>>> "Justin" == Justin Maggard <jmaggard10@gmail.com> writes:

Hi,

 > Thanks for your answer.  A workable backport doesn't look all that
 > difficult -- just a bit ugly.  I submitted a kinda-sort backport at
 > http://lists.uclibc.org/pipermail/uclibc/2014-February/048220.html .

Yes, I saw. With all the uClibc mess (especially as we also support
external uClibc based toolchains) I really prefer to not add any more
patches if possible.

 > But I can't argue with just reverting those patches in the next
 > busybox.  I never had a problem with the old pread/pwrite emulation in
 > the first place.

No, it only triggers in rare cases. Afaik the issue is about locking
between the lseek and read/write, so it should only be an issue if you
have an application doing pread/pwrite from multiple threads with the
same file descriptor.

git gc was apparently such a case.


 > Hopefully uClibc 0.9.33.3 doesn't get released with this problem
 > though.

Lets hope not.

-- 
Bye, Peter Korsgaard