Re: curious file access problem

[Sebastian Gottschall <s.gottschall@dd-wrt.com>]

Am 20.08.2015 um 20:30 schrieb Timo Teras:
> On Thu, 20 Aug 2015 11:00:20 -0400
> Rich Felker <dalias@libc.org> wrote:
>
>> On Thu, Aug 20, 2015 at 04:51:56PM +0200, Sebastian Gottschall wrote:
>>> Am 20.08.2015 um 15:48 schrieb Rich Felker:
>>>> On Thu, Aug 20, 2015 at 03:25:39PM +0200, Bastian Bittorf wrote:
>>>>> * Sebastian Gottschall <s.gottschall@dd-wrt.com> [20.08.2015
>>>>> 13:21]:
>>>>>>> i cannot see this prob on openwrt.
>>>>>>> what is your arch and your exact musl version?
>>>>>> same es openwrt. but it seems to be related only to kernel 4.1
>>>>>> (or newer) in 3.18 it does not happen in openwrt
>>>>> i can see it too - not on 3.18 but with kernel 4.1.5
>>>>> you are right, busybox 'route -n' is affected and does not
>>>>> see a default route (the same for hexdump, strings...)
>>>> In that case, it sounds like somebody broke the kernel. This is
>>>> rather unfortunate, and it would be great if someone could look
>>>> into the bug and get it fixed before these broken kernels are too
>>>> widespread...
>>> there are some fib tree enhancements. i nailed it down to a patchset
>>> which i can apply and revert to let the problem show up
>>> the interesting thing is that uclibc doesnt show that behaviour. but
>>> i dont know why. maybe its some sort of application based routing
>>> table?
>> Again, if the bug is in the kernel's tracking of the pseudo-file
>> position state (which seems clear now), then whether it manifests or
>> not is almost certainly a matter of _how_ the reading takes place
>> (small chunks, big chunks, read vs readv vs pread, whether or not
>> seeking is involved, etc.). And this is going to vary between
>> applications, and if stdio is used by the application to perform the
>> reading, then it's also going to vary between stdio implementations
>> (and thus libcs).
> DaveM's net -stable queue has:
> http://patchwork.ozlabs.org/patch/507167/
>
> Sounds like this is the fix for a kernel regression.
>
> /Timo
>
absolutelly. i will try it and give feedback