Re: stress-ng process termination issue

Hi All,

I've seen no indication that my alteration to task_terminate() has 
introduced any new problems. My test case however is still not 
succeeding for a long enough continuous run for me to propose this 
change confidently. In any case since this issue presumably does not 
occur often under ordinary system usage I don't think it's worth the 
risk of inclusion at this stage. My virtual machine is regularly locking 
with all sorts of processes stuck in vm_fault_continue after running the 
test case for longer periods. It's possible there's an issue with page 
in from the default pager as the test case exercises swapping very 
intensively. That seems the most likely cause but it's just a guess at 
the moment.

I need to spend more time working out what's happening here and will 
provide an update when I know more. My aim is to get this test run to 
function normally for a 24 hour period before offering any patches for 
inclusion.

Regards,

Mike.

On 29/07/2025 21:22, Michael Kelly wrote:
> Thanks for the quick feedback. I will continue to satisfy myself that 
> it doesn't obviously introduce any new issues. My test case has just 
> hit problems with the default pager (the stack trace suggested it had 
> issues writing so perhaps it had run out of swap space). I'll start it 
> running again over night with a slightly lower memory load. I'll also 
> do some alternative testing, perhaps some large builds and if all is 
> well offer the change as a patch for consideration.
>
> Regards,
>
> Mike.
>
> On 29/07/2025 21:11, Samuel Thibault wrote:
>> Hello,
>>
>> Michael Kelly, le mar. 29 juil. 2025 20:46:24 +0100, a ecrit:
>>> I think that I have an understanding of how this problem arises. 
>>> Apologies
>>> for the long explanation especially if much of this is already 
>>> apparent to
>>> you.
>> Thanks for the investigation and the details!
>>
>>> I've attached my proposal for review. The solution appears clumsy but I
>>> could not see a more trivial method of traversing the list safely 
>>> with the
>>> locks necessarily released for the call to thread_force_terminate().
>> It looks alright to me, just pre-acquiring a reference for the next
>> thread.
>>
>> Samuel
>>
>