From yar@rt2.chem.msu.ru  Tue Oct 11 14:33:51 2005
Return-Path: <yar@rt2.chem.msu.ru>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 650D816A42F;
	Tue, 11 Oct 2005 14:33:51 +0000 (GMT)
	(envelope-from yar@rt2.chem.msu.ru)
Received: from rt2.chem.msu.ru (rt2-tower.chem.msu.ru [195.208.208.6])
	by mx1.FreeBSD.org (Postfix) with ESMTP id C24AE43D48;
	Tue, 11 Oct 2005 14:33:50 +0000 (GMT)
	(envelope-from yar@rt2.chem.msu.ru)
Received: from rt2.chem.msu.ru (localhost.chem.msu.ru [127.0.0.1])
	by rt2.chem.msu.ru (8.13.3/8.13.3) with ESMTP id j9BEXmGF083053;
	Tue, 11 Oct 2005 18:33:48 +0400 (MSD)
	(envelope-from yar@rt2.chem.msu.ru)
Received: (from yar@localhost)
	by rt2.chem.msu.ru (8.13.3/8.13.3/Submit) id j9BEXlLJ083052;
	Tue, 11 Oct 2005 18:33:47 +0400 (MSD)
	(envelope-from yar)
Message-Id: <200510111433.j9BEXlLJ083052@rt2.chem.msu.ru>
Date: Tue, 11 Oct 2005 18:33:47 +0400 (MSD)
From: Yar Tikhiy <yar@comp.chem.msu.su>
To: FreeBSD-gnats-submit@freebsd.org
Cc: phk@freebsd.org
Subject: Large malloc-backed mfs crashes the system
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         87255
>Category:       kern
>Synopsis:       [md] [panic] large malloc-backed mfs crashes the system
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    yar
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Oct 11 14:40:16 GMT 2005
>Closed-Date:    Fri Feb 15 11:41:02 UTC 2008
>Last-Modified:  Tue Feb  8 21:00:19 UTC 2011
>Originator:     Yar Tikhiy
>Release:        FreeBSD-CURRENT
>Organization:
MSU
>Environment:
	FreeBSD-CURRENT as of October, 7.

>Description:
	Filling up a too large malloc-backed mfs disk results
	in a well-reproducible system panic.  While it is bogus
	to give nearly all RAM to a malloc-backed mfs disk, the
	system ideally shouldn't panic either, but return a error
	at some earlier point.

	This issue was initially mentioned in PR bin/87218.

>How-To-Repeat:
	On a machine with 256M of RAM:

	# mdmfs -s 200M -S -M /dev/md0 /mnt
	# cat /dev/urandom > /mnt/foo
	[system croaks and panics in a few seconds]

	Pre-panic and panic messages:

	g_vfs_done():md0[WRITE(offset=124108800, length=131072)]error = 28
	g_vfs_done():md0[WRITE(offset=52543488, length=6144)]error = 28
	[quite a bunch of such g_vfs_done() error messages precedes panic]
	panic: bundirty: buffer 0xc63c78b0 still on queue 1

	Kernel backtrace:

#11 0xc04dae87 in panic (
    fmt=0xc06578d1 "bundirty: buffer %p still on queue %d")
    at /usr/src/sys/kern/kern_shutdown.c:539
#12 0xc051f52d in bundirty (bp=0xc63c78b0) at /usr/src/sys/kern/vfs_bio.c:1036
#13 0xc051fe60 in brelse (bp=0xc63c78b0) at /usr/src/sys/kern/vfs_bio.c:1346
#14 0xc0522ca6 in bufdone (bp=0xc63c78b0) at /usr/src/sys/kern/vfs_bio.c:3183
#15 0xc05d7346 in ffs_backgroundwritedone (bp=0xc63c78b0)
    at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1537
#16 0xc05229ba in bufdone (bp=0xc63c78b0) at /usr/src/sys/kern/vfs_bio.c:3051
#17 0xc04a9aa6 in g_vfs_done (bip=0x0) at /usr/src/sys/geom/geom_vfs.c:86
#18 0xc0522694 in biodone (bp=0xc1281294) at /usr/src/sys/kern/vfs_bio.c:2894
#19 0xc04a741f in g_io_schedule_up (tp=0xc1108300)
    at /usr/src/sys/geom/geom_io.c:510
