[haiku-commits] Re: haiku: hrev52902 - in src: add-ons/kernel/busses/usb add-ons/kernel/bus_managers/usb system/kernel system/kernel/arch/x86
- From: waddlesplash <waddlesplash@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 20 Feb 2019 10:24:59 -0500
On Wed, Feb 20, 2019 at 9:48 AM Rene Gollent <anevilyak@xxxxxxxxx> wrote:
I'm not sure how that example contradicts what Axel said. Pinning a
thread, as its name implies, does nothing more than lock its execution
to only occurring on the current CPU until it's unpinned again (c.f.
http://xref.plausible.coop/source/xref/haiku/src/system/kernel/scheduler/scheduler.cpp#107
). This is necessary in e.g. the VM code since it may be manipulating
the per-CPU TLB, which would obviously be problematic if the thread is
rescheduled onto another CPU in the middle of the process.
OK.
Pinning the thread does not prevent it from being context switched,
that's never been the case. AFAIK, the only thing that can cause the
latter is if interrupts are disabled, as the scheduler's timer
interrupt will obviously not fire in that circumstance. In your VM
example, Flush() is only ever called with the map locked, so a context
switch isn't an issue, as anyone else attempting to access the map
will block on the lock until the thread handling the modification is
done.
OK, so then my prior statement is correct that there is no way from
blocking an implicit context-switch except by disabling interrupts.
What about an explicit context switch, like thread_block?
What I was trying to prevent here was drivers context-switching
illegally from the interrupt handler, which deadlocks the whole
system. I've added panics to all the usual methods (sems, snooze) and
others already had them before I started looking into this (mutexes,
cvars), but since thread_block must be called with interrupts already
disabled, we can't really check for anything in particular there. We
can't rely on the spinlock code to detect these cases either; as
hardware interrupts will always occur on a specific CPU, if someone
context-switched or otherwise blocked the interrupt handler with the
interrupt vector spinlock held, we will probably just not get the next
interrupt at all.
I guess I've learned my lesson though, these kinds of commits really
should go through Gerrit.
-waddlesplash
Other related posts:
