Re: [linux-dvb] compiling on 2.6.28 broken?

From: wk
Date: Wed Jan 14 2009 - 16:42:21 EST


Chris Mason schrieb:
On Wed, 2009-01-14 at 22:19 +0100, wk wrote:
Chris Mason wrote:
On Tue, 2009-01-13 at 13:38 -0700, Matthew Wilcox wrote:
On Tue, Jan 13, 2009 at 11:37:00AM -0800, Andrew Morton wrote:
I'd have expected to see stat() returning -EOVERFLOW, but it isn't there.

googling around a bit seems to indcate that this might be a glibc issue:

http://sourceware.org/bugzilla/show_bug.cgi?id=1864
http://bugs.gentoo.org/show_bug.cgi?id=146951

But the traces are all using stat64() and fstat64(). And why would it
just start occurring now?
Maybe glibc is using the 64-bit stat calls and returning -EOVERFLOW to
the application when the results from the kernel turn out to be > 32-bit
in size?

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6c31b93a14a453c8756ffd228e24910ffdf30c5d

I'd guess the commit above is related, although I don't see any way for
it to make things interesting without the user doing mount -o inode64.

strace -v should show us more, it would show if the inode numbers coming
out of stat64 are big.

-chris

I cannot fully understand what strace -v outputs (see attachment), but what i see is that 'find' stops after finding a file with d_off = 4294967295
4294967295 = 0xFFFFFFFF, adding any number greater that zero will be greater that 32bits, so this could be the reason for the message "value too large".



I also noticed that i cannot access these files through samba if i boot from 2.6.28 - really strange.
If i reboot older kernels these are visible in samba again and fully accessible.

Attached the log from stracing the command which was ivoked by the Makefile from v4l-dvb.
I guess this is all i could contribute to that problem. Thats stuff for xfs filesystem experts now..

Seems suspect indeed. Could you please attach the strace for the run
that works on the older kernel?

-chris


Shure, is attached. Please note:

2.6.28: {d_ino=53258597, d_off=4294967295, d_type=DT_UNKNOWN, d_reclen=40, d_name="v4l1-compat.ko"}
2.6.26.3: {d_ino=53258597, d_off=2147483647, d_type=DT_UNKNOWN, d_reclen=40, d_name="v4l1-compat.ko"}

Please also note: 0x7FFFFFFF = 2147483647 -> 0xFFFFFFFF = 4294967295

I think i will go back to < 2.6.28, i don't want to risk my files. :-(((

-Winfried

Attachment: find-4.1.20_old_kernel.log.bz2
Description: Binary data