Date: Thu, 11 Mar 2021 09:13:42 -0800 From: John Baldwin <jhb@FreeBSD.org> To: Hans Petter Selasky <hps@selasky.org>, Konstantin Belousov <kostikbel@gmail.com> Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: d1cbe7908986 - main - Allocating the LinuxKPI current structure from an interrupt thread must be done using the M_NOWAIT flag after 1ae20f7c70ea . Message-ID: <5aaa5f2a-a67d-a495-7f56-a6b31c2494c7@FreeBSD.org> In-Reply-To: <2b1739ab-000c-ca28-5a59-0a3e19ef4591@selasky.org> References: <202103100952.12A9qRKR040117@gitrepo.freebsd.org> <YEiZwWT28AeXzQjA@kib.kiev.ua> <2b1739ab-000c-ca28-5a59-0a3e19ef4591@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5aaa5f2a-a67d-a495-7f56-a6b31c2494c7>