[PATCH v5] um: Enable preemption in UML

[Anton Ivanov]

On 22/09/2023 08:40, Johannes Berg wrote:
> On Fri, 2023-09-22 at 08:38 +0100, Anton Ivanov wrote:
>>> I had enabled CONFIG_DEBUG_ATOMIC_SLEEP because that's actually
>>> something I'd really like to have in our testing.
>>>
>>> But with that issue I don't even know how we get there really. It
>>> doesn't even happen every time we fork?
>>>
>>> I'll dig a little bit, but did you try enabling
>>> CONFIG_DEBUG_ATOMIC_SLEEP also?
>> Will do. I have no crashes over here so I need to trigger this one first.
>>
>> Though, frankly, if it is a race in a tlb flush it may be subject to local conditions. So it will be difficult to reproduce.
>>
> Yes, it might be a race in the fork handler maybe? IOW, whenever we
> actually do fork, it depends on what conditions the rest is in? I'm not
> sure I fully figured out right now how the fork handler is doing all
> this, but I sent my mail before I could since you were discussing :)
>
> But it shouldn't be impossible - while I don't see it for every fork, it
> does happen 8 or 9 times in a very simple test that just boots, pings a
> bit, and then shuts down, so ...

My favorite test which I run on all changes is:

find /usr -type f -exec cat {} > /dev/null \;

On Debian this forks /bin/cat for each file and does IO on it. That test passes here every time :(

However, I did not have debug turned on. So, I would not be surprised if something in the debug

portion of the config makes the crashes more likely.

Otherwise, each fork is a forced tlb_flush_all, so it is a massive tlb exercise. Any bugs, locking, etc are likely to show up.

>
> johannes
>
-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/