Re: [PATCH 1/4] nptl: Fix Race conditions in pthread cancellation, (BZ#12683)

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 23 Sep 2014, Adhemerval Zanella wrote:

> > The aim is to fix all architectures.  For an essentially mechanical change 
> > - converting to a new set of macros - that should be feasible.  It is also 
> > possible to do it bit by bit - because adding the macros doesn't break any 
> > files using the old macros, it isn't necessary to convery all files in the 
> > same commit, if you'd like architecture maintainers to test the 
> > conversions for their architectures.
> 
> It is not just a mechanical change unfortunately: I get rid of 
> *_[enable/disable]_asynccancel

It's only the conversion to SYSCALL_CANCEL that I'm referring to as a 
mechanical change.

> symbol, rewrite the SIGCANCEL handler and some NPTL functions.  A 
> preliminary patch to define SYSCALL_CANCEL to expand to current behavior 
> would mean I would have to conditionally compile the old code while 
> providing the new one and adjust the new behavior to work with old 
> pieces (which is not the patch intended and I see it as usefulness work, 
> since the idea will to get rid of it eventually).

I don't see any adjustment or conditional compilation as needed.  The only 
extra intermediate step I imagine here is one architecture-independent 
definition of the SYSCALL_CANCEL macro (which would later go away); all 
the conversions to use SYSCALL_CANCEL would be in places that would need 
converting anyway.  The aim, again, is to keep the main patch as small as 
possible so it is as easy as possible to review and there is as little as 
possible that architecture maintainers need to understand to make their 
architecture-specific changes.

(But I don't know how many places would end up using SYSCALL_CANCEL if the 
approach taken is preferentially converting such places to use 
syscalls.list instead, so conversions to syscalls.list should take 
priority.)

-- 
Joseph S. Myers
joseph@codesourcery.com