Date: Mon, 1 Feb 1999 20:19:32 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Robert Watson <robert@cyrus.watson.org> Cc: current@FreeBSD.ORG Subject: Re: swap_page_getswapspace failed (don't do stupid things with /dev/mem) Message-ID: <199902020419.UAA31702@apollo.backplane.com> References: <Pine.BSF.3.96.990201201334.10163A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:So, never do stupid things as root; that's always my moto. Well, so I did
:something stupid as root, but it wasn't inherrently *that* stupid, at
:least not stupid enough to require a hard boot :). Below is the source
:...
:Except I decided to test that feature that overrides the device filename
:(normally /dev/audit). Instead, I chose /dev/mem. Don't do that (ouch).
:The machine began to churn -- ok, so the buffer expands as necessary
:without limit, which is something that will go away once I actually write
:...
:swap_pager_getswapspace: failed
:
:from the kernel. And needless to say, it loops fairly tightly and we
:...
Uh. Mmmmmm...... Hmmmmmm :-)
i = read(fd, &size, sizeof(size));
... malloc(bufsize * sizeof(char))
i = read(fd, buf, bufsize);
When you are reading /dev/mem, 'size' can turn out to be anything.
You are then allocating 'size' bytes ( which could be some insane
value ). Finally, you try to read() from /dev/mem into the buffer
the same insane value.
The system is almost certainly trying to kill this process, but it
can't because the process is stuck in an uninterruptable system read()
of an insane amount of data.
I don't think there is anything to 'fix' here. The system is making
the best of a bad situation. Perhaps, though, we could test for signal
9 within the insanely huge read() loops and pop out.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902020419.UAA31702>