#20 0xc04a76f6 in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:95
#21 0xc04c7d74 in fork_exit (callout=0xc04a769c <g_up_procbody>, arg=0x0,
    frame=0xcbdcbd38) at /usr/src/sys/kern/kern_fork.c:789
#22 0xc061e8bc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208

>Fix:
>Release-Note:
>Audit-Trail:

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: FreeBSD-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/87255: Large malloc-backed mfs crashes the system
Date: Tue, 11 Oct 2005 18:44:36 +0400

 Just for the record:
 
 The problem seems to involve vfs-md interaction
 as filling just a bogusly large malloc-backed md
 device results in harmless ENOSPC at some point.
 
 -- 
 Yar

From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To: Yar Tikhiy <yar@comp.chem.msu.su>
Cc: freebsd-bugs@freebsd.org
Subject: Re: kern/87255: Large malloc-backed mfs crashes the system 
Date: Tue, 11 Oct 2005 16:55:09 +0200

 In message <200510111450.j9BEoLEB006718@freefall.freebsd.org>, Yar Tikhiy write
 s:
 >The following reply was made to PR kern/87255; it has been noted by GNATS.
 >
 >From: Yar Tikhiy <yar@comp.chem.msu.su>
 >To: FreeBSD-gnats-submit@FreeBSD.org
 >Cc:  
 >Subject: Re: kern/87255: Large malloc-backed mfs crashes the system
 >Date: Tue, 11 Oct 2005 18:44:36 +0400
 >
 > Just for the record:
 > 
 > The problem seems to involve vfs-md interaction
 > as filling just a bogusly large malloc-backed md
 > device results in harmless ENOSPC at some point.
 
 ENOSPC may be a problem for filesystems, try changing it to EIO and
 see if they cope better with that.
 
 In all cases it is a "don't do that then" class of problem.
 
 -- 
 Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
 phk@FreeBSD.ORG         | TCP/IP since RFC 956
 FreeBSD committer       | BSD since 4.3-tahoe    
 Never attribute to malice what can adequately be explained by incompetence.

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: freebsd-bugs@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: kern/87255: Large malloc-backed mfs crashes the system
Date: Wed, 26 Oct 2005 13:07:37 +0400

 On Tue, Oct 11, 2005 at 04:55:09PM +0200, Poul-Henning Kamp wrote:
 > In message <200510111450.j9BEoLEB006718@freefall.freebsd.org>, Yar Tikhiy write
 > > Just for the record:
 > > 
 > > The problem seems to involve vfs-md interaction
 > > as filling just a bogusly large malloc-backed md
 > > device results in harmless ENOSPC at some point.
 > 
 > ENOSPC may be a problem for filesystems, try changing it to EIO and
 > see if they cope better with that.
 
 Tried to, replaced all ENOSPC codes with EIO in sys/dev/md/md.c,
 but alas, the problem still is there with exactly the same symptoms.
 
 > In all cases it is a "don't do that then" class of problem.
 
 Yes, of course.  The question is whether we consider it normal
 for root to have ability to panic the system using standard tools.
 "cat /dev/zero > /dev/mem" still is the ultimate way to.  IMHO it
 is a key issue whether we fall back at the academical/research stage
 where rough corners are OK and the system is just a toy for eggheads,
 or we pretend our system is stable and robust.  I doubt if an admin
 can crash the Windows NT kernel from the userland using conventional
 interfaces.  I by no means expect this issue to be resolved soon, but
 it's worth being reflected on at tea-time :-)
 
 Apropos, here's another reproducible crash induced by md:
 
 	# mdconfig -a -t malloc -s 300m
 	md0
 	# dd if=/dev/urandom of=/dev/md0 bs=1
 	dd: /dev/md0: Input/output error
 	79+0 records in
 	78+9 records out
 	# reboot
 	panic: kmem_malloc(4096): kmem_map too small: 86224896 total allocated
 
 Apparently, it is not a fault of md, just our kernel memory
 allocator allows other kernel parts to starve it to death.
 
 -- 
 Yar

