Re: [PATCH v7] nptl: Fix Race conditions in pthread cancellation [BZ#12683]

[Carlos O'Donell <carlos@redhat.com>]

On 8/31/23 14:30, Florian Weimer wrote:
> * Carlos O'Donell via Libc-alpha:
> 
>> My opinion is that we should consider a model where the syscall is a
>> range of instructions and that creates some interesting implementation
>> details which I will discuss. Without your implementation I would
>> never have thought this necessary, but your requirement to go back to
>> legacy single instruction syscalls raises a yellow flag for me here.
> 
> I think it's not fair to bring up hypothetical glibc ports that may
> never be submitted upstream.  We should evaluate the change in the
> context of the present sources and supported architectures.

Sorry, I don't follow.

I agree with you completely, we should focus on current ports, but the open question
about how to support those current ports without regression.

In Adhemerval's v7 implementation the i686 and ia64 ports loose vDSO support for
cancellable syscalls. That is a regression for existing ports?

The more technical question is: Will vDSO functions intersect the set of functions
for which we have cancellation points today?

And the answer is that they don't really.

We have vDSO routines for:

* clock_gettime
* clock_gettime64
* gettimeofday
* time
* getcpu
* clock_getres
* clock_getres_time64
* get_tbfreq (POWER-specific)

None of these are really cancellable to begin with, but if we're talking about
fundamental modelling of the cancellation in glibc, I'm asking specifically about
i686.

-- 
Cheers,
Carlos.