Re: [PR19826] fix non-LE TLS in static programs

[Alexandre Oliva <aoliva at redhat dot com>]

On Sep 29, 2016, Torvald Riegel <triegel@redhat.com> wrote:

> Consider an exaggerated but similar example:  I want to add a
> non-trivial piece of code, and like to reason about it using notes on
> paper.  Yet glibc has decided that it wants comments in the code.  What
> should I do?  Should I just give up, or try to find a way to do what
> glibc wants and how it decided to maintain the code base (eg, finding a
> back-and-forth conversion between glibc model of taking notes and mine)?

IMHO the important question is not what *you* should do in this
scenario, but what should the GNU Libc community do, when an occasional
contributor comes up with a fix for an existing bug.  Should you boss
around playing language police and demand further unrelated changes, so
as to push the contributor away, or should you welcome and thank the
contribution so that the contributor feels welcome and inclined to come
back?

> Right.  But we also need to consider that more than one person will
> eventually want to maintain any piece of glibc code.

We also have to consider that by the time some of these people do, the
standards will have changed again, and the language in the comments will
again no longer be in line with the newer consensus of the community.
That's already happened.  As much as you want to portray things this
way, some key concepts have not changed, nor have they been ruled out of
the vocabulary.

> Can you fix this to use C11 atomics (or even the old-style atomics if
> you're not comfortable with using C11 atomics yet), please?

Of course not.  I have a lot of other work to do, and absolutely zero
interest in going through the pain of trying to get anything vaguely
concurrency-related into glibc, as much as I have studied and been
interested in this area.  That's unfortunate for glibc, that I'm still
somewhat responsible for, but I just can't stand this pain.

>> but IIRC there are
>> self-concurrency issues if DTV resizing is interrupted by a signal that
>> uses GD and starts further resizing) and IIRC there is plenty of
>> suspicious stuff in slotinfo manipulation vs use (the data structure is
>> only modified while holding the rtld lock, but it's read while updating
>> a DTV without any explicit synchronization; I never looked into it
>> enough to tell what the assumptions were that make it safe at some
>> point, to tell whether there's any chance they still are);

> That sounds like a incorrect attempt at double-checked locking, which
> I've found several cases of so far, so it would be "within the pattern".

I don't see how you could possibly have drawn that conclusion, since the
readers do NOT take locks, before or after any test.

> Also note that even if assuming a strong memory model, some of the nscd
> synchronization would be broken.

> Furthermore, you reviewed nscd-related code and marked it as
> thread-safe.

The review was limited to functions provided by glibc and documented in
the glibc manual.  nscd provides none.  So your claim that I reviewed
them may very well be the result of a misunderstanding leading to an
incorrect assumption.

Regardless, if you found any comments about nscd code in my
thread-safety annotations (and presumably corrected them), it would have
been polite (and appreciated) for you to copy me, so that I could have
been informed and educated about the changes.  I don't have recollection
of having been copied on any such messages.

> I find it surprising that you think it wasn't surprising that the
> synchronization in nscd is buggy.

I vaguely recall finding a few nss synchronization problems in nss
plgins years before the thread-safety review and documentation project
started.  That's why I wasn't surprised by the existence of
synchronization porblems in that general area, even though nss plugins
were not part of the review.

> I'm missing some detail in the description of the case, so I can't say
> whether it would or would not be a data race in how the variable is
> communicated.  But irrespective of whether the 

(-:  If this message didn't end at this comma,

-- 
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 Brasil GNU Toolchain Engineer