From: Robert Watson <rwatson@FreeBSD.org>
To: Yar Tikhiy <yar@comp.chem.msu.su>
Cc: freebsd-bugs@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: kern/87255: Large malloc-backed mfs crashes the system
Date: Wed, 5 Jul 2006 12:16:11 +0100 (BST)

 On Wed, 26 Oct 2005, Yar Tikhiy wrote:
 
 > > In all cases it is a "don't do that then" class of problem.
 >
 > Yes, of course.  The question is whether we consider it normal for root to 
 > have ability to panic the system using standard tools. "cat /dev/zero > 
 > /dev/mem" still is the ultimate way to.  IMHO it is a key issue whether we 
 > fall back at the academical/research stage where rough corners are OK and 
 > the system is just a toy for eggheads, or we pretend our system is stable 
 > and robust.  I doubt if an admin can crash the Windows NT kernel from the 
 > userland using conventional interfaces.  I by no means expect this issue to 
 > be resolved soon, but it's worth being reflected on at tea-time :-)
 >
 > Apropos, here's another reproducible crash induced by md:
 >
 > 	# mdconfig -a -t malloc -s 300m
 > 	md0
 > 	# dd if=/dev/urandom of=/dev/md0 bs=1
 > 	dd: /dev/md0: Input/output error
 > 	79+0 records in
 > 	78+9 records out
 > 	# reboot
 > 	panic: kmem_malloc(4096): kmem_map too small: 86224896 total allocated
 >
 > Apparently, it is not a fault of md, just our kernel memory allocator allows 
 > other kernel parts to starve it to death.
 
 I'm not sure I entirely go along with this interpretation.  The answer to the 
 question "What do do when the kernel runs out of address space?" is not easily 
 found.  The "problem" is that md performs potentially unbounded allocation of 
 a quite bounded resource -- remember that resource deadlocks are very real, 
 sometimes it takes memory to release memory (abstractly, think of memory 
 allocation as locking).  UMA supports allocator-enforced resource limits, 
 which can be requested by the consumer using uma_zone_set_max().  md(4) should 
 probably be using that interface and requesting a resource limit.
 
 There is also a problem then regarding what happens when md(4) runs out of 
 resources to allocate when it has already "promised" that it's a disk of a 
 certain size up the stack.  I.e., if the result isn't a panic, then how will 
 md(4) handle failure?  Most file systems will not be happy when they get EIO, 
 so then perhaps the problem is that md(4) provides an abstraction for a 
 non-sparse device up the storage stack, but is in fact over-committing.  This 
 suggests either that the size of an md device should be strictly bounded if it 
 is malloc-backed.  Picking that maximum bound is also tricky.  This is why, in 
 practice, we recommend using swap-backed md devices, so that the pages 
 associated with the md device can be swapped out under memory pressure, and 
 that the swap system have enough memory to fully back the md device.
 
 Robert N M Watson
 Computer Laboratory
 University of Cambridge

