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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <496E5C19.4060305@gmx.de>
Date:	Wed, 14 Jan 2009 22:41:45 +0100
From:	wk <handygewinnspiel@....de>
To:	Chris Mason <chris.mason@...cle.com>
CC:	Matthew Wilcox <matthew@....cx>,
	Andrew Morton <akpm@...ux-foundation.org>, rjw@...k.pl,
	HWerner4@....de, viro@...iv.linux.org.uk,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	mchehab@...radead.org
Subject: Re: [linux-dvb] compiling on 2.6.28 broken?

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

Download attachment "find-4.1.20_old_kernel.log.bz2" of type "application/octet-stream" (28316 bytes)