This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Cancellation and dlmopen?
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: Florian Weimer <fweimer at redhat dot com>
- Date: Tue, 10 Nov 2015 10:27:19 -0200
- Subject: Re: Cancellation and dlmopen?
- Authentication-results: sourceware.org; auth=none
- References: <56415059 dot 803 at redhat dot com>
On 10-11-2015 00:03, Carlos O'Donell wrote:
> Adhemerval,
>
> In our previous cancellation implementation the use of dlmopen
> would lead to weird issues like this:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1192013
>
> In the old implementation if you called usleep in a dlmopen'd
> libc.so.6 then that libc.so.6 would not have a __libc_multiple_threads
> value > 0 and would not execute cenable/cdisable around the cancellable
> syscalls.
>
> IIUC your work removes these variables as it introduces cancellation
> regions around the syscalls, so we shouldn't see this problem?
>
> Does that sound right?
Currently my patchset still adds the 'optimization' to first check if
program is in single-thread to avoid call the cancellation function.
This is done in sysdep-cancel.h headers.
However, I am currently working on removing the need to actually have
architecture defined sysdep-cancel.h to use the SYSCALL_CANCEL definition
in every cancellation entrypoint (and make easier to port).
>
> Florian,
>
> We were just talking about cases of shared global state and
> this is another one of them that likely impacts static binaries
> and also dlmopen :-)
>
> Cheers,
> Carlos.
>