From owner-freebsd-current Tue Feb 2 08:18:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA01407 for freebsd-current-outgoing; Tue, 2 Feb 1999 08:16:18 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA01398 for ; Tue, 2 Feb 1999 08:16:13 -0800 (PST) (envelope-from green@unixhelp.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.8.8/8.8.7) with ESMTP id LAA00695; Tue, 2 Feb 1999 11:15:49 -0500 (EST) Date: Tue, 2 Feb 1999 11:15:48 -0500 (EST) From: Brian Feldman X-Sender: green@janus.syracuse.net To: Matthew Dillon cc: Robert Watson , current@FreeBSD.ORG Subject: Re: swap_page_getswapspace failed (don't do stupid things with /dev/mem) In-Reply-To: <199902020419.UAA31702@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 1 Feb 1999, Matthew Dillon wrote: > :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. I did a signal test inside /dev/urandom (probably yet to be committed, but Bruce said he was going to.) There's no reason we can't do one here, but we may have to break read()s of /dev/mem to smaller chunks to allow for this. Maybe there is a better way to break out of a running system call, and have it return immediately, but I haven't seen one. > > -Matt > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman _ __ ___ ___ ___ green@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ ____ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ ____ _____ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message