> You're ignoring the background question - we expressly _stopped_ doing > this long ago. So the real issue was the ".. if you really .." part.> > Do we really? What's the actual downside here?

I'm not convinced it was real "express". It was never expressed in acomment or log entry. The change came in (pre-git) with: [PATCH] x86-64 architecture specific sync for 2.5.8and commit 10ffdbb8d605be88b148f127ec86452f1364d4f0 "cleaned up slightly"making the other paths match, with no explanation on the subject.

i386 has never behaved this way, and still doesn't. I would doubt anyother arch ever has. (My fix makes x86_64 and i386 treatment of_TIF_WORK_MASK and any related signal race issues identical.)

The behavior of the test case I posted is just demonstrably wrong. Iknow you're never swayed by the fact that it has always been specifiedand documented clearly to behave this way (in the case of multiplepending signals like the test case). Since it always did on i386, it'seasy to expect that there may be all manner of applications lurkingaround that have depended on the correct semantics in subtle (andprobably intermittent) ways their poor users and maintainers may neverfigure out.

What really irks me about the thought of leaving this wrong is that wehave spent so much effort lately on establishing a simple rule that whenyou set TIF_SIGPENDING it will be acted on. We did this after a lot ofpainful time from a lot of people went into tracking down subtle weirdproblems and races. So, KISS. Make a rule we can rely on, and then bedamn careful that we don't break the rule. That's been serving us well,which is to say preventing it going from two people who can keep trackof what's going with signals on any given day, to zero. Now that rulethat kept life barely comprehensible is amended with, unless it'salready inside signals code or some nearby arch code, or it's a race,or, yeah, I think that's all the cases, but check with--well, noonereally knows, so I don't know who you check with, sorry. You just can'treason about the code if you don't maintain the invariants.

The "actual" downsides include numerous unknowns, and I always forgetnot to be surprised when you aren't scared that we have no idea what-allthe code might actually do. The easy scenarios to think of off handhave downsides like loss of timely signal delivery, where something canchew 15ms of CPU after you killed it. If I try all day I can come upwith more specific cases and maybe even some with instantly terribleoutcomes. But I won't think of them all. The worst ones will come upmuch later (or are already dogging someone unwitting now), when someoneelse sinks lots of time and effort trying to figure out strangemisbehaviors in their systems.