From: "Dominique Goncalves" <dominique.goncalves@gmail.com>
To: bug-followup@FreeBSD.org, yar@comp.chem.msu.su
Cc:  
Subject: Re: kern/87255: [md] [panic] large malloc-backed mfs crashes the system
Date: Thu, 20 Jul 2006 14:28:52 +0200

 Hi,
 
 On a recent FreeBSD 7.0-CURRENT #11: Tue Jul 18 11:12:05 CEST 2006, I
 can also reproduce this panic. It's a bit annoying because I use
 FreeBSD with freesbie2 on USB keys.
 
 What's the status of this issue ?
 
 Let me know if you need more information.
 
 Regards.
 
 g_vfs_done():md5[WRITE(offset=51625984, length=131072)]error = 28
 [...]
 g_vfs_done():md5[WRITE(offset=118456320, length=6144)]error = 28
 panic: bundirty: buffer 0xcbe94148 still on queue 1
 cpuid = 0
 KDB: enter: panic
 [thread pid 3 tid 100001 ]
 Stopped at      kdb_enter+0x2b: nop
 db> trace
 Tracing pid 3 tid 100001 td 0xc237fd80
 kdb_enter(c0955759) at kdb_enter+0x2b
 panic(c095e295,cbe94148,1,cbe94148,d26a1c54,...) at panic+0x127
 bundirty(cbe94148) at bundirty+0x35
 brelse(cbe94148) at brelse+0x823
 bufdone_finish(cbe94148) at bufdone_finish+0x32a
 bufdone(cbe94148) at bufdone+0xaa
 ffs_vget(cbe94148) at ffs_vget+0x9ae
 bufdone(cbe94148) at bufdone+0x8f
 g_getattr__(c279f8c4) at g_getattr__+0xca
 biodone(c279f8c4) at biodone+0x58
 g_io_schedule_up(c237fd80) at g_io_schedule_up+0xe6
 g_print_bio(0,d26a1d38) at g_print_bio+0xfa
 fork_exit(c068f38c,0,d26a1d38) at fork_exit+0xa4
 fork_trampoline() at fork_trampoline+0x8
 --- trap 0x1, eip = 0, esp = 0xd26a1d6c, ebp = 0 ---
 db>
 
 -- 
 There's this old saying: "Give a man a fish, feed him for a day. Teach
 a man to fish, feed him for life."

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: Robert Watson <rwatson@FreeBSD.org>
Cc: freebsd-bugs@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: kern/87255: Large malloc-backed mfs crashes the system
Date: Thu, 20 Jul 2006 18:52:34 +0400

 On Wed, Jul 05, 2006 at 12:16:11PM +0100, Robert Watson wrote:
 > On Wed, 26 Oct 2005, Yar Tikhiy wrote:
 > 
 > >> In all cases it is a "don't do that then" class of problem.
 > >
 > >Yes, of course.  The question is whether we consider it normal for root to 
 > >have ability to panic the system using standard tools. "cat /dev/zero > 
 > >/dev/mem" still is the ultimate way to.  IMHO it is a key issue whether we 
 > >fall back at the academical/research stage where rough corners are OK and 
 > >the system is just a toy for eggheads, or we pretend our system is stable 
 > >and robust.  I doubt if an admin can crash the Windows NT kernel from the 
 > >userland using conventional interfaces.  I by no means expect this issue 
 > >to be resolved soon, but it's worth being reflected on at tea-time :-)
 > >
 > >Apropos, here's another reproducible crash induced by md:
 > >
 > >	# mdconfig -a -t malloc -s 300m
 > >	md0
 > >	# dd if=/dev/urandom of=/dev/md0 bs=1
 > >	dd: /dev/md0: Input/output error
 > >	79+0 records in
 > >	78+9 records out
 > >	# reboot
 > >	panic: kmem_malloc(4096): kmem_map too small: 86224896 total 
 > >	allocated
 > >
 > >Apparently, it is not a fault of md, just our kernel memory allocator 
 > >allows other kernel parts to starve it to death.
 > 
 > I'm not sure I entirely go along with this interpretation.  The answer to 
 > the question "What do do when the kernel runs out of address space?" is not 
 > easily found.  The "problem" is that md performs potentially unbounded 
 > allocation of a quite bounded resource -- remember that resource deadlocks 
 > are very real, sometimes it takes memory to release memory (abstractly, 
 > think of memory allocation as locking).  UMA supports allocator-enforced 
 > resource limits, which can be requested by the consumer using 
 > uma_zone_set_max().  md(4) should probably be using that interface and 
 > requesting a resource limit.
 
 The panic doesn't seem to be on a critical path in the kernel; it's
 in kmem_malloc(), which is essentially a utility routine.  Could
 the allocation attempt just fail for the caller to decide what to
 do then?  In fact, it can fail, but only in case of M_NOWAIT:
 
         if (vm_map_findspace(map, vm_map_min(map), size, &addr)) {
                 vm_map_unlock(map);
                 if ((flags & M_NOWAIT) == 0)
                         panic("kmem_malloc(%ld): kmem_map too small: %ld total allocated",
                                 (long)size, (long)map->size);
                 return (0);
         }
 
 Looks like we have to panic there merely because malloc(9) is
 promised to succeed if waiting is OK, but there's no chance for
 success.  Isn't it a design issue?
 
 > There is also a problem then regarding what happens when md(4) runs out of 
 > resources to allocate when it has already "promised" that it's a disk of a 
 > certain size up the stack.  I.e., if the result isn't a panic, then how 
 > will md(4) handle failure?  Most file systems will not be happy when they 
 > get EIO, so then perhaps the problem is that md(4) provides an abstraction 
 > for a non-sparse device up the storage stack, but is in fact 
 > over-committing.  This suggests either that the size of an md device should 
 > be strictly bounded if it is malloc-backed.  Picking that maximum bound is 
 > also tricky.  This is why, in practice, we recommend using swap-backed md 
 > devices, so that the pages associated with the md device can be swapped out 
 > under memory pressure, and that the swap system have enough memory to fully 
 > back the md device.
 
 Perhaps md(4) shouldn't over-commit in malloc mode?  It will waste
 precious physical memory, but malloc mode is supposed to.  And one
 can't use swap-backed md when diskless.
 
 -- 
 Yar

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: Dominique Goncalves <dominique.goncalves@gmail.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/87255: [md] [panic] large malloc-backed mfs crashes the system
Date: Thu, 20 Jul 2006 18:53:41 +0400

 On Thu, Jul 20, 2006 at 02:28:52PM +0200, Dominique Goncalves wrote:
 > Hi,
 > 
 > On a recent FreeBSD 7.0-CURRENT #11: Tue Jul 18 11:12:05 CEST 2006, I
 > can also reproduce this panic. It's a bit annoying because I use
 > FreeBSD with freesbie2 on USB keys.
 > 
 > What's the status of this issue ?
 
 I don't think there was any progress in this issue.  It isn't a
 mere bug, it's connected tightly to the way the FreeBSD kernel
 handles memory.
 
 -- 
 Yar

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/87255: commit references a PR
Date: Tue,  6 Mar 2007 13:14:00 +0000 (UTC)

 yar         2007-03-06 13:13:54 UTC
 
   FreeBSD src repository
 
   Modified files:
     etc/defaults         rc.conf 
     share/man/man5       rc.conf.5 
   Log:
   As suggested more than once in the lists, drop -M from flags to mfs
   for /tmp and /var.  This makes the memory discs swap-backed instead
   of malloc-backed.  A swap-backed memory disc should not be worse
   than a malloc-backed one in any scenario because it will start
   touching swap only when needed.  OTOH, a malloc-backed disc can
   starve limited kernel resources and evenually crash the system.
   
   Reflect the change in the rc.conf(5) manpage.  Also stop telling
   lies there about softupdates: it does not waste disc space, it
   just can delay its freeing.
   
   Suggested by:   many
   PR:             kern/87255
   MFC after:      1 week
   
   Revision  Changes    Path
   1.306     +2 -2      src/etc/defaults/rc.conf
   1.317     +7 -9      src/share/man/man5/rc.conf.5
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 

