[Bug 195882] Local DoS from unprivileged user

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195882

--- Comment #9 from Mark Millard <marklmi26-fbsd at 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 enabled.

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.