Date: Thu, 11 Jan 2018 23:46:15 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 224479] kernel panic in reboot+swapoff sys call Message-ID: <bug-224479-8-gsraKYTqDr@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-224479-8@https.bugs.freebsd.org/bugzilla/> References: <bug-224479-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224479 --- Comment #32 from ota@j.email.ne.jp --- (In reply to Conrad Meyer from comment #31) if tmpfs uses large memory so that files on tmpfs were swapped out, the 1st swapoff_all() can fail due to insufficient memory. vfs_unmountall() will unmount and release such tmpfs memory so that 2nd swapoff_all() may be able to swapoff this time; however, if swap spaces left are still NFS files or mdconfig files, we will still get panic. So, I changed swapoff_all() to release in the reverse order swap spaces are added. System adds swap devices at start (given the penalty of mdconfig/NF= S, raw devices are best and most suitable for default entries). When memory and swap space go short, I add md-file or NFS files to avoid immediate issues. So, reverse order in swap_all will take outs manually ad= ded entries first to reduce chances of panic. Actually... if all file systems are already unmounted, any processes get swapped-in from swap spaces cannot do much useful anyway; indeed, we may not need 2nd(existing) swapoff_all()... --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-224479-8-gsraKYTqDr>