From: Gergely CZUCZY <phoemix@harmless.hu>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/87255: [md] ]panic] largemalloc backed mfs crashes the system
Date: Fri, 23 Mar 2007 15:12:22 +0100

 --PEIAKu/WMn1b1Hv9
 Content-Type: text/plain; charset=utf-8
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 Hello
 
 I've just hit this issue on a 6.2-STABLE, and it's been verified on freenod=
 e/##freebsd on
 an other 6.2-STABLE.
 FreeBSD  6.2-STABLE FreeBSD 6.2-STABLE #0: Tue Feb 27 12:04:37 CET 2007    =
  toor@mort:/usr/obj/usr/src/sys/FREESBIE  i386
 FreeBSD sys0 6.2-STABLE FreeBSD 6.2-STABLE #1: Web Mar 21 23:39:54 CET 2007
 
 how did i triggered it:
 # mdconfig -a -t malloc -s 1g
 mdX
 # newfs /dev/mdX
 # mount /dev/mdX /mnt/
 # cd /usr/ && tar -czf /mnt/src.tar src
 # cd /mnt && tar -xvf src.tar
 
 the box has 2G of ram in it, i allocated half of that into mfs for
 some proposes. so, if i leave enough memory for the system, it still
 crashed.
 
 it crashed the system and rebooted it shortly.
 
 Bye,
 
 Gergely Czuczy
 mailto: gergely.czuczy@harmless.hu
 
 --=20
 Weenies test. Geniuses solve problems that arise.
 
 --PEIAKu/WMn1b1Hv9
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.5 (FreeBSD)
 
 owGFU71rFEEUTwymGBBMYf8kkBRmP++SiytBTbyLgoJ4hxEsZG737e7o7sw5M3vm
 0guCH0QbBUFbQUULW7GwtxIEq1T+DZa+vSRHOrcZ3u/93r6v39s9MTN1bO7H5y+3
 zzx58Xr648y3/pmyslZmTsn1UEgn8P3AaYZBs+k0nSBuLDeDlSRYTZdbfMXvzOx1
 NpS0KK3TGw0wAovb1hsUXMhzEOdcG7RrlU2dVXbIuyTMQBlhhZIRCFkIiRNfT3Np
 UtROW8YqETKL4H6lLCbOQAtpeb9Axi5jUSjGriwOEe5WxkIuLNhcGBDGVAhKAocV
 N3S6vYvrV9tLwGUCwi4a6CNKGKIWqcCk5qWaEJWsMfTm52ujb2qccQnK5qiP/MZl
 HfKvdy/BERAOsSPQvB9Bj8roYB/CFgRh5DejRgs22j0Ifb8F9K0xsErpC6XSNvIq
 oz3Vvzt+jY49MzJe50a73V2/0gYQjdWVSW5y+f/LH0SwRbmvcQ1hAGEjapyNlpuT
 /Izl6gEkgmYCVossQ431fCI2D2USK5mKDBwOjoWS06RjcAwEGSuTW8SQ+CA14CU4
 9PaBUlXSTgDwSmk9guMExv3AwgJYqsSJd9J9J3Xo1gi9BzxCJ7TtYQoHDMZoBdBX
 25BzA+EmqBQ0L0kzVO0SVT+ujpM6iFCktdvm3JLfKiipylRpZlSJMNCKJIfGBaMo
 MKXYAjnJh5ZfZTmUSIsY1XyoU9KQLZZEtGCsKAoWa25yTFzGCDowjjDHAtPYV7VS
 x1E57bUYEX99hEuMbaLOsBjBxk4V74xYyUVhVQTZPuzGY/gCXUtZoDFuXjHmOGuh
 z7ZIngINXZWxLmySUVEb1EUxHHdF91Ca/a65FgZd9uj8zPGp+iwPb3ru2MPZqbfd
 vV93Pvm/p19tntxd/Pjz5qn3G8HUm9a7Z8//nLz3d/nr6acvH0/Pfr/+IfkH
 =u6Dv
 -----END PGP SIGNATURE-----
 
 --PEIAKu/WMn1b1Hv9--

