On Thu, May 13, 2021 at 11:08:25AM -0500, Scott Cheloha wrote:
> > On May 13, 2021, at 10:57 AM, Visa Hankala wrote:
> >
> > On Thu, May 13, 2021 at 12:04:57AM -0500, Scott Cheloha wrote:
> >> The funky locking dance in softclock() and softclock_thread() is
> >> needed to keep from violating the
> On May 13, 2021, at 10:57 AM, Visa Hankala wrote:
>
> On Thu, May 13, 2021 at 12:04:57AM -0500, Scott Cheloha wrote:
>> The funky locking dance in softclock() and softclock_thread() is
>> needed to keep from violating the locking hierarchy. The
>> timeout_mutex is above the kernel lock, so we
On Thu, May 13, 2021 at 12:04:57AM -0500, Scott Cheloha wrote:
> The funky locking dance in softclock() and softclock_thread() is
> needed to keep from violating the locking hierarchy. The
> timeout_mutex is above the kernel lock, so we need to leave the
> timeout_mutex, then drop the kernel
Hi,
With the removal of the kernel lock from timeout_barrier(9),
softclock() and the timeout thread do not need the kernel lock.
However, many timeouts implicitly rely on the kernel lock.
So to unlock softclock() and the timeout thread I propose adding a new
flag, TIMEOUT_MPSAFE. The flag
