From owner-freebsd-current Mon Feb 1 20:19:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA05369 for freebsd-current-outgoing; Mon, 1 Feb 1999 20:19:48 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA05361 for ; Mon, 1 Feb 1999 20:19:45 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id UAA31702; Mon, 1 Feb 1999 20:19:32 -0800 (PST) (envelope-from dillon) Date: Mon, 1 Feb 1999 20:19:32 -0800 (PST) From: Matthew Dillon Message-Id: <199902020419.UAA31702@apollo.backplane.com> To: Robert Watson Cc: current@FreeBSD.ORG Subject: Re: swap_page_getswapspace failed (don't do stupid things with /dev/mem) References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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