Reiser4 changes meaning of ENOENT/EACCES, breaking gcc?

Reiser4 changes meaning of ENOENT/EACCES, breaking gcc?

[Perry Kundert]

Hello;

    I am running 2.6.5 patched wtih Debian package 
"kernel-patch-2.6-reiser4", varsion 20040326-2.  So far, my uptime is 65 
days, running a quite active Apache/NFS/WiFi/Shorewall server.  Some 
known problems with corruption of Mozilla's configuration and mail files 
when it accesses them over NFS (and corruption of files written by the 
"tee" program, oddly enough), but everything else seems to work fine.  
Until now...

    I am attempting to build openzaurus.  Along the way it builds glibc, 
which fails due to the following problem (see below).

    Question:  has reiser4 changed the semantics of accessing 
directories and files in such a way that we should expect similar 
failures in other programs that use error codes to distinguish between 
files and directories?  Is this a known/expected issue that is not 
expected to cause too many problems?

    By the way, his suggested workaround was effective...

--
    -pjk



>Situation: reiser4 filesystem, wd contains an ordinary file mode 0644 named
>'nss'. (This is important).
>
>Cause: in gcc/cppfiles.c,
>_cpp_find_file() calls find_file_in_dir() on . for nss/nsswitch.h
>find_file_in_dir() calls open_file() on ./nss/nsswitch.h
>open_file() calls open() on ./nss/nsswitch.h
>Instead of failing ENOTDIR, open() fails EACCES. This is because under reiser4
>all files are directories so ENOTDIR is unused as an error code; instead it
>tries to read 'nss' as a directory but as 'nss' is 0644 its "directory contents"
>are not accessible.
>On any normal file system, open() fails ENOTDIR, open_file() returns false
>converting ENOTDIR to ENOENT, find_file_in_dir() returns false, and
>_cpp_find_file() continues to the next node in the include list, eventually
>finding nss/nsswitch.h in -I..
>On reiser4, open() fails EACCES, open_file() returns false, find_file_in_dir()
>calls open_file_failed() and returns true, everything falls apart.
>
>The workaround I suggest for glibc is to make 'nss' 0755 thus causing open() to
>fail ENOENT which causes _cpp_find_file_in_dir() to continue to the next node in
>the include list.
>
>The fix I suggest for gcc is to make EACCES non-fatal: gcc should instead of
>failing print a warning message and continue searching for an include file it
>can access. 
>
>The patch is obvious and I will attach it as soon as I have tested it properly.
>
>-- 
>           Summary: "Permission denied" compiling glibc 2.3.3 on reiser4:
>                    EACCES fatal to #include
>           Product: gcc
>           Version: 3.4.0
>            Status: UNCONFIRMED
>          Severity: normal
>          Priority: P2
>         Component: c
>        AssignedTo: unassigned at gcc dot gnu dot org
>        ReportedBy: ed at catmur dot co dot uk
>                CC: gcc-bugs at gcc dot gnu dot org
>
>
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15772
>

Re: Reiser4 changes meaning of ENOENT/EACCES, breaking gcc?

[Hans Reiser]

Perry Kundert wrote:

> Hello;
>
>    I am running 2.6.5 patched wtih Debian package 
> "kernel-patch-2.6-reiser4", varsion 20040326-2.  So far, my uptime is 
> 65 days, running a quite active Apache/NFS/WiFi/Shorewall server.  
> Some known problems with corruption of Mozilla's configuration and 
> mail files when it accesses them over NFS (and corruption of files 
> written by the "tee" program, oddly enough), but everything else seems 
> to work fine.  Until now...
>
>    I am attempting to build openzaurus.  Along the way it builds 
> glibc, which fails due to the following problem (see below).
>
>    Question:  has reiser4 changed the semantics of accessing 
> directories and files in such a way that we should expect similar 
> failures in other programs that use error codes to distinguish between 
> files and directories?

Well, we made files act as directories for their metafiles, so, yes.

> Is this a known/expected issue

no, I didn't know that there were many programs that did this.  It is a 
little bit too be expected though.   Is the testing code by any chance 
written by David Woodhouse?

> that is not expected to cause too many problems?
>
>    By the way, his suggested workaround was effective...

