> On 2 May 2024, at 12:27, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, May 01, 2024 at 04:12:14PM -0700, Noah Misch wrote:
>> While writing an injection point test, I encountered a variant of the race
>> condition that f4083c4 fixed. It had three sessions and this sequence of
>> events:
>>
>> s1: local-attach to POINT
>> s2: enter InjectionPointRun(POINT), yield CPU just before injection_callback()
>> s3: detach POINT, deleting the InjectionPointCondition record
>> s2: wake up and run POINT as though it had been non-local
>
> Fun. One thing I would ask is why it makes sense to be able to detach
> a local point from a different session than the one who defined it as
> local. Shouldn't the operation of s3 be restricted rather than
> authorized as a safety measure, instead?
That seems to prevent meaningful use case. If we want exactly one session to be waiting just before some specific
point,the only way to achieve this is to create local injection point. But the session must be resumable from another
session.
Without this local waiting injection points are meaningless.
Best regards, Andrey Borodin.