Re: [PATCH v5] um: Enable preemption in UML

[Anton Ivanov <anton.ivanov@cambridgegreys.com>]

On 22/09/2023 09:13, Johannes Berg wrote:
> On Fri, 2023-09-22 at 09:01 +0100, Anton Ivanov wrote:
>> 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 :(
> Oh, apart from the splat, it all _works_ fine.

The splat is because mm is caused by this:

void force_flush_all(void)
{
     struct mm_struct *mm = current->mm;
     struct vm_area_struct *vma;
     VMA_ITERATOR(vmi, mm, 0);

     mmap_read_lock(mm);

     ^^^^^^^^^^^^^^

     for_each_vma(vmi, vma)
         fix_range(mm, vma->vm_start, vma->vm_end, 1);
     mmap_read_unlock(mm);

     ^^^^^^^^^^^^^^

}

We invoke this on every fork. MM is now locked "gently" using a semaphore and that is supposed to

be sleepable. From there on you get a warning if atomic sleep is enabled.


>
>> However, I did not have debug turned on. So, I would not be surprised if something in the debug
> OK.
>
>> portion of the config makes the crashes more likely.
> It's just a debug warning for me, no real crash.
>
>> 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.
>>
> Yes, but when does the fork actually happen?
>
> That part confuses me - the fork_handler() seems to be called at various
> kind of random points in time after?
Indeed. I am trying to chase it down. It seems harmless at this point, but it would be nice to understand what causes it.
>
> johannes
>
-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um