glibc 2.20 - Issues with async-signal-safe TLS patches and ASan.

["Carlos O'Donell" <carlos at redhat dot com>]

I'm retitling this thread to more accurately reflect the content.

On 01/10/2014 06:27 PM, Roland McGrath wrote:
> I'm very sorry that I let it fester so long and am still far behind on
> replying to the issue, but I think the TLS change is still premature.
> It's been as it was for so long that I am fairly skeptical that it's a
> burning need for 2.19 rather than 2.20 and it's a very hairy and
> subtle change whose ramifications might not be immediately obvious.
> 
> In particular, I don't think anyone has considered all the issues of
> no longer using the canonical malloc path for allocation when a
> non-libc malloc implementation is being used.  I strongly suspect the
> new status quo will break ASan in some cases, for example.

I've started a new thread and asked Konstantin Serebryany to comment
on the potential impact. I see no need for us to futz about, we should
just talk to the experts.

> I'm not going to jump up and down if the strong consensus is against
> me.  But I am not at all sanguine about the level of conservatism
> exercised with regard to this change.  It's clearly my fault for not
> getting more involved earlier, so I don't blame anyone for what
> they've already done in my absence.
> 
> I'm not yet prepared to discuss the technical issues in detail,
> because I need to catch up on the long threads here first.  I will
> make strong efforts to get up to speed and summarize my concerns
> early next week.

I feel like we've been rather conservative with the signal-safe TLS
change. We split it into 4 patches, each orthogonal, removed any
public API pieces, and setup the signal-safe allocator in such a way
that it can be removed later if required. We did a parallelism and
concurrency issues review, we reviewed the code, reviewed the cases
around it in the existing code. I think we had 5-6 people look over
the code. We know it doesn't work for GNU2 TLS, but that's future
work.

The fact that we no longer use malloc for this TLS case is not a
"first" when it comes to using an alternate allocation mechanism for
memory. There are several situations internally where glibc simply
uses mmap directly to get memory and if you don't track those things
then you don't have an accurate picture of memory usage anyway.

The fact that it might break ASan is something I had not considered.
I appreciate your input there.

I still don't think that it should block Paul and Andrew's work to
make TLS vars signal safe. ASan is not a part of glibc, and the
glibc project is beholden only to it's users. Making the project
better is our goal here. Obviously having working tools to debug
memory issues is important, but I don't see how that should block us
from fixing the library. It might be that in 2.20 ASan is inaccurate
and in 2.20.1 it isn't anymore, and we document that and distros
need to know what's what.

Cheers,
Carlos.