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
