Date: Fri, 29 Nov 2024 15:27:05 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 282994] Repeated kernel panics Message-ID: <bug-282994-227-FebNjmd2yI@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-282994-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282994 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open CC| |markj@FreeBSD.org --- Comment #3 from Mark Johnston <markj@FreeBSD.org> --- > 5. They all use RCTL to control resources used by users. The problem is that shm_alloc() assumes that object allocation won't fail, but this is false: - racct rules which restrict swap usage can cause swap_reserve_by_cred() to fail; - some overcommit modes limit swap reservations such that swap_reserve_by_cred() can fail. I suspect that changing your racct rules will work around the problem. RACCT_SWAP works by limiting the maximum number and size of swap-backed objects, rather than swap device usage. In particular, it treats swap object allocation as a "reservation" and that counts against the limit before swap space is actually used. I'm a bit skeptical that this implementation is very useful. I wrote a patch which prevents the crash, but note that you'll get shm object allocation failures instead, which might cause all kinds of problems: https://reviews.freebsd.org/D47839 (In reply to jSML4ThWwBID69YC from comment #1) Changing your racct rules might address these problems as well. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-282994-227-FebNjmd2yI>