From edwin@mavetju.org  Mon Jun 14 05:11:21 2004
Return-Path: <edwin@mavetju.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id AA53616A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 14 Jun 2004 05:11:21 +0000 (GMT)
Received: from mailout2.barnet.com.au (mailout2.barnet.com.au [218.185.88.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP id EAA2843D2F
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 14 Jun 2004 05:11:20 +0000 (GMT)
	(envelope-from edwin@mavetju.org)
Received: by mailout2.barnet.com.au (Postfix, from userid 27)
	id DC405AA61E0; Mon, 14 Jun 2004 15:11:19 +1000 (EST)
Received: from mail2-auth.barnet.com.au (localhost [127.0.0.1])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "*.barnet.com.au", Issuer "BarNet Root Certificate Authority" (verified OK))
	by mail2.barnet.com.au (Postfix) with ESMTP id 84C24B29D0D
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 14 Jun 2004 15:11:19 +1000 (EST)
Received: from k7.mavetju (unknown [10.10.12.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "edwin.adsl.barnet.com.au", Issuer "BarNet Root Certificate Authority" (verified OK))
	by mail2-auth.barnet.com.au (Postfix) with ESMTP id 995DD193D1
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 14 Jun 2004 15:11:18 +1000 (EST)
Received: by k7.mavetju (Postfix, from userid 1001)
	id 0A9CA60EB; Mon, 14 Jun 2004 15:11:14 +1000 (EST)
Message-Id: <20040614051114.0A9CA60EB@k7.mavetju>
Date: Mon, 14 Jun 2004 15:11:14 +1000 (EST)
From: Edwin Groothuis <edwin@mavetju.org>
Reply-To: Edwin Groothuis <edwin@mavetju.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: imagemagicks convert image to movie conversion kills 5.2.1 machine in vnode_pager_putpages
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         67919
>Category:       kern
>Synopsis:       imagemagicks convert image to movie conversion kills 5.2.1 machine in vnode_pager_putpages
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jun 14 05:20:01 GMT 2004
>Closed-Date:    Thu Jun 09 21:21:24 UTC 2011
>Last-Modified:  Thu Jun 09 21:21:24 UTC 2011
>Originator:     Edwin Groothuis
>Release:        FreeBSD 5.2.1-RELEASE i386
>Organization:
-
>Environment:
    System: FreeBSD k7.mavetju 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #3: Fri Feb 27 13:54:29 EST 2004 edwin@k7.mavetju:/usr/src/sys/i386/compile/k7 i386

    768Mb of memory, 1.5Gb of swap

>Description:

    I have about 5000 PNG images I try to convert into an MPG movie.
    ImageMagicks convert can do this. I can convert 100 images, 200
    images but somewhere between 201 and 300 images it totally
    crashes my FreeBSD box with an endless stream of messages:
	"vnode_pager_putpages: I/O error ..."
	"vnode_pager_putpages: residual I/O ..."

>How-To-Repeat:

    Install graphics/ImageMagick.
    Create about 300 PNG files (mine are
    movie00001.png: PNG image data, 586 x 533, 2-bit colormap, non-interlaced)
    Run "convert -verbose movie*.png blaat.mpg"

    Somewhere between image 200 and 300 you get a message about
    /var being full and lots of the vnode_pager_putpages messages
    scrolling over the kernel.

>Fix:

    Euhm... I'm willing to try every patch being send to me.
>Release-Note:
>Audit-Trail:

From: Edwin Groothuis <edwin@mavetju.org>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/67919: imagemagicks convert image to movie conversion kills 5.2.1 machine in vnode_pager_putpages
Date: Mon, 14 Jun 2004 16:00:35 +1000

 I would like to point to this email on the -stable list:
 	http://lists.freebsd.org/pipermail/freebsd-stable/2004-March/006493.html
 
 From irc:
 
 <tjr> well, i have a vague idea
 <tjr> perhaps the application has mmap()'d in a sparse file
 <tjr> dirtied so many pages that there isn't space on disk for them
 <tjr> then the syncer has gone to flush the dirty pages out to disk..
 <tjr> you could confirm whether or not that's the case fairly easily
 <tjr> create a sparse file that would be too big to fit on disk if it was non-sparse, mmap it in, dirty all the pages
 
 -- 
 Edwin Groothuis      |            Personal website: http://www.mavetju.org
 edwin@mavetju.org    |          Weblog: http://weblog.barnet.com.au/edwin/

From: Parv <parv@pair.com>
To: Edwin Groothuis <edwin@mavetju.org>
Cc: FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: kern/67919: imagemagicks convert image to movie conversion kills 5.2.1 machine in vnode_pager_putpages
Date: Mon, 14 Jun 2004 03:04:55 -0400

 in message <20040614051114.0A9CA60EB@k7.mavetju>,
 wrote Edwin Groothuis thusly...
 >
 > 
 > >Number:         67919
 > >Category:       kern
 > >Synopsis:       imagemagicks convert image to movie conversion
 > >kills 5.2.1 machine in vnode_pager_putpages
 > 
 > I have about 5000 PNG images I try to convert into an MPG movie.
 > ImageMagicks convert can do this. I can convert 100 images, 200
 > images but somewhere between 201 and 300 images it totally crashes
 ...
 
 Nice to see, not that i take delight in this, that somebody also has
 problem when convert is faced w/ a large number of files.
 
 I had problem w/ convert long time ago on a [34].x (non-CURRENT)
 branch while either creating an index and/or thumbnails of JPEG/GIF
 images.  The machine locked up & had to do hard power down when did
 2-3 times.  Since then i have given up on using convert on more than
 a few images.
 
 
   - Parv
 
 -- 
 

From: Edwin Groothuis <edwin@mavetju.org>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/67919: imagemagicks convert image to movie conversion kills 5.2.1 machine in vnode_pager_putpages
Date: Mon, 14 Jun 2004 17:34:19 +1000

 I've attached a sample program with which the behaviour can be
 simulated. It works against my 256Mb /tmp partition. I have had
 different experiences with it.
 
 1. start program, wait a couple of seconds, see these messages:
    Jun 14 16:49:39 k7 kernel: vnode_pager_putpages: I/O error 28
    Jun 14 16:49:39 k7 kernel: vnode_pager_putpages: residual I/O 65536 at 124934
    Jun 14 16:49:39 k7 kernel: pid 781 (mtest), uid 1001 inumber 6 on /tmp: filesystem full
 
 Two things can happen now:
 
 2a. ^C the program, program itself becomes unkillable (state is
    something like bwrite in top), but machine responds (although
    very lagging) until it doesn't do anything further. The messages
    above keep coming in a regular interval (once every second or so)
 
 2b. kill -9 the program, program terminates after some seconds.
     Machine keeps working for two-three seconds and an endless
     stream of vnode_pager_putpages messsages overflow the console.
 
 Some googling for the vnode_pager_putpages showed me this thread too:
     http://archives.neohapsis.com/archives/freebsd/2000-05/0345.html
 which sounds exactly like what is happening here.
 
 #include <sys/mman.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <fcntl.h>
 #include <unistd.h>
 
 #define FNAME "/tmp/blaat"
 #define SIZE 500000*1024
 
 int main(int argc,char **argv) {
     FILE *f;
     char *a=malloc(SIZE);
     int fd;
     int i;
 
     printf("Start\n");
 
     if ((f=fopen(FNAME,"w"))==NULL) { perror("fopen"); return 1; }
     if (fseek(f,SIZE,SEEK_SET)!=0) { perror("fseek"); return 1; }
     if (fwrite("a",1,1,f)!=1) { perror("fwrite"); return 1; }
     if (fseek(f,0,SEEK_SET)!=0) { perror("fseek"); return 1; }
     if (fclose(f)!=0) { perror("fclose"); return 1; }
 
     if ((fd=open(FNAME,O_RDWR))==NULL) { perror("open"); return 1; }
     if ((a=mmap(NULL,SIZE,PROT_WRITE|PROT_READ,MAP_SHARED,fd,0))==MAP_FAILED) {
 	perror("mmap"); return 1; }
 
     for (i=0;i<SIZE/1024;i++) { a[1024*i]=65; }
 
     if (msync(a,0,MS_SYNC)!=0) { perror("msync"); return 1; }
     if (munmap(a,SIZE)!=0) { perror("munmap"); return 1; }
     if (close(fd)!=0) { perror("close"); return 1; }
 
     printf("Stop\n");
     return 0;
 }

From: Edwin Groothuis <edwin@mavetju.org>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/67919: imagemagicks convert image to movie conversion kills 5.2.1 machine in vnode_pager_putpages
Date: Mon, 14 Jun 2004 17:52:08 +1000

 For what it is worth, convert works fine if you set TMPDIR to
 something on /usr instead of on /var/tmp. But still, it shouldn't
 kill half the system if you don't :-)
 
 -- 
 Edwin Groothuis      |            Personal website: http://www.mavetju.org
 edwin@mavetju.org    |          Weblog: http://weblog.barnet.com.au/edwin/

From: Igor Sysoev <is@rambler-co.ru>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/67919
Date: Fri, 12 Nov 2004 18:26:54 +0300 (MSK)

   This message is in MIME format.  The first part should be readable text,
   while the remaining parts are likely unreadable without MIME-aware tools.
   Send mail to mime@docserver.cac.washington.edu for more info.
 
 --0-805100342-1100273214=:41088
 Content-Type: TEXT/PLAIN; charset=US-ASCII
 
 The attached patch by Uwe Doering, see
 http://docs.freebsd.org/cgi/getmsg.cgi?fetch=653596+0+current/freebsd-stable
 had resolved the same problem on FreeBSD 4.10-RELEASE.
 
 
 Igor Sysoev
 http://sysoev.ru/en/
 --0-805100342-1100273214=:41088
 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="vnode_pager.c.diff"
 Content-Transfer-Encoding: BASE64
 Content-ID: <20041112182654.F41088@is.park.rambler.ru>
 Content-Description: 
 Content-Disposition: attachment; filename="vnode_pager.c.diff"
 
 LS0tIHNyYy9zeXMvdm0vdm5vZGVfcGFnZXIuYy5vcmlnCVR1ZSBEZWMgMzEg
 MTA6MzQ6NTEgMjAwMg0KKysrIHNyYy9zeXMvdm0vdm5vZGVfcGFnZXIuYwlG
 cmkgTm92ICA1IDIwOjQxOjE1IDIwMDQNCkBAIC05NTQsNyArOTU0LDkgQEAN
 CiAJc3RydWN0IHVpbyBhdWlvOw0KIAlzdHJ1Y3QgaW92ZWMgYWlvdjsNCiAJ
 aW50IGVycm9yOw0KKwlpbnQgc3RhdHVzOw0KIAlpbnQgaW9mbGFnczsNCisJ
 c3RhdGljIGludCBsYXN0X2Vsb2csIGxhc3RfcmxvZzsNCiANCiAJb2JqZWN0
 ID0gdnAtPnZfb2JqZWN0Ow0KIAljb3VudCA9IGJ5dGVjb3VudCAvIFBBR0Vf
 U0laRTsNCkBAIC0xMDM1LDE1ICsxMDM3LDE4IEBADQogCWNudC52X3Zub2Rl
 b3V0Kys7DQogCWNudC52X3Zub2RlcGdzb3V0ICs9IG5jb3VudDsNCiANCi0J
 aWYgKGVycm9yKSB7DQorCWlmIChlcnJvciAmJiBsYXN0X2Vsb2cgIT0gdGlt
 ZV9zZWNvbmQpIHsNCisJCWxhc3RfZWxvZyA9IHRpbWVfc2Vjb25kOw0KIAkJ
 cHJpbnRmKCJ2bm9kZV9wYWdlcl9wdXRwYWdlczogSS9PIGVycm9yICVkXG4i
 LCBlcnJvcik7DQogCX0NCi0JaWYgKGF1aW8udWlvX3Jlc2lkKSB7DQorCWlm
 IChhdWlvLnVpb19yZXNpZCAmJiBsYXN0X3Jsb2cgIT0gdGltZV9zZWNvbmQp
 IHsNCisJCWxhc3RfcmxvZyA9IHRpbWVfc2Vjb25kOw0KIAkJcHJpbnRmKCJ2
 bm9kZV9wYWdlcl9wdXRwYWdlczogcmVzaWR1YWwgSS9PICVkIGF0ICVsdVxu
 IiwNCiAJCSAgICBhdWlvLnVpb19yZXNpZCwgKHVfbG9uZyltWzBdLT5waW5k
 ZXgpOw0KIAl9DQorCXN0YXR1cyA9IGVycm9yID8gVk1fUEFHRVJfQkFEIDog
 Vk1fUEFHRVJfT0s7DQogCWZvciAoaSA9IDA7IGkgPCBuY291bnQ7IGkrKykg
 ew0KLQkJcnR2YWxzW2ldID0gVk1fUEFHRVJfT0s7DQorCQlydHZhbHNbaV0g
 PSBzdGF0dXM7DQogCX0NCiAJcmV0dXJuIHJ0dmFsc1swXTsNCiB9DQo=
 
 --0-805100342-1100273214=:41088--

From: "Cai, Quanqing" <caiquanqing@gmail.com>
To: freebsd-current@freebsd.org, bug-followup@FreeBSD.org
Cc: Igor Sysoev <is@rambler-co.ru>, Edwin Groothuis <edwin@mavetju.org>, 
	Uwe Doering <gemini@geminix.org>
Subject: Re: kern/67919: Why nobody take serious to fix this bug?
Date: Sun, 30 Oct 2005 21:28:22 -0800

 ------=_Part_29858_5728121.1130736502398
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: inline
 
 Today I happened to read this message on freebsd-stable:
 http://lists.freebsd.org/pipermail/freebsd-stable/2005-October/019086.html
 
 After I read all messages and related links, I feel so frustrating, why
 nobody take serious to fix this bug even we have a patch for it? I can
 repeat this bug on 7.0-CURRENT and 6.0-RC1 easily as a normal user! System
 goes no response so I have to power cycle it. The patch made by Uwe Doering
 actually works well. This bug looks like a security hole to me:( If you guy=
 s
 don't like this patch, please give out a reason and come out a better patch
 or solution.
 
 For impatience, you can run this to crush your system(7.x, 6.x, 5.x), you
 have to increase FILELEN to a size greater than your /tmp partition:
 
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 #include <stdio.h>
 #include <fcntl.h>
 #include <unistd.h>
 #include <err.h>
 #include <sys/types.h>
 #include <sys/mman.h>
 
 #define FILENAME "/tmp/test" /* where to put the test file */
 #define FILELEN 710 /* test file length in MB */
 
 main()
 {
 int fd;
 size_t len;
 char *buf, *p, *lim;
 
 len =3D FILELEN * 1024 * 1024;
 
 if ((fd =3D open(FILENAME, O_RDWR|O_CREAT|O_TRUNC, 0666)) =3D=3D -1)
 err(2, "open() failed");
 
 if (ftruncate(fd, len) =3D=3D -1)
 err(2, "ftruncate() failed");
 
 buf =3D mmap(NULL, len, PROT_WRITE, MAP_SHARED, fd, 0);
 if (buf =3D=3D MAP_FAILED)
 err(2, "mmap() failed");
 (void)close(fd);
 
 for (p =3D buf, lim =3D p + len; p < lim; p +=3D 4096)
 *p =3D '0';
 
 if (munmap(buf, len) =3D=3D -1)
 err(2, "munmap() failed");
 
 exit(0);
 }
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
 
 Cai, Quanqing
 
 ------=_Part_29858_5728121.1130736502398
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: inline
 
 Today I happened to read this message on freebsd-stable:
 <a href=3D"http://lists.freebsd.org/pipermail/freebsd-stable/2005-October/0=
 19086.html">http://lists.freebsd.org/pipermail/freebsd-stable/2005-October/=
 019086.html</a><br>
 <br>
 After I read all messages and related links, I feel so frustrating, why
 nobody take serious to fix this bug even we have a patch for it? I can
 repeat this bug on 7.0-CURRENT and 6.0-RC1 easily as a normal user!
 System goes no response so I have to power cycle it. The patch made by
 Uwe Doering actually works well. This bug looks like a security hole to
 me:( If you guys don't like this patch, please give out a reason and
 come out a better patch or solution.<br>
 <br>
 For impatience, you can run this to crush your system(7.x, 6.x, 5.x),
 you have to increase FILELEN to a size greater than your /tmp partition:<br=
 >
 <br>
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
 #include &lt;stdio.h&gt;<br>
 #include &lt;fcntl.h&gt;<br>
 #include &lt;unistd.h&gt;<br>
 #include &lt;err.h&gt;<br>
 #include &lt;sys/types.h&gt;<br>
 #include &lt;sys/mman.h&gt;<br>
 <br>
 #define FILENAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;/tmp/test&=
 quot;&nbsp;&nbsp;&nbsp;&nbsp; /* where to put the test file */<br>
 #define FILELEN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 710&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 /* test file length in MB */<br>
 <br>
 main()<br>
 {<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int fd;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; size_t len;<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; char *buf, *p, *lim;<br>
 <br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; len =3D FILELEN * 1024 * 1024;<b=
 r>
 <br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if ((fd =3D open(FILENAME, O_RDW=
 R|O_CREAT|O_TRUNC, 0666)) =3D=3D -1)<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
 sp;&nbsp;&nbsp; err(2, &quot;open() failed&quot;);<br>
 <br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (ftruncate(fd, len) =3D=3D -1=
 )<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
 sp;&nbsp;&nbsp; err(2, &quot;ftruncate() failed&quot;);<br>
 <br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; buf =3D mmap(NULL, len, PROT_WRI=
 TE, MAP_SHARED, fd, 0);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (buf =3D=3D MAP_FAILED)<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
 sp;&nbsp;&nbsp; err(2, &quot;mmap() failed&quot;);<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (void)close(fd);<br>
 <br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for (p =3D buf, lim =3D p + len;=
  p &lt; lim; p +=3D 4096)<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
 sp;&nbsp;&nbsp; *p =3D '0';<br>
 <br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (munmap(buf, len) =3D=3D -1)<=
 br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
 sp;&nbsp;&nbsp; err(2, &quot;munmap() failed&quot;);<br>
 <br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exit(0);<br>
 }<br>
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
 <br>
 <br>
 Cai, Quanqing<br>
 
 ------=_Part_29858_5728121.1130736502398--

From: Maxim Konovalov <maxim@macomnet.ru>
To: "Cai, Quanqing" <caiquanqing@gmail.com>
Cc: freebsd-current@freebsd.org, bug-followup@freebsd.org,
        Edwin Groothuis <edwin@mavetju.org>, Igor Sysoev <is@rambler-co.ru>,
        Uwe Doering <gemini@geminix.org>
Subject: Re: kern/67919: Why nobody take serious to fix this bug?
Date: Mon, 31 Oct 2005 14:42:03 +0300 (MSK)

 On Sun, 30 Oct 2005, 21:28-0800, Cai, Quanqing wrote:
 
 > Today I happened to read this message on freebsd-stable:
 > http://lists.freebsd.org/pipermail/freebsd-stable/2005-October/019086.html
 >
 > After I read all messages and related links, I feel so frustrating,
 > why nobody take serious to fix this bug even we have a patch for it?
 > I can repeat this bug on 7.0-CURRENT and 6.0-RC1 easily as a normal
 > user! System goes no response so I have to power cycle it. The patch
 > made by Uwe Doering actually works well. This bug looks like a
 > security hole to me:( If you guys don't like this patch, please give
 > out a reason and come out a better patch or solution.
 
 I was told the patch is incorrect.  It works in certain cases but
 incorrect in general.
 
 -- 
 Maxim Konovalov

From: Igor Sysoev <is@rambler-co.ru>
To: Maxim Konovalov <maxim@macomnet.ru>
Cc: "Cai, Quanqing" <caiquanqing@gmail.com>, freebsd-current@freebsd.org,
        bug-followup@freebsd.org, Edwin Groothuis <edwin@mavetju.org>,
        Uwe Doering <gemini@geminix.org>
Subject: Re: kern/67919: Why nobody take serious to fix this bug?
Date: Mon, 31 Oct 2005 16:26:56 +0300 (MSK)

 On Mon, 31 Oct 2005, Maxim Konovalov wrote:
 
 > On Sun, 30 Oct 2005, 21:28-0800, Cai, Quanqing wrote:
 >
 >> Today I happened to read this message on freebsd-stable:
 >> http://lists.freebsd.org/pipermail/freebsd-stable/2005-October/019086.html
 >>
 >> After I read all messages and related links, I feel so frustrating,
 >> why nobody take serious to fix this bug even we have a patch for it?
 >> I can repeat this bug on 7.0-CURRENT and 6.0-RC1 easily as a normal
 >> user! System goes no response so I have to power cycle it. The patch
 >> made by Uwe Doering actually works well. This bug looks like a
 >> security hole to me:( If you guys don't like this patch, please give
 >> out a reason and come out a better patch or solution.
 >
 > I was told the patch is incorrect.  It works in certain cases but
 > incorrect in general.
 
 Why is it incorrect ? I'm using it for year.
 
 
 Igor Sysoev
 http://sysoev.ru/en/

From: Maxim Konovalov <maxim@macomnet.ru>
To: Igor Sysoev <is@rambler-co.ru>
Cc: "Cai, Quanqing" <caiquanqing@gmail.com>, freebsd-current@freebsd.org,
        bug-followup@freebsd.org, Edwin Groothuis <edwin@mavetju.org>,
        Uwe Doering <gemini@geminix.org>
Subject: Re: kern/67919: Why nobody take serious to fix this bug?
Date: Mon, 31 Oct 2005 17:18:18 +0300 (MSK)

 [...]
 > > I was told the patch is incorrect.  It works in certain cases but
 > > incorrect in general.
 >
 > Why is it incorrect ? I'm using it for year.
 
 Because you can't just throw away any chunk of data (e.g. it could be
 a meta-data) without a risk to damage a filesystem.
 
 -- 
 Maxim Konovalov

From: Uwe Doering <gemini@geminix.org>
To: Maxim Konovalov <maxim@macomnet.ru>
Cc: Igor Sysoev <is@rambler-co.ru>, 
 "Cai, Quanqing" <caiquanqing@gmail.com>,
  freebsd-current@freebsd.org,  bug-followup@freebsd.org, 
 Edwin Groothuis <edwin@mavetju.org>
Subject: Re: kern/67919: Why nobody take serious to fix this bug?
Date: Mon, 31 Oct 2005 16:08:30 +0100

 Maxim Konovalov wrote:
 > [...]
 > 
 >>>I was told the patch is incorrect.  It works in certain cases but
 >>>incorrect in general.
 >>
 >>Why is it incorrect ? I'm using it for year.
 > 
 > Because you can't just throw away any chunk of data (e.g. it could be
 > a meta-data) without a risk to damage a filesystem.
 
 I wonder, could it really be meta-data?  I was under the impression that 
 meta-data is a filesystem property and is therefore dealt with in the 
 filesystem code, through i/o buffers.  Isn't the VM pager responsible 
 for handling object contents (files etc.), only?  If so, it would be 
 unfortunate to throw away pages of data but it certainly wouldn't damage 
 the filesystem.
 
 As to our own experience: Since I provided the patch a year ago or so 
 we've had tons of users bumping against the space limit of their 
 respective disk containers (with the VM pager involved: Berkeley DB 3, 
 for instance) but not a single instance where the filesystem had been 
 damaged by this incident.  This is on the 4.x branch.
 
     Uwe
 -- 
 Uwe Doering         |  EscapeBox - Managed On-Demand UNIX Servers
 gemini@geminix.org  |  http://www.escapebox.net

From: Maxim Konovalov <maxim@macomnet.ru>
To: Uwe Doering <gemini@geminix.org>
Cc: Igor Sysoev <is@rambler-co.ru>, "Cai, Quanqing" <caiquanqing@gmail.com>,
        freebsd-current@freebsd.org, bug-followup@freebsd.org,
        Edwin Groothuis <edwin@mavetju.org>
Subject: Re: kern/67919: Why nobody take serious to fix this bug?
Date: Wed, 2 Nov 2005 13:34:31 +0300 (MSK)

 On Mon, 31 Oct 2005, 16:08+0100, Uwe Doering wrote:
 
 > Maxim Konovalov wrote:
 > > [...]
 > >
 > > > >I was told the patch is incorrect.  It works in certain cases but
 > > > >incorrect in general.
 > > >
 > > >Why is it incorrect ? I'm using it for year.
 > >
 > > Because you can't just throw away any chunk of data (e.g. it could be
 > > a meta-data) without a risk to damage a filesystem.
 >
 > I wonder, could it really be meta-data?  I was under the impression
 > that meta-data is a filesystem property and is therefore dealt with
 > in the filesystem code, through i/o buffers.  Isn't the VM pager
 > responsible for handling object contents (files etc.), only?  If so,
 > it would be unfortunate to throw away pages of data but it certainly
 > wouldn't damage the filesystem.
 
 I'm under different (perhaps incorrect) impression.
 
 For the record: ps@ just committed to HEAD a rate limit part of your
 patch with a slightly different implementation.
 
 -- 
 Maxim Konovalov

From: Niclas Zeising <niclas.zeising@gmail.com>
To: bug-followup@FreeBSD.org, edwin@mavetju.org
Cc:  
Subject: Re: kern/67919: imagemagicks convert image to movie conversion kills
 5.2.1 machine in vnode_pager_putpages
Date: Thu, 09 Jun 2011 14:48:28 +0200

 What's the status of this PR? It was sent a long time ago, and FreeBSD
 5.2.1 is not supported anymore. ImageMagick has also been updated to
 newer versions several times.
 Can this PR be closed?
 Regards!
 -- 
 Niclas Zeising
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Thu Jun 9 21:20:33 UTC 2011 
State-Changed-Why:  
By now this PR is many years stale.  Sorry that it never got looked at. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=67919 
>Unformatted:
