From owner-cvs-all  Sun Jul 23  0:52:28 2000
Delivered-To: cvs-all@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP
	id C0D6537B93F; Sun, 23 Jul 2000 00:52:15 -0700 (PDT)
	(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e6N7qEg21894;
	Sun, 23 Jul 2000 00:52:14 -0700 (PDT)
Date: Sun, 23 Jul 2000 00:52:14 -0700
From: Alfred Perlstein <bright@wintelcom.net>
To: Brian Feldman <green@FreeBSD.org>
Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/kern imgact_elf.c
Message-ID: <20000723005214.J13979@fw.wintelcom.net>
References: <200007230649.XAA77168@freefall.freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <200007230649.XAA77168@freefall.freebsd.org>; from green@FreeBSD.org on Sat, Jul 22, 2000 at 11:49:48PM -0700
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* Brian Feldman <green@FreeBSD.org> [000722 23:50] wrote:
> green       2000/07/22 23:49:48 PDT
> 
>   Modified files:
>     sys/kern             imgact_elf.c 
>   Log:
>   Solve the problem where it is possible to get the kernel stuck in
>   a loop down in pmap_init_pt().  A subtraction causes the number of
>   pages to become negative, that was assigned to an unsigned variable,
>   and there is a lot of iteration.  The bug is due to the ELF image
>   activator not properly checking for its files being the correct size
>   as specified by the ELF header.
>   
>   The solution is to check that the header doesn't ask for part of a
>   file when that part of the file doesn't exist.  Make sure to set
>   VEXEC at the proper times to make the executables immutable (remove
>   race conditions).  Also, the ELF format specifiies header entries
>   that allow embedding of other executables (hence how ld-elf.so.1
>   gets loaded, but not the same as loading shared libraries), so those
>   executables need to be set VEXEC, too, so they're immutable.

%s/VEXEC/VTEXT/g

:)

I'm also concerned that you're using atomic_set_long() rather than
or'ing the flag in, there doesn't seem to be a flag in vnode.h that
could possibly co-exist with VTEXT but clearing all other flags 
introduces an unexpected side-effect.

All your atomic op does right there is slow down the code path, we
aren't doing multithreaded at this point and there's no reason to
give a fake sense of safe-ness.

-Alfred


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message