From: Kris Kennaway <kris@obsecurity.org>
To: Gergely CZUCZY <phoemix@harmless.hu>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/87255: [md] ]panic] largemalloc backed mfs crashes the system
Date: Fri, 23 Mar 2007 15:20:15 -0400

 On Fri, Mar 23, 2007 at 02:50:07PM +0000, Gergely CZUCZY wrote:
 > The following reply was made to PR kern/87255; it has been noted by GNATS.
 > 
 > From: Gergely CZUCZY <phoemix@harmless.hu>
 > To: bug-followup@FreeBSD.org
 > Cc:  
 > Subject: Re: kern/87255: [md] ]panic] largemalloc backed mfs crashes the system
 > Date: Fri, 23 Mar 2007 15:12:22 +0100
 > 
 >  --PEIAKu/WMn1b1Hv9
 >  Content-Type: text/plain; charset=utf-8
 >  Content-Disposition: inline
 >  Content-Transfer-Encoding: quoted-printable
 >  
 >  Hello
 >  
 >  I've just hit this issue on a 6.2-STABLE, and it's been verified on freenod=
 >  e/##freebsd on
 >  an other 6.2-STABLE.
 >  FreeBSD  6.2-STABLE FreeBSD 6.2-STABLE #0: Tue Feb 27 12:04:37 CET 2007    =
 >   toor@mort:/usr/obj/usr/src/sys/FREESBIE  i386
 >  FreeBSD sys0 6.2-STABLE FreeBSD 6.2-STABLE #1: Web Mar 21 23:39:54 CET 2007
 >  
 >  how did i triggered it:
 >  # mdconfig -a -t malloc -s 1g
 >  mdX
 >  # newfs /dev/mdX
 >  # mount /dev/mdX /mnt/
 >  # cd /usr/ && tar -czf /mnt/src.tar src
 >  # cd /mnt && tar -xvf src.tar
 >  
 >  the box has 2G of ram in it, i allocated half of that into mfs for
 >  some proposes. so, if i leave enough memory for the system, it still
 >  crashed.
 >  
 >  it crashed the system and rebooted it shortly.
 
 Right, this is a documented limitation of malloc backing.  Use swap
 backing instead, it's just better.
 
 Kris
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Fri Mar 23 20:33:38 UTC 2007 
State-Changed-Why:  
Perhaps the documentation could be better, but as kris said, the system 
is working as designed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=87255 

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: Mark Linimon <linimon@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/87255: [md] [panic] large malloc-backed mfs crashes the system
Date: Sat, 24 Mar 2007 12:14:08 +0300

 On Fri, Mar 23, 2007 at 08:34:26PM +0000, Mark Linimon wrote:
 > Synopsis: [md] [panic] large malloc-backed mfs crashes the system
 > 
 > State-Changed-From-To: open->closed
 > State-Changed-By: linimon
 > State-Changed-When: Fri Mar 23 20:33:38 UTC 2007
 > State-Changed-Why: 
 > Perhaps the documentation could be better, but as kris said, the system
 > is working as designed.
 
 I don't care about this PR, but see
 http://lists.freebsd.org/pipermail/freebsd-stable/2007-March/033475.html
 through
 http://lists.freebsd.org/pipermail/freebsd-stable/2007-March/033480.html
 if you believe this behaviour of the system is well-intended.
 
 -- 
 Yar
