Re: mmap bug
Arun Sharma writes: > The daemons which are involved in freeing up pages during low memory > conditions qualify as system daemons. Making sure that these daemons > don't block avoids the deadlock. > > -Arun The second solution involves a little more than that. Such as blessing "normal" jobs just enough to allow them to get sufficent resources to avoid a deadlock. One instance of the mmap lockup involves a case where you've got a single process dirtying a memory mapped file which is larger than physical memory. Assuming an otherwise idle system, nearly all available memory in the system will belong to the file's object & it will all be dirty. At some point, the process will trigger a fault on a non-resident page. vm_fault will call the vnode_pager_getpages to read in the faulting page. ffs_getpages (let's assume we're using ffs) will then call ffs_read to read in the pages. ffs_read will try to build a cluster. The deadlock occurs when allocbuf cannot allocate a page for one of the pages in the cluster. Here's a stack trace (from a long, long time ago, May 12th): db> tr vm_page_alloc(caa0a074,d1d,0,c58f7ba0,1fc) at vm_page_alloc allocbuf(c58f7ba0,2000,0,c58c4588,5) at allocbuf+0x3ae getblk(caa0f8c0,68e,2000,0,0) at getblk+0x32e cluster_rbuild(caa0f8c0,801,0,689,370b0) at cluster_rbuild+0x1df cluster_read(caa0f8c0,801,0,689,2000) at cluster_read+0x2cc ffs_read(caa12e28) at ffs_read+0x3ea ffs_getpages(caa12e80) at ffs_getpages+0x22c vnode_pager_getpages(caa0a074,caa12f14,1,0,c9fcdce0) at vnode_pager_getpages+0x4e vm_fault(c9fd28c0,48df9000,3,8,c9fcdce0) at vm_fault+0x484 trap_pfault(caa12fb8,1,48df9000) at trap_pfault+0xaa trap(2f,2f,2f,48df9000,48df9000) at trap+0x1aa calltrap() at calltrap+0x1c The real problem is that the pageout daemon cannot push any pages because (nearly) all the pages available to user-processes are held by the mmap'ed object. The killer is that they are all dirty & that because we're in the middle of doing a cluster read, the vnode is locked so the pageout daemon cannot touch them. A solution would be allowing the faulting process to dip into the system reserves enough so that the vm_page_alloc will succeed, which will allow the cluster read to complete. This will avoid deadlock. I personally think the first solution (always taking write faults) would be far, far better. This would allow the system to avoid getting anywhere near a deadlock situation & to remain responsive. I'm afraid that if we go with the second solution, the system would be unresponsive until the cluster read completed & the pageout daemon was able begin to flush the dirty pages in the offending object. -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: galla...@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
Arun Sharma writes: > The daemons which are involved in freeing up pages during low memory > conditions qualify as system daemons. Making sure that these daemons > don't block avoids the deadlock. > > -Arun The second solution involves a little more than that. Such as blessing "normal" jobs just enough to allow them to get sufficent resources to avoid a deadlock. One instance of the mmap lockup involves a case where you've got a single process dirtying a memory mapped file which is larger than physical memory. Assuming an otherwise idle system, nearly all available memory in the system will belong to the file's object & it will all be dirty. At some point, the process will trigger a fault on a non-resident page. vm_fault will call the vnode_pager_getpages to read in the faulting page. ffs_getpages (let's assume we're using ffs) will then call ffs_read to read in the pages. ffs_read will try to build a cluster. The deadlock occurs when allocbuf cannot allocate a page for one of the pages in the cluster. Here's a stack trace (from a long, long time ago, May 12th): db> tr vm_page_alloc(caa0a074,d1d,0,c58f7ba0,1fc) at vm_page_alloc allocbuf(c58f7ba0,2000,0,c58c4588,5) at allocbuf+0x3ae getblk(caa0f8c0,68e,2000,0,0) at getblk+0x32e cluster_rbuild(caa0f8c0,801,0,689,370b0) at cluster_rbuild+0x1df cluster_read(caa0f8c0,801,0,689,2000) at cluster_read+0x2cc ffs_read(caa12e28) at ffs_read+0x3ea ffs_getpages(caa12e80) at ffs_getpages+0x22c vnode_pager_getpages(caa0a074,caa12f14,1,0,c9fcdce0) at vnode_pager_getpages+0x4e vm_fault(c9fd28c0,48df9000,3,8,c9fcdce0) at vm_fault+0x484 trap_pfault(caa12fb8,1,48df9000) at trap_pfault+0xaa trap(2f,2f,2f,48df9000,48df9000) at trap+0x1aa calltrap() at calltrap+0x1c The real problem is that the pageout daemon cannot push any pages because (nearly) all the pages available to user-processes are held by the mmap'ed object. The killer is that they are all dirty & that because we're in the middle of doing a cluster read, the vnode is locked so the pageout daemon cannot touch them. A solution would be allowing the faulting process to dip into the system reserves enough so that the vm_page_alloc will succeed, which will allow the cluster read to complete. This will avoid deadlock. I personally think the first solution (always taking write faults) would be far, far better. This would allow the system to avoid getting anywhere near a deadlock situation & to remain responsive. I'm afraid that if we go with the second solution, the system would be unresponsive until the cluster read completed & the pageout daemon was able begin to flush the dirty pages in the offending object. -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
On Fri, Aug 13, 1999 at 03:04:43PM +0930, Mark Newton wrote: > Arun Sharma wrote: > > > The second alternative - to mark system daemons as special > > sounds much more attractive. > > Ok, now define the difference between "system daemons" and any other > daemon (or, for that matter, any other process). That's easy. $ ps aux | head USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 23924 5.0 30.2 41312 38716 ?? SSat05PM 191:41.92 /usr/X11R6/bin/ root 0 0.0 0.0 00 ?? DLs 31Jul99 0:02.30 (swapper) root 1 0.0 0.2 504 200 ?? ILs 31Jul99 0:00.05 /sbin/init -- root 2 0.0 0.0 00 ?? DL 31Jul99 0:03.18 (pagedaemon) root 3 0.0 0.0 00 ?? DL 31Jul99 0:00.00 (vmdaemon) root 4 0.0 0.0 00 ?? DL 31Jul99 0:03.55 (bufdaemon) root 5 0.0 0.0 00 ?? DL 31Jul99 12:06.17 (syncer) The daemons which are involved in freeing up pages during low memory conditions qualify as system daemons. Making sure that these daemons don't block avoids the deadlock. -Arun To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
Arun Sharma wrote: > The second alternative - to mark system daemons as special > sounds much more attractive. Ok, now define the difference between "system daemons" and any other daemon (or, for that matter, any other process). - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
On Thu, Aug 12, 1999 at 12:02:19PM +0100, Tony Finch wrote: > Matthew Dillon wrote: > > > >One solution would be to map clean R+W pages RO and force a write fault > >to occur, allowing the system to recognize that there are too many dirty > >pages in vm_fault before it is too late and flush some of them. The > >downside of this is that, of course, we take unnecessary faults. > > Surely they aren't unnecessary faults if they are required for correctness? They _are_ unnecessary faults, if other correct solutions exist. The second alternative - to mark system daemons as special sounds much more attractive. -Arun To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
On Fri, Aug 13, 1999 at 03:04:43PM +0930, Mark Newton wrote: > Arun Sharma wrote: > > > The second alternative - to mark system daemons as special > > sounds much more attractive. > > Ok, now define the difference between "system daemons" and any other > daemon (or, for that matter, any other process). That's easy. $ ps aux | head USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 23924 5.0 30.2 41312 38716 ?? SSat05PM 191:41.92 /usr/X11R6/bin/ root 0 0.0 0.0 00 ?? DLs 31Jul99 0:02.30 (swapper) root 1 0.0 0.2 504 200 ?? ILs 31Jul99 0:00.05 /sbin/init -- root 2 0.0 0.0 00 ?? DL 31Jul99 0:03.18 (pagedaemon) root 3 0.0 0.0 00 ?? DL 31Jul99 0:00.00 (vmdaemon) root 4 0.0 0.0 00 ?? DL 31Jul99 0:03.55 (bufdaemon) root 5 0.0 0.0 00 ?? DL 31Jul99 12:06.17 (syncer) The daemons which are involved in freeing up pages during low memory conditions qualify as system daemons. Making sure that these daemons don't block avoids the deadlock. -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
Arun Sharma wrote: > The second alternative - to mark system daemons as special > sounds much more attractive. Ok, now define the difference between "system daemons" and any other daemon (or, for that matter, any other process). - mark Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
On Thu, Aug 12, 1999 at 12:02:19PM +0100, Tony Finch wrote: > Matthew Dillon <[EMAIL PROTECTED]> wrote: > > > >One solution would be to map clean R+W pages RO and force a write fault > >to occur, allowing the system to recognize that there are too many dirty > >pages in vm_fault before it is too late and flush some of them. The > >downside of this is that, of course, we take unnecessary faults. > > Surely they aren't unnecessary faults if they are required for correctness? They _are_ unnecessary faults, if other correct solutions exist. The second alternative - to mark system daemons as special sounds much more attractive. -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
Matthew Dillon wrote: > >One solution would be to map clean R+W pages RO and force a write fault >to occur, allowing the system to recognize that there are too many dirty >pages in vm_fault before it is too late and flush some of them. The >downside of this is that, of course, we take unnecessary faults. Surely they aren't unnecessary faults if they are required for correctness? Tony. -- f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
Matthew Dillon <[EMAIL PROTECTED]> wrote: > >One solution would be to map clean R+W pages RO and force a write fault >to occur, allowing the system to recognize that there are too many dirty >pages in vm_fault before it is too late and flush some of them. The >downside of this is that, of course, we take unnecessary faults. Surely they aren't unnecessary faults if they are required for correctness? Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
:If the latter mmap.c is allowed to fill up filesystem, -current hangs in : :/kernel: pid 2 (pagedaemon), uid 0 on /: file system full :/kernel: vnode_pager_putpages: I/O error 28 :/kernel: vnode_pager_putpages: residual I/O 16384 at 880 : :...repeating the last two lines, gradually increasing pindex, :residual changing to 64kB. : :Juha Ok, we have a fix for the mmap bug which should go in relatively soon. I reproduced the I/O error too. It does create an infinite loop... I'm not sure how to fix it yet. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
:If the latter mmap.c is allowed to fill up filesystem, -current hangs in : :/kernel: pid 2 (pagedaemon), uid 0 on /: file system full :/kernel: vnode_pager_putpages: I/O error 28 :/kernel: vnode_pager_putpages: residual I/O 16384 at 880 : :...repeating the last two lines, gradually increasing pindex, :residual changing to 64kB. : :Juha Ok, we have a fix for the mmap bug which should go in relatively soon. I reproduced the I/O error too. It does create an infinite loop... I'm not sure how to fix it yet. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
:If the latter mmap.c is allowed to fill up filesystem, -current hangs in : :/kernel: pid 2 (pagedaemon), uid 0 on /: file system full :/kernel: vnode_pager_putpages: I/O error 28 :/kernel: vnode_pager_putpages: residual I/O 16384 at 880 : :...repeating the last two lines, gradually increasing pindex, :residual changing to 64kB. : :Juha It should stop eventually when it runs out of pages in the map. This is what happens when you map a file, ftruncate() it to be a certain size (all zero-fill), and then touch the pages forcing the filesystem to allocate actual blocks for the data and the filesystem isn't big enough. The system doesn't know the filesystem isn't big enough until it actually tries to flush the pages. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
If the latter mmap.c is allowed to fill up filesystem, -current hangs in /kernel: pid 2 (pagedaemon), uid 0 on /: file system full /kernel: vnode_pager_putpages: I/O error 28 /kernel: vnode_pager_putpages: residual I/O 16384 at 880 ...repeating the last two lines, gradually increasing pindex, residual changing to 64kB. Juha To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
:> :>He's trying to ask if this is a problem with the code in question or 3.2R's :>mmap. : : That's better. It appears to be a classic resource related deadlock that :is caused by the VFS code needing pages in order to page things out (and thus :free up pages), but is unable to since no memory is available. : Matt Dillon was working on deadlocks like this in -current awhile back and :it would be interesting to know if the hang occurs there as well. I don't :have a -current machine at the moment so I can't test it myself. : :-DG : :David Greenman :Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org :Creator of high-performance Internet servers - http://www.terasolutions.com The problem can occur in both STABLE and CURRENT. I ran the test program on a CURRENT system artificially limited to 64MB of ram. It locked it up instantly. This is because we map clean R+W pages as R+W. Thus we do not take a fault when the process dirties a pages underlying a map, so we do not know that it has been dirtied until it is far too late. When we run out of pages, the system daemons lockup in the VFS subsystem when the filesystem tries to read or write metadata. One solution would be to map clean R+W pages RO and force a write fault to occur, allowing the system to recognize that there are too many dirty pages in vm_fault before it is too late and flush some of them. The downside of this is that, of course, we take unnecessary faults. Another solution might be to reorganize the emergency page reserve to operate based on a P_ flag in the process structure, so VFS routines that normally block when memory is low are allowed to proceed when called from system processes. I'll try persuing the second idea. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
:If the latter mmap.c is allowed to fill up filesystem, -current hangs in : :/kernel: pid 2 (pagedaemon), uid 0 on /: file system full :/kernel: vnode_pager_putpages: I/O error 28 :/kernel: vnode_pager_putpages: residual I/O 16384 at 880 : :...repeating the last two lines, gradually increasing pindex, :residual changing to 64kB. : :Juha It should stop eventually when it runs out of pages in the map. This is what happens when you map a file, ftruncate() it to be a certain size (all zero-fill), and then touch the pages forcing the filesystem to allocate actual blocks for the data and the filesystem isn't big enough. The system doesn't know the filesystem isn't big enough until it actually tries to flush the pages. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
If the latter mmap.c is allowed to fill up filesystem, -current hangs in /kernel: pid 2 (pagedaemon), uid 0 on /: file system full /kernel: vnode_pager_putpages: I/O error 28 /kernel: vnode_pager_putpages: residual I/O 16384 at 880 ...repeating the last two lines, gradually increasing pindex, residual changing to 64kB. Juha To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
:> :>He's trying to ask if this is a problem with the code in question or 3.2R's :>mmap. : : That's better. It appears to be a classic resource related deadlock that :is caused by the VFS code needing pages in order to page things out (and thus :free up pages), but is unable to since no memory is available. : Matt Dillon was working on deadlocks like this in -current awhile back and :it would be interesting to know if the hang occurs there as well. I don't :have a -current machine at the moment so I can't test it myself. : :-DG : :David Greenman :Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org :Creator of high-performance Internet servers - http://www.terasolutions.com The problem can occur in both STABLE and CURRENT. I ran the test program on a CURRENT system artificially limited to 64MB of ram. It locked it up instantly. This is because we map clean R+W pages as R+W. Thus we do not take a fault when the process dirties a pages underlying a map, so we do not know that it has been dirtied until it is far too late. When we run out of pages, the system daemons lockup in the VFS subsystem when the filesystem tries to read or write metadata. One solution would be to map clean R+W pages RO and force a write fault to occur, allowing the system to recognize that there are too many dirty pages in vm_fault before it is too late and flush some of them. The downside of this is that, of course, we take unnecessary faults. Another solution might be to reorganize the emergency page reserve to operate based on a P_ flag in the process structure, so VFS routines that normally block when memory is low are allowed to proceed when called from system processes. I'll try persuing the second idea. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
> >He's trying to ask if this is a problem with the code in question or 3.2R's > >mmap. > >That's better. It appears to be a classic resource related deadlock that > is caused by the VFS code needing pages in order to page things out (and thus > free up pages), but is unable to since no memory is available. >Matt Dillon was working on deadlocks like this in -current awhile back and > it would be interesting to know if the hang occurs there as well. I don't > have a -current machine at the moment so I can't test it myself. FreeBSD 4.0-CURRENT #14: Mon Aug 9 17:44:35 PDT 1999 It doesn't hang my machine here, I let it go to about 25. -- we are but packets in the internet of life To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
>Looks like Oleg made a mistake in posting the code. I saw an earlier version >of this in freebsd-questions and followed up with him. > >I've appended the version I think he meant to include. > >He's reporting this behavior with 3.2R. Runs fine with 'mmap -u', appears to >hang the machine on the second iteration (file "1") with 'mmap'. > >Runs fine on Solaris 2.6 and Digital Unix 4.0D -- with the exception of >filling the disk without "-u" :^). > >He's trying to ask if this is a problem with the code in question or 3.2R's >mmap. That's better. It appears to be a classic resource related deadlock that is caused by the VFS code needing pages in order to page things out (and thus free up pages), but is unable to since no memory is available. Matt Dillon was working on deadlocks like this in -current awhile back and it would be interesting to know if the hang occurs there as well. I don't have a -current machine at the moment so I can't test it myself. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: mmap bug
Looks like Oleg made a mistake in posting the code. I saw an earlier version
of this in freebsd-questions and followed up with him.
I've appended the version I think he meant to include.
He's reporting this behavior with 3.2R. Runs fine with 'mmap -u', appears to
hang the machine on the second iteration (file "1") with 'mmap'.
Runs fine on Solaris 2.6 and Digital Unix 4.0D -- with the exception of
filling the disk without "-u" :^).
He's trying to ask if this is a problem with the code in question or 3.2R's
mmap.
Charles
--- mmap.c ---
#include
#include
#include
#include
#include
#include
#include
main(int argc, char *argv[])
{
int fd;
int i;
int len=1024*1024*10; /*ie 10Mbytes*/
caddr_t addr;
char ttt[80];
int bunlink = 0;
if ( argc > 1 && strcmp(argv[1], "-u") == 0 ) {
bunlink = 1;
}
printf("unlink files? %s\n", bunlink ? "YES" : "NO");
for (i=0;;i++)
{
sprintf (ttt,"%d",i);
printf("mmaping %ld byte region on file %s\n", len, ttt);
fd=open(ttt,O_CREAT|O_RDWR,0666);
if (fd<0)
{
printf("open error %ld\n",errno);
exit(1);
}
lseek(fd,len-1,SEEK_SET);
write(fd,"",1);
addr=mmap(0,len,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);
if (addr==MAP_FAILED)
{
printf("mmap error %ld",errno);
exit(1);
}
memset(addr,'x',len);
if ( munmap(addr, len) != 0 ) {
fprintf(stderr, "munmap failed\n");
exit(EXIT_FAILURE);
}
close(fd);
if ( bunlink ) unlink(ttt);
}
}
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
> >He's trying to ask if this is a problem with the code in question or 3.2R's > >mmap. > >That's better. It appears to be a classic resource related deadlock that > is caused by the VFS code needing pages in order to page things out (and thus > free up pages), but is unable to since no memory is available. >Matt Dillon was working on deadlocks like this in -current awhile back and > it would be interesting to know if the hang occurs there as well. I don't > have a -current machine at the moment so I can't test it myself. FreeBSD 4.0-CURRENT #14: Mon Aug 9 17:44:35 PDT 1999 It doesn't hang my machine here, I let it go to about 25. -- we are but packets in the internet of life To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
This report seems to be severely lacking in details. First, I don't
understand why it is called "mmap" since it doesn't do an mmap and the
"addr" that is being frobbed with isn't even initialized. Second, I
get a core dump when I run it on a -stable machine:
[speedy:tmp9] mmap
unlink files? NO
mmaping 10485760 byte region on file 0
Segmentation fault (core dumped)
...which is exactly what I'd expect when dealing with a bogus pointer.
You didn't specify what version of FreeBSD you saw a hang and didn't provide
any details of the hang. Please provide more information so that we can
help you. Thanks.
-DG
David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com
>This small program, running as 'mmap', not 'mmap -u', can hang my machine.
>Is this a known bug in FreeBSD's kernel, or it is my fantasy ?
>Thank you for answer.
>
>#include
>#include
>#include
>#include
>#include
>#include
>#include
>
>main(int argc, char *argv[])
>{
> int fd;
> int i;
> int len=1024*1024*10; /*ie 10Mbytes*/
> caddr_t addr;
> char ttt[80];
> int bunlink = 0;
>
> if ( argc > 1 && strcmp(argv[1], "-u") == 0 ) {
> bunlink = 1;
> }
> printf("unlink files? %s\n", bunlink ? "YES" : "NO");
>
> for (i=0;;i++)
> {
> sprintf (ttt,"%d",i);
> printf("mmaping %ld byte region on file %s\n", len, ttt);
> fd=open(ttt,O_CREAT|O_RDWR,0666);
> if (fd<0)
> {
>printf("mmap error %ld",errno);
>exit(1);
> }
> memset(addr,'x',len);
> if ( munmap(addr, len) != 0 ) {
> fprintf(stderr, "munmap failed\n");
> exit(EXIT_FAILURE);
> }
> close(fd);
> if ( bunlink ) unlink(ttt);
> }
>}
>
>
>To Unsubscribe: send mail to majord...@freebsd.org
>with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
Um, just where do you call mmap(2) in this code?
- ad
Oleg Derevenetz wrote:
> This small program, running as 'mmap', not 'mmap -u', can hang my machine.
> Is this a known bug in FreeBSD's kernel, or it is my fantasy ?
> Thank you for answer.
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> main(int argc, char *argv[])
> {
> int fd;
> int i;
> int len=1024*1024*10; /*ie 10Mbytes*/
> caddr_t addr;
> char ttt[80];
> int bunlink = 0;
>
> if ( argc > 1 && strcmp(argv[1], "-u") == 0 ) {
>bunlink = 1;
> }
> printf("unlink files? %s\n", bunlink ? "YES" : "NO");
>
> for (i=0;;i++)
> {
> sprintf (ttt,"%d",i);
> printf("mmaping %ld byte region on file %s\n", len, ttt);
> fd=open(ttt,O_CREAT|O_RDWR,0666);
> if (fd<0)
> {
> printf("mmap error %ld",errno);
> exit(1);
> }
> memset(addr,'x',len);
> if ( munmap(addr, len) != 0 ) {
>fprintf(stderr, "munmap failed\n");
>exit(EXIT_FAILURE);
> }
> close(fd);
> if ( bunlink ) unlink(ttt);
> }
> }
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
>Looks like Oleg made a mistake in posting the code. I saw an earlier version >of this in freebsd-questions and followed up with him. > >I've appended the version I think he meant to include. > >He's reporting this behavior with 3.2R. Runs fine with 'mmap -u', appears to >hang the machine on the second iteration (file "1") with 'mmap'. > >Runs fine on Solaris 2.6 and Digital Unix 4.0D -- with the exception of >filling the disk without "-u" :^). > >He's trying to ask if this is a problem with the code in question or 3.2R's >mmap. That's better. It appears to be a classic resource related deadlock that is caused by the VFS code needing pages in order to page things out (and thus free up pages), but is unable to since no memory is available. Matt Dillon was working on deadlocks like this in -current awhile back and it would be interesting to know if the hang occurs there as well. I don't have a -current machine at the moment so I can't test it myself. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
Are you running this as root? <- - - . . Bosko Milekic http://www.dsuper.net/~bmilekic/ Network Operations - Delphi SuperNet, an Internet Direct company +1.514.281.7500 (vox) / +1.514.281.6599 (fax) / http://www.dsuper.net/ . . - - -> On Wed, 11 Aug 1999, Oleg Derevenetz wrote: !> !>This small program, running as 'mmap', not 'mmap -u', can hang my machine. !>Is this a known bug in FreeBSD's kernel, or it is my fantasy ? !>Thank you for answer. !> [ code snipped ] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
On Wed, 11 Aug 1999 20:48:08 +0400 (MSD)
Oleg Derevenetz wrote:
> This small program, running as 'mmap', not 'mmap -u', can hang my machine.
> Is this a known bug in FreeBSD's kernel, or it is my fantasy ?
> Thank you for answer.
If it hangs your system, must be a bug in FreeBSD. Here is what happens
on a NetBSD/alpha system:
bishop:thorpej 26$ ./mmap-bug
unlink files? NO
mmaping 10485760 byte region on file 0
Memory fault (core dumped)
bishop:thorpej 27$ ./mmap-bug -u
unlink files? YES
mmaping 10485760 byte region on file 0
Memory fault (core dumped)
bishop:thorpej 28$
...which is correct. There isn't any backing store for the region
you've mapped.
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> main(int argc, char *argv[])
> {
> int fd;
> int i;
> int len=1024*1024*10; /*ie 10Mbytes*/
> caddr_t addr;
> char ttt[80];
> int bunlink = 0;
>
> if ( argc > 1 && strcmp(argv[1], "-u") == 0 ) {
>bunlink = 1;
> }
> printf("unlink files? %s\n", bunlink ? "YES" : "NO");
>
> for (i=0;;i++)
> {
> sprintf (ttt,"%d",i);
> printf("mmaping %ld byte region on file %s\n", len, ttt);
> fd=open(ttt,O_CREAT|O_RDWR,0666);
> if (fd<0)
> {
> printf("mmap error %ld",errno);
> exit(1);
> }
> memset(addr,'x',len);
> if ( munmap(addr, len) != 0 ) {
>fprintf(stderr, "munmap failed\n");
>exit(EXIT_FAILURE);
> }
> close(fd);
> if ( bunlink ) unlink(ttt);
> }
> }
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
-- Jason R. Thorpe
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
RE: mmap bug
Looks like Oleg made a mistake in posting the code. I saw an earlier version
of this in freebsd-questions and followed up with him.
I've appended the version I think he meant to include.
He's reporting this behavior with 3.2R. Runs fine with 'mmap -u', appears to
hang the machine on the second iteration (file "1") with 'mmap'.
Runs fine on Solaris 2.6 and Digital Unix 4.0D -- with the exception of
filling the disk without "-u" :^).
He's trying to ask if this is a problem with the code in question or 3.2R's
mmap.
Charles
--- mmap.c ---
#include
#include
#include
#include
#include
#include
#include
main(int argc, char *argv[])
{
int fd;
int i;
int len=1024*1024*10; /*ie 10Mbytes*/
caddr_t addr;
char ttt[80];
int bunlink = 0;
if ( argc > 1 && strcmp(argv[1], "-u") == 0 ) {
bunlink = 1;
}
printf("unlink files? %s\n", bunlink ? "YES" : "NO");
for (i=0;;i++)
{
sprintf (ttt,"%d",i);
printf("mmaping %ld byte region on file %s\n", len, ttt);
fd=open(ttt,O_CREAT|O_RDWR,0666);
if (fd<0)
{
printf("open error %ld\n",errno);
exit(1);
}
lseek(fd,len-1,SEEK_SET);
write(fd,"",1);
addr=mmap(0,len,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);
if (addr==MAP_FAILED)
{
printf("mmap error %ld",errno);
exit(1);
}
memset(addr,'x',len);
if ( munmap(addr, len) != 0 ) {
fprintf(stderr, "munmap failed\n");
exit(EXIT_FAILURE);
}
close(fd);
if ( bunlink ) unlink(ttt);
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
This report seems to be severely lacking in details. First, I don't
understand why it is called "mmap" since it doesn't do an mmap and the
"addr" that is being frobbed with isn't even initialized. Second, I
get a core dump when I run it on a -stable machine:
[speedy:tmp9] mmap
unlink files? NO
mmaping 10485760 byte region on file 0
Segmentation fault (core dumped)
...which is exactly what I'd expect when dealing with a bogus pointer.
You didn't specify what version of FreeBSD you saw a hang and didn't provide
any details of the hang. Please provide more information so that we can
help you. Thanks.
-DG
David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com
>This small program, running as 'mmap', not 'mmap -u', can hang my machine.
>Is this a known bug in FreeBSD's kernel, or it is my fantasy ?
>Thank you for answer.
>
>#include
>#include
>#include
>#include
>#include
>#include
>#include
>
>main(int argc, char *argv[])
>{
> int fd;
> int i;
> int len=1024*1024*10; /*ie 10Mbytes*/
> caddr_t addr;
> char ttt[80];
> int bunlink = 0;
>
> if ( argc > 1 && strcmp(argv[1], "-u") == 0 ) {
> bunlink = 1;
> }
> printf("unlink files? %s\n", bunlink ? "YES" : "NO");
>
> for (i=0;;i++)
> {
> sprintf (ttt,"%d",i);
> printf("mmaping %ld byte region on file %s\n", len, ttt);
> fd=open(ttt,O_CREAT|O_RDWR,0666);
> if (fd<0)
> {
>printf("mmap error %ld",errno);
>exit(1);
> }
> memset(addr,'x',len);
> if ( munmap(addr, len) != 0 ) {
> fprintf(stderr, "munmap failed\n");
> exit(EXIT_FAILURE);
> }
> close(fd);
> if ( bunlink ) unlink(ttt);
> }
>}
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
Um, just where do you call mmap(2) in this code?
- ad
Oleg Derevenetz wrote:
> This small program, running as 'mmap', not 'mmap -u', can hang my machine.
> Is this a known bug in FreeBSD's kernel, or it is my fantasy ?
> Thank you for answer.
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> main(int argc, char *argv[])
> {
> int fd;
> int i;
> int len=1024*1024*10; /*ie 10Mbytes*/
> caddr_t addr;
> char ttt[80];
> int bunlink = 0;
>
> if ( argc > 1 && strcmp(argv[1], "-u") == 0 ) {
>bunlink = 1;
> }
> printf("unlink files? %s\n", bunlink ? "YES" : "NO");
>
> for (i=0;;i++)
> {
> sprintf (ttt,"%d",i);
> printf("mmaping %ld byte region on file %s\n", len, ttt);
> fd=open(ttt,O_CREAT|O_RDWR,0666);
> if (fd<0)
> {
> printf("mmap error %ld",errno);
> exit(1);
> }
> memset(addr,'x',len);
> if ( munmap(addr, len) != 0 ) {
>fprintf(stderr, "munmap failed\n");
>exit(EXIT_FAILURE);
> }
> close(fd);
> if ( bunlink ) unlink(ttt);
> }
> }
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
Are you running this as root? <- - - . . Bosko Milekic <[EMAIL PROTECTED]> http://www.dsuper.net/~bmilekic/ Network Operations - Delphi SuperNet, an Internet Direct company +1.514.281.7500 (vox) / +1.514.281.6599 (fax) / http://www.dsuper.net/ . . - - -> On Wed, 11 Aug 1999, Oleg Derevenetz wrote: !> !>This small program, running as 'mmap', not 'mmap -u', can hang my machine. !>Is this a known bug in FreeBSD's kernel, or it is my fantasy ? !>Thank you for answer. !> [ code snipped ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap bug
On Wed, 11 Aug 1999 20:48:08 +0400 (MSD)
Oleg Derevenetz <[EMAIL PROTECTED]> wrote:
> This small program, running as 'mmap', not 'mmap -u', can hang my machine.
> Is this a known bug in FreeBSD's kernel, or it is my fantasy ?
> Thank you for answer.
If it hangs your system, must be a bug in FreeBSD. Here is what happens
on a NetBSD/alpha system:
bishop:thorpej 26$ ./mmap-bug
unlink files? NO
mmaping 10485760 byte region on file 0
Memory fault (core dumped)
bishop:thorpej 27$ ./mmap-bug -u
unlink files? YES
mmaping 10485760 byte region on file 0
Memory fault (core dumped)
bishop:thorpej 28$
...which is correct. There isn't any backing store for the region
you've mapped.
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> main(int argc, char *argv[])
> {
> int fd;
> int i;
> int len=1024*1024*10; /*ie 10Mbytes*/
> caddr_t addr;
> char ttt[80];
> int bunlink = 0;
>
> if ( argc > 1 && strcmp(argv[1], "-u") == 0 ) {
>bunlink = 1;
> }
> printf("unlink files? %s\n", bunlink ? "YES" : "NO");
>
> for (i=0;;i++)
> {
> sprintf (ttt,"%d",i);
> printf("mmaping %ld byte region on file %s\n", len, ttt);
> fd=open(ttt,O_CREAT|O_RDWR,0666);
> if (fd<0)
> {
> printf("mmap error %ld",errno);
> exit(1);
> }
> memset(addr,'x',len);
> if ( munmap(addr, len) != 0 ) {
>fprintf(stderr, "munmap failed\n");
>exit(EXIT_FAILURE);
> }
> close(fd);
> if ( bunlink ) unlink(ttt);
> }
> }
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
-- Jason R. Thorpe <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
