From owner-freebsd-hackers  Wed May 10 11:29:17 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id LAA29488
          for hackers-outgoing; Wed, 10 May 1995 11:29:17 -0700
Received: from Root.COM (implode.Root.COM [198.145.90.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA29481
          for <hackers@freebsd.org>; Wed, 10 May 1995 11:29:13 -0700
Received: (dyson@localhost) by Root.COM (8.6.8/8.6.5) id LAA05484; Wed, 10 May 1995 11:31:55 -0700
From: John Dyson <dyson@Root.COM>
Message-Id: <199505101831.LAA05484@Root.COM>
Subject: Re: (fwd) mmap() problem [940412-SNAP, pdksh]
To: adhir@romulus.worldbank.org (Alok K. Dhir)
Date: Wed, 10 May 1995 11:31:54 -0700 (PDT)
Cc: hackers@FreeBSD.org, erandall@reo.dec.com
In-Reply-To: <9505101712.AA29887@romulus.worldbank.org> from "Alok K. Dhir" at May 10, 95 01:12:25 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1602      
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> 
> 
> Not sure - but this looks like a possible bug?  Has this been addressed 
> already?
> 
> Thanks...
This problem has been fixed in -current for about 3-4wks now.  It has
to do with recursive locking of vnodes necessary to afford read/write
of files that have been mmaped into the mmaped region:

fd = open("badfile", O_RDWR);
addr = mmap(...,fd,...);
write(fd,addr,size_of_write);

> 
> Problem #2 - During the "configure" script, it hangs when scanning for
> "mmap()".  A "kill -9" of the parent shell of the "configure" process
> will bring back a prompt ... but the "configure" process is still there.
> Any attempt to "ls" the directory it was in, or "cat" any files in that
> directory, result in another hang.  Oh dear !
> 
> I investigated this in more depth (adding printf's to the .c file used 
> by "configure" for testing "mmap()") and it seems that the hang occurs
> in the read() performed just after the call to "mmap()".
> 
> "Oh well, it's obviously broken" I thought, and hacked "configure" so 
> that "HAVE_MMAP" doesn't get defined, and the problematical test is skipped.
> I now have a working "ksh", all seems well.
> 
> But what of the miscreant "mmap()" ?  Is this a known bug, or should it
> work ?  Has anybody else had similar problems when running the "configure"
> scripts provided with most ports ?

It works now in -current and of course in release.

I did extensive testing on mmap for coherency, etc because of all of the
new code for the merged, fully coherent buffer cache scheme -- but
did not check this specific case.  It does work now.

John
dyson@root.com