Can you talk the glibc guys into adopting it?  That would be best.

>
> -- 
>    -pjk
>
>
>
>> Situation: reiser4 filesystem, wd contains an ordinary file mode 0644 
>> named
>> 'nss'. (This is important).
>>
>> Cause: in gcc/cppfiles.c,
>> _cpp_find_file() calls find_file_in_dir() on . for nss/nsswitch.h
>> find_file_in_dir() calls open_file() on ./nss/nsswitch.h
>> open_file() calls open() on ./nss/nsswitch.h
>> Instead of failing ENOTDIR, open() fails EACCES. This is because 
>> under reiser4
>> all files are directories so ENOTDIR is unused as an error code; 
>> instead it
>> tries to read 'nss' as a directory but as 'nss' is 0644 its 
>> "directory contents"
>> are not accessible.
>> On any normal file system, open() fails ENOTDIR, open_file() returns 
>> false
>> converting ENOTDIR to ENOENT, find_file_in_dir() returns false, and
>> _cpp_find_file() continues to the next node in the include list, 
>> eventually
>> finding nss/nsswitch.h in -I..
>> On reiser4, open() fails EACCES, open_file() returns false, 
>> find_file_in_dir()
>> calls open_file_failed() and returns true, everything falls apart.
>>
>> The workaround I suggest for glibc is to make 'nss' 0755 thus causing 
>> open() to
>> fail ENOENT which causes _cpp_find_file_in_dir() to continue to the 
>> next node in
>> the include list.
>>
>> The fix I suggest for gcc is to make EACCES non-fatal: gcc should 
>> instead of
>> failing print a warning message and continue searching for an include 
>> file it
>> can access.
>> The patch is obvious and I will attach it as soon as I have tested it 
>> properly.
>>
>> -- 
>>           Summary: "Permission denied" compiling glibc 2.3.3 on reiser4:
>>                    EACCES fatal to #include
>>           Product: gcc
>>           Version: 3.4.0
>>            Status: UNCONFIRMED
>>          Severity: normal
>>          Priority: P2
>>         Component: c
>>        AssignedTo: unassigned at gcc dot gnu dot org
>>        ReportedBy: ed at catmur dot co dot uk
>>                CC: gcc-bugs at gcc dot gnu dot org
>>
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15772
>>
>
>

Re: Reiser4 changes meaning of ENOENT/EACCES, breaking gcc?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

On Fri, 30 Jul 2004 11:57:35 PDT, Hans Reiser said:

> >    By the way, his suggested workaround was effective...
> 
> Can you talk the glibc guys into adopting it?  That would be best.

Somebody should also check the POSIX spec and see if it requires a
particular semantic there.

Also, pushing it off to the glibc people is quite possibly the wrong
way to go about it.  Do you *really* want to sit there and tell every
other app that turns up with a similar problem that they have to fix
it to run on one particular filesystem, when every OTHER filesystem
doesn't need help?  That doesn't sound like a good plan - if 4 or 5
apps turn up, it will turn people away "because stuff breaks if you
use reiser4"....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Reiser4 changes meaning of ENOENT/EACCES, breaking gcc?

[Hans Reiser]

Valdis.Kletnieks@vt.edu wrote:

>On Fri, 30 Jul 2004 11:57:35 PDT, Hans Reiser said:
>
>  
>
>>>   By the way, his suggested workaround was effective...
>>>      
>>>
>>Can you talk the glibc guys into adopting it?  That would be best.
>>    
>>
>
>Somebody should also check the POSIX spec and see if it requires a
>particular semantic there.
>
>Also, pushing it off to the glibc people is quite possibly the wrong
>way to go about it.  Do you *really* want to sit there and tell every
>other app that turns up with a similar problem that they have to fix
>it to run on one particular filesystem, when every OTHER filesystem
>doesn't need help?  That doesn't sound like a good plan - if 4 or 5
>apps turn up, it will turn people away "because stuff breaks if you
>use reiser4"....
>
>  
>
That is the cost of progress.  Just look at all the confusion caused by 
phasing out horse whips and using gas pedals instead.....

We are adding functionality.  The standards will adjust to that in 5 
years.  I am 40, 5 years seems like not so long....