Date: Tue, 06 Nov 2018 04:11:48 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 195882] Local DoS from unprivileged user Message-ID: <bug-195882-227-yR7fjBhmKl@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-195882-227@https.bugs.freebsd.org/bugzilla/> References: <bug-195882-227@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=3D195882 --- Comment #9 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to rozhuk.im from comment #6) > On 10.1 this cache eat all free mem and all system freeze, if swap not en= abled. In what I describe below I was testing a head -r339076 based FreeBSD on an aarch64 8GiByte system. So I used 16 instead of 4 to scale to twice the RAM size. swapoff -a had been used first so no swap was enabled. First I give the ideas, then comment on the tests of using the ideas. If the file is to stick around and should be fully updated, an fsync before closing would seem to deal with updating the file at the time. If so, the RAM pages should no longer be dirty. That should in turn allow later conversion of such pages to other uses in any process without I/O or such at the time. True even if started after swapoff -a so no swap is available. If the file is to stick around and does not need to be (fully) updated, posix_madvise(mem, write_size, MADV_FREE) before each unmap and use of the fsync before close (to be sure to deal with any dirty pages if the hint is not taken) might be how to hint the intent to the system. Both Active and Inact might end up containing such clean RAM pages that could be put to direct use for other memory requests, if I understand right. True even if started after swapoff -a so no swap is available. So I tried those combinations: The MADV_FREE and fsync combination allowed me to (with swapoff -a before): run, rename the file, run, . . . The same was true for the just fsync variant: run, rename the file, run, . . . So the presence of multiple such 16 GiByte files from past runs (no boots between) did not prevent the next file from being created and used the same way on the 8 GiByte RAM box with no swap space enabled. Clearly the RAM is being made available as needed for this program. In at least the MADV_FREE involved case, both Active and Inact could be large after a run but that did not interfere with later runs: the RAM pages became available as needed without needing to be swapped first. If there is something I missed in the test structure, let me know. --=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-195882-227-yR7fjBhmKl>