This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [MTASCsft PATCH 10/??] MT-, AS- and AC-Safety docs: manual/filesys.texi
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: codonell at redhat dot com, libc-alpha at sourceware dot org
- Date: Thu, 30 Jan 2014 18:50:07 -0200
- Subject: Re: [MTASCsft PATCH 10/??] MT-, AS- and AC-Safety docs: manual/filesys.texi
- Authentication-results: sourceware.org; auth=none
- References: <ortxelb5zd dot fsf at livre dot home> <or4n4uoncj dot fsf at livre dot home> <ora9elflec dot fsf_-_ at livre dot home> <52EA0A22 dot 3080706 at redhat dot com>
On Jan 30, 2014, "Carlos O'Donell" <carlos@redhat.com> wrote:
> On 01/24/2014 10:29 AM, Alexandre Oliva wrote:
>> Some of the functions in this file had @mtsrace (previously xguargs)
>> because they'd misbehave should the pathnames passed to them as strings
>> be modified concurrently. I've dropped those from this patch.
> Right, I assume you did that because we require users to take care
> that those paths as strings are race free.
Yup
>> Other occurrences of @mtsrace had to do with non-atomic uses of timeval
>> or utimbuf objects passed as arguments; those are not opaque types, so
>> I've dropped the race annotations from them too.
> Same as above.
Ditto
>> The one oddity in this patch is the @mtasurace{:dirstream} annotation in
>> readdir and readdir64. These functions, instead of using static
>> buffers, they return pointers into the internal buffers in the DIR
>> objects they take as arguments. They are MT-Unsafe because the returned
>> object is not safe to use without coordinating with other uses of
>> dirstream, but someone might be surprised by the lack of mentioning a
>> race on an internal buffer, and by the allegation of a race involving
>> the dirstream object, in spite of its being guarded by internal locks.
>> I've considered using say @mtasurace{:dirstream.buf}, but in the end I
>> decided I'd stick with @mtasurace{:dirstream} and ask whether others had
>> better ideas. Anyone?
> I have no better idea :-)
> Patch OK to commit as long as /bsd doesn't render to anything.
Uhh, serious? :-( Later files (signal.texi comes to mind) have plenty
of these, and because on different systems different functions are
implemented in terms of different primitives, we get to different
conclusions depending on whether we take note of kernel-specific safety
issues.
So, if we really want to drop the conditionals, should I do that by
simply removing them, or by introducing a wrapper macro (say @sftcond{})
that discards its argument?
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Toolchain Engineer