Re: [PATCH] Fix problem with file locking used before initialised

[Jeff Johnston <jjohnstn at redhat dot com>]

Patch applied.  I noticed a flaw in that __sinit was unlocked so you could 
conceivably have two threads that called it in a race condition.  I added a lock 
for it and added a check once you acquire the lock that __sdidinit wasn't 
already set.

Thanks,

-- Jeff J.

Antony KING wrote:
> Please find attached a revised version of the following patch (replacing 
> the original submission) which adds some missing #includes of "local.h" 
> in files which had CHECK_INIT() calls added.
>
> (I have also attached the patch file as text this time instead of as a 
> gzip'd attachment for easier perusal).
>
> Cheers,
>
> Antony.
>
> Antony King wrote:
>
> > Please find attached a patch against libc in newlib to fix I a problem 
> > I have encountered in the use of the _flockfile/_funlockfile API on 
> > the standard I/O streams (stderr, stdout and stdin).
> >
> > The problems stems from the fact that the FILE objects for these I/O 
> > streams are initially statically allocated in the global re-entrancy 
> > structure (aka the "impure" pointer) and they are not 100% initialised 
> > by static initialisation. This is overcome by the use of the 
> > CHECK_INIT and _REENT_SMALL_CHECK_INIT macros which complete the 
> > initialisation of the standard FILE I/O objects in a re-entrancy 
> > structure. As part of the initialisation of the standard I/O FILE 
> > objects the file lock objects are initialised.
> >
> > Unfortunately the _flockfile/_funlockfile functions are used before 
> > CHECK_INIT is called and therefore the FILE lock object could end up 
> > in an unknown state depending on the implementation of the FILE lock 
> > object and the method of initialisation. To solve this problem it is 
> > necessary to call CHECK_INIT before _flockfile/_funlockfile are called 
> > in any function that takes a FILE * object as an argument (which 
> > normally is a user level function). The attached patch attempts to fix 
> > this problem.
> >
> > Note that I have modified some machine specific files unfortunately I 
> > am unable to test so you may not wish to commit these changes (powerpc 
> > and arm files).
> >
> > Cheers,
> >
> > Antony.