git: d1cbe7908986 - main - Allocating the LinuxKPI current structure from an interrupt thread must be done using the M_NOWAIT flag after 1ae20f7c70ea .

[Konstantin Belousov]

On Thu, Mar 11, 2021 at 07:17:41PM +0100, Hans Petter Selasky wrote:
> On 3/11/21 6:13 PM, John Baldwin wrote:
> > On 3/10/21 2:09 AM, Hans Petter Selasky wrote:
> > > On 3/10/21 11:04 AM, Konstantin Belousov wrote:
> > > > This probably hangs machine instead of panicing.  In low memory
> > > > condition,
> > > > you do not handle interrupt, which probably mean that the source is not
> > > > silenced, and after EOI the same interrupt will be generated again.
> > > 
> > > Hi,
> > > 
> > > This usually happens during boot. Another possibility is to panic()
> > > there. I don't see so many options.
> > 
> > Is there no way to pre-allocate this?  That is, could we not have all
> > ithreads invoke this during their initialization, and have the module
> > handler for linuxkpi iterate over ithreads allocating one for
> > each ithread during MOD_LOAD?
> > 
> > I think there are few enough ithreads that allocating "extra" ones
> > is probably ok.  Alternatively, you could hook into the path when an
> > interrupt is registered perhaps by passing some sort of INTR_LINUX
> > flag or the like that causes kern_intr.c to allocate one for the
> > associated ithread when the interrupt is registered.
> > 
> 
> Yes, I have a review for that:
> https://reviews.freebsd.org/D29183

And I dislike this.  It is yet another case of introducing consumer-specific
logic into core.  Isn't netepoch example enough?

I presented another patch to Hans, where task and mm allocations are
switched to zones, and the zones have reserve applied. Then allocations
from ithreads use the reserve.

There is one detail there, reserve is finite, for x86 I set it to the
total limit of interrupts. This somewhat breaks if interrupts are
deallocated and reallocated, but I think it is good enough even with
this wart.