State-Changed-From-To: closed->open 
State-Changed-By: linimon 
State-Changed-When: Sun Mar 25 17:41:47 UTC 2007 
State-Changed-Why:  
Reopened at submitter's request. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=87255 
State-Changed-From-To: open->closed 
State-Changed-By: yar 
State-Changed-When: Fri Feb 15 11:39:20 UTC 2008 
State-Changed-Why:  
I no longer can reproduce this bug.  Moreover, AFAIK a fix was 
committed for the `kmem too small' issue. 


Responsible-Changed-From-To: freebsd-bugs->yar 
Responsible-Changed-By: yar 
Responsible-Changed-When: Fri Feb 15 11:39:20 UTC 2008 
Responsible-Changed-Why:  
Closing my own PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=87255 

From: Anton Lazarov <anton.lazarov@gmail.com>
To: bug-followup@FreeBSD.org, yar@comp.chem.msu.su
Cc:  
Subject: Re: kern/87255: [md] [panic] large malloc-backed mfs crashes the system
Date: Tue, 8 Feb 2011 22:32:41 +0200

 What a footshot! This was just reproduced by accident on a 4G (RAM)
 FreeBSD 8.2-RC3 system (while testing memory) using:
 
 # mdmfs -M -S -o async -s 1024m md1 /mnt/tmp
 # dd if=/dev/random of=/mnt/tmp/testfile bs=1M count=900
 
 Classic "follow the manpage behavior" by jump hard at gardening tools.
 
 Can this be prevented by tuning system parameters, or at least give a
 firm warning in the manpage?
 
 Seems quite idiotic (to run with scissors down stairs) but yet again
 some of us would like to know upfront rather than get that unpleasant
 result by experiment.
 
 Anton L.
>Unformatted:
