From nobody  Sun Dec 21 07:39:19 1997
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA08388;
          Sun, 21 Dec 1997 07:39:19 -0800 (PST)
          (envelope-from nobody)
Message-Id: <199712211539.HAA08388@hub.freebsd.org>
Date: Sun, 21 Dec 1997 07:39:19 -0800 (PST)
From: cschuber@uumail.gov.bc.ca
To: freebsd-gnats-submit@freebsd.org
Subject: Fix for NULLFS problems
X-Send-Pr-Version: www-1.0

>Number:         5355
>Category:       kern
>Synopsis:       Fix for NULLFS problems
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    bp
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sun Dec 21 07:40:01 PST 1997
>Closed-Date:    Mon Jun 25 21:26:39 PDT 2001
>Last-Modified:  Mon Jun 25 21:28:56 PDT 2001
>Originator:     Cy Schubert
>Release:        2.2.2R (Will work on other releases too)
>Organization:
ITSD, Province of British Columbia
>Environment:
FreeBSD cwsys 2.2.2-RELEASE FreeBSD 2.2.2-RELEASE #0: Fri Dec 19 07:02:49 PST 1997     root@cwsys:/opt/usr_src/sys/compile/CWSYS  i386

>Description:

Xref: kern/5212, bin/4491, bin/5154

>How-To-Repeat:
See above listed problems.
>Fix:
cwsys# cat /opt/archives-3/usermods/nullfs_panic_fix.usermod 
--- src/sys/vm/vnode_pager.c.orig2      Sun Dec  7 13:11:03 1997
+++ src/sys/vm/vnode_pager.c    Fri Dec 19 06:30:27 1997
@@ -231,10 +231,12 @@
        blocksperpage = 0;
        if (pagesperblock > 0) {
                reqblock = pindex / pagesperblock;
-       } else {
+       } else if (bsize > 0)  {
                blocksperpage = (PAGE_SIZE / bsize);
                reqblock = pindex * blocksperpage;
-       }
+       } else
+               return FALSE;
+
        err = VOP_BMAP(vp, reqblock, (struct vnode **) 0, &bn,
                after, before);
        if (err)
cwsys# exit

>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: cschuber@uumail.gov.bc.ca, freebsd-gnats-submit@FreeBSD.ORG
Cc:  Subject: Re: kern/5355: Fix for NULLFS problems
Date: Mon, 22 Dec 1997 04:41:45 +1100

 >>Fix:
 >cwsys# cat /opt/archives-3/usermods/nullfs_panic_fix.usermod 
 >--- src/sys/vm/vnode_pager.c.orig2      Sun Dec  7 13:11:03 1997
 >+++ src/sys/vm/vnode_pager.c    Fri Dec 19 06:30:27 1997
 >@@ -231,10 +231,12 @@
 >        blocksperpage = 0;
 >        if (pagesperblock > 0) {
 >                reqblock = pindex / pagesperblock;
 >-       } else {
 >+       } else if (bsize > 0)  {
 >                blocksperpage = (PAGE_SIZE / bsize);
 >                reqblock = pindex * blocksperpage;
 >-       }
 >+       } else
 >+               return FALSE;
 >+
 
 I think bsize is supposed to be > 0 here.  Lots of other places depend
 on vp->v_mount->mnt_stat.f_iosize being reasonable.  nullfs and some
 other file systems (portal and umapfs at least) just don't initialize
 most of mnt_stat (except by bzeroing it).  This untested fix for nullfs
 was obtained from union[fs].
 
 diff -c2 null_vfsops.c~ null_vfsops.c
 *** null_vfsops.c~	Mon Oct 13 21:46:00 1997
 --- null_vfsops.c	Mon Dec 22 04:32:11 1997
 ***************
 *** 199,202 ****
 --- 199,203 ----
   	    &size);
   	bzero(mp->mnt_stat.f_mntfromname + size, MNAMELEN - size);
 + 	(void)nullfs_statfs(mp, &mp->mnt_stat, p);
   #ifdef NULLFS_DIAGNOSTIC
   	printf("nullfs_mount: lower %s, alias at %s\n",
 
 Bruce

From: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca>
To: Bruce Evans <bde@zeta.org.au>
Cc: cschuber@uumail.gov.bc.ca, freebsd-gnats-submit@freebsd.org,
        cy@passer.osg.gov.bc.ca
Subject: Re: kern/5355: Fix for NULLFS problems 
Date: Mon, 22 Dec 1997 10:35:40 -0800

 I'll give your code a try.
 
 Would it be a good idea to to have a panic() or a printf() where I return a 
 FALSE?  I'm torn between providing better diagnostic messages and reducing 
 kernel bloat.  By doing a printf() or panic() any author of a filesystem would 
 know that he would need to do some work on his code.
 
 
 Regards,                       Phone:  (250)387-8437
 Cy Schubert                      Fax:  (250)387-5766
 UNIX Support                   OV/VM:  BCSC02(CSCHUBER)
 ITSD                          BITNET:  CSCHUBER@BCSC02.BITNET
 Government of BC            Internet:  cschuber@uumail.gov.bc.ca
                                        Cy.Schubert@gems8.gov.bc.ca
 
 		"Quit spooling around, JES do it."
 
 > >>Fix:
 > >cwsys# cat /opt/archives-3/usermods/nullfs_panic_fix.usermod 
 > >--- src/sys/vm/vnode_pager.c.orig2      Sun Dec  7 13:11:03 1997
 > >+++ src/sys/vm/vnode_pager.c    Fri Dec 19 06:30:27 1997
 > >@@ -231,10 +231,12 @@
 > >        blocksperpage = 0;
 > >        if (pagesperblock > 0) {
 > >                reqblock = pindex / pagesperblock;
 > >-       } else {
 > >+       } else if (bsize > 0)  {
 > >                blocksperpage = (PAGE_SIZE / bsize);
 > >                reqblock = pindex * blocksperpage;
 > >-       }
 > >+       } else
 > >+               return FALSE;
 > >+
 > 
 > I think bsize is supposed to be > 0 here.  Lots of other places depend
 > on vp->v_mount->mnt_stat.f_iosize being reasonable.  nullfs and some
 > other file systems (portal and umapfs at least) just don't initialize
 > most of mnt_stat (except by bzeroing it).  This untested fix for nullfs
 > was obtained from union[fs].
 > 
 > diff -c2 null_vfsops.c~ null_vfsops.c
 > *** null_vfsops.c~	Mon Oct 13 21:46:00 1997
 > --- null_vfsops.c	Mon Dec 22 04:32:11 1997
 > ***************
 > *** 199,202 ****
 > --- 199,203 ----
 >   	    &size);
 >   	bzero(mp->mnt_stat.f_mntfromname + size, MNAMELEN - size);
 > + 	(void)nullfs_statfs(mp, &mp->mnt_stat, p);
 >   #ifdef NULLFS_DIAGNOSTIC
 >   	printf("nullfs_mount: lower %s, alias at %s\n",
 > 
 > Bruce
 
 

From: Bruce Evans <bde@zeta.org.au>
To: bde@zeta.org.au, cschuber@uumail.gov.bc.ca
Cc: cy@passer.osg.gov.bc.ca, freebsd-gnats-submit@freebsd.org
Subject: Re: kern/5355: Fix for NULLFS problems
Date: Tue, 23 Dec 1997 05:52:30 +1100

 >Would it be a good idea to to have a panic() or a printf() where I return a 
 >FALSE?  I'm torn between providing better diagnostic messages and reducing 
 >kernel bloat.  By doing a printf() or panic() any author of a filesystem would 
 >know that he would need to do some work on his code.
 
 I think you have to trust the [author of] the filesystem.  There are many
 other details that must be right, and this particular mistake probably
 won't be made again.
 
 Bruce

From: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca>
To: Bruce Evans <bde@zeta.org.au>
Cc: cschuber@uumail.gov.bc.ca, cy@passer.osg.gov.bc.ca,
        freebsd-gnats-submit@freebsd.org
Subject: Re: kern/5355: Fix for NULLFS problems 
Date: Tue, 23 Dec 1997 07:59:26 -0800

 Bruce, you're right.  Nullfs and umapfs don't have support for mmap.  A lot of 
 work needs to be put into nullfs and umapfs to make them support this (just 
 like unionfs).
 
 
 Regards,                       Phone:  (250)387-8437
 Cy Schubert                      Fax:  (250)387-5766
 UNIX Support                   OV/VM:  BCSC02(CSCHUBER)
 ITSD                          BITNET:  CSCHUBER@BCSC02.BITNET
 Government of BC            Internet:  cschuber@uumail.gov.bc.ca
                                        Cy.Schubert@gems8.gov.bc.ca
 
 		"Quit spooling around, JES do it."
 > >Would it be a good idea to to have a panic() or a printf() where I return a 
 > >FALSE?  I'm torn between providing better diagnostic messages and reducing 
 > >kernel bloat.  By doing a printf() or panic() any author of a filesystem wou
 ld 
 > >know that he would need to do some work on his code.
 > 
 > I think you have to trust the [author of] the filesystem.  There are many
 > other details that must be right, and this particular mistake probably
 > won't be made again.
 > 
 > Bruce
 > 
 
 

From: Cy Schubert <cys@wlc.com>
To: freebsd-gnats-submit@freebsd.org, cschuber@uumail.gov.bc.ca
Cc:  Subject: Re: kern/5355: Fix for NULLFS problems
Date: Sun, 18 Jan 1998 08:09:22 -0800

 I gave the code a try on one of my 2.2.5 systems and it won't even
 patch.  It appears that -current is radically different from -stable in
 this area making it impossible for me to patch 2.2.5 without upgrading
 to -current.
 
 I still have my original patch installed and have tested it thoroughly
 without any ill effects.  I can't even detect that I've created a memory
 leak.  The question I have is:  Can anyone think of any way that my
 original patch would adversely affect a -stable system?
 
 I've looked at the 4.4BSD-Lite, 4.4BSD-Lite2, NetBSD, and OpenBSD source
 for the nullfs and umapfs filesystems.  It appears that FreeBSD has
 deviated from original BSD and that f_iosize will need to be a non-zero
 value deviates even further.  I'm not sure whether this is goodness or
 badness, however it does make portability between the other variants of
 4.4BSD an issue.  It would be nice to be able to take a filesystem from
 one of the other variants of 4.4BSD, compile it and have it work.
 
 Just my thoughts.
 
 
 Regards,                       Phone:  (250)387-8437
 Cy Schubert                      Fax:  (250)387-5766
 UNIX Support                   OV/VM:  BCSC02(CSCHUBER)
 ITSD                          BITNET:  CSCHUBER@BCSC02.BITNET
 Government of BC            Internet:  cschuber@uumail.gov.bc.ca
                                        Cy.Schubert@gems8.gov.bc.ca
 
                 "Quit spooling around, JES do it."
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: phk 
State-Changed-When: Sun Apr 19 12:56:20 PDT 1998 
State-Changed-Why:  
Cy, can you  give an update on this one ? 

From: "Vladimir B. Grebenschikov" <vova@plugcom.ru>
To: freebsd-gnats-submit@freebsd.org, cschuber@uumail.gov.bc.ca
Cc:  Subject: Re: kern/5355: Fix for NULLFS problems
Date: Tue, 17 Nov 1998 20:26:54 +0300

 It is not full workable fix :(
 
 # uname -a
 FreeBSD ds.express.ru 3.0-980520-SNAP FreeBSD 3.0-980520-SNAP #5: Thu
 Nov  5 23:22:39 MSK 1998     vova@ds.express.ru:/usr/src/sys/compile/DS 
 i386
 
 # mount -t null /home/ntmdt /users/home/ntmdt
 # cd /users/home/ntmdt
 # ls -ldi . WWW.access.log
 844906 drwxr-xr-x  32 ntmdt  ntmdt  3072   Nov 17 06:00 .
 846338 -rw-r--r--  1  ntmdt  ntmdt  116345 Nov 17 19:57 WWW.access.log
 # tail -f WWW.access.log
 // normal web log output here
 // ...
 // trying another user
 # umount /home/ntmdt
 # mount -t null /home/aqwamdt /users/home/aqwamdt
 # cd /users/home/aqwamdt
 # ls -ldi . WWW.access.log
 906380 drwxr-x---  4 aqwamdt  aqwamdt  512   Feb  7  1998 .
 906387 -rw-r-----  1 root     aqwamdt  46672 Mar 30  1998 WWW.access.log
 # tail -f WWW.access.log
 
 // on console imideatly appears:
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x40
 fault code              = supervisor read, page not present
 instruction pointer     = 0x8:0xf01779d9
 stack pointer           = 0x10:0xf7021ce0
 frame pointer           = 0x10:0xf7021dbc
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = interrupt enabled, resume, IOPL = 0
 current process         = 3648 (tail)
 interrupt mask          = 
 trap number             = 12
 panic: page fault
 
 // 100% repeating
 // when ... when  nullfs will work ????
 
 more:
 
 # md /users
 # cat bin.?? | tar -xpzf - -C /users
 # cp -p /usr/local/bin/perl /users/usr/local/bin
 # mount -t null /usr/local/lib/perl5 /users/usr/local/lib/perl5
 # chroot /users
 # perl
 use strict;
 ^D
 # 
 # perl
 use stict;
 use Net::Ping;
 ^D
 ... PAGE fault in kernel ... current process: perl
 
 
 -- 
 
 Plug Communication ISP, Moscow
 Vladimir B. Grebenschikov, vova@plugcom.ru, 2:5020/302@fidonet.org

From: Cy Schubert <cschuber@uumail.gov.bc.ca>
To: "Vladimir B. Grebenschikov" <vova@plugcom.ru>
Cc: freebsd-gnats-submit@freebsd.org, cschuber@uumail.gov.bc.ca,
        bde@zeta.org.au
Subject: Re: kern/5355: Fix for NULLFS problems 
Date: Tue, 17 Nov 1998 11:53:23 -0800

 You may want to try Bruce Evans' patch discussed in the PR under 3.0.  
 My patch has only been tested on -stable.
 
 
 Regards,                       Phone:  (250)387-8437
 Cy Schubert                      Fax:  (250)387-5766
 Open Systems Group          Internet:  Cy.Schubert@uumail.gov.bc.ca
 ITSD                                   Cy.Schubert@gems8.gov.bc.ca
 Government of BC            
                                        
 In message <3651B1DE.3D5F4E0C@plugcom.ru>, "Vladimir B. Grebenschikov" 
 writes:
 > 
 > It is not full workable fix :(
 > 
 > # uname -a
 > FreeBSD ds.express.ru 3.0-980520-SNAP FreeBSD 3.0-980520-SNAP #5: Thu
 > Nov  5 23:22:39 MSK 1998     vova@ds.express.ru:/usr/src/sys/compile/DS 
 > i386
 > 
 > # mount -t null /home/ntmdt /users/home/ntmdt
 > # cd /users/home/ntmdt
 > # ls -ldi . WWW.access.log
 > 844906 drwxr-xr-x  32 ntmdt  ntmdt  3072   Nov 17 06:00 .
 > 846338 -rw-r--r--  1  ntmdt  ntmdt  116345 Nov 17 19:57 WWW.access.log
 > # tail -f WWW.access.log
 > // normal web log output here
 > // ...
 > // trying another user
 > # umount /home/ntmdt
 > # mount -t null /home/aqwamdt /users/home/aqwamdt
 > # cd /users/home/aqwamdt
 > # ls -ldi . WWW.access.log
 > 906380 drwxr-x---  4 aqwamdt  aqwamdt  512   Feb  7  1998 .
 > 906387 -rw-r-----  1 root     aqwamdt  46672 Mar 30  1998 WWW.access.log
 > # tail -f WWW.access.log
 > 
 > // on console imideatly appears:
 > Fatal trap 12: page fault while in kernel mode
 > fault virtual address   = 0x40
 > fault code              = supervisor read, page not present
 > instruction pointer     = 0x8:0xf01779d9
 > stack pointer           = 0x10:0xf7021ce0
 > frame pointer           = 0x10:0xf7021dbc
 > code segment            = base 0x0, limit 0xfffff, type 0x1b
 >                         = DPL 0, pres 1, def32 1, gran 1
 > processor eflags        = interrupt enabled, resume, IOPL = 0
 > current process         = 3648 (tail)
 > interrupt mask          = 
 > trap number             = 12
 > panic: page fault
 > 
 > // 100% repeating
 > // when ... when  nullfs will work ????
 > 
 > more:
 > 
 > # md /users
 > # cat bin.?? | tar -xpzf - -C /users
 > # cp -p /usr/local/bin/perl /users/usr/local/bin
 > # mount -t null /usr/local/lib/perl5 /users/usr/local/lib/perl5
 > # chroot /users
 > # perl
 > use strict;
 > ^D
 > # 
 > # perl
 > use stict;
 > use Net::Ping;
 > ^D
 > ... PAGE fault in kernel ... current process: perl
 > 
 > 
 > -- 
 > 
 > Plug Communication ISP, Moscow
 > Vladimir B. Grebenschikov, vova@plugcom.ru, 2:5020/302@fidonet.org
 
 

From: Sheldon Hearn <sheldonh@iafrica.com>
To: Cy Schubert <cschuber@uumail.gov.bc.ca>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/5355: Fix for NULLFS problems
Date: Fri, 19 Mar 1999 15:40:29 +0200

 Hi Cy,
 
 Now that we have 3.1-STABLE and 4.0-CURRENT, can you offer any feedback
 on your PR (kern/5355) and the state of NULLFS in either of those?
 
 Thanks,
 Sheldon.
 

From: Cy Schubert <cschuber@uumail.gov.bc.ca>
To: Sheldon Hearn <sheldonh@iafrica.com>
Cc: Cy Schubert <cschuber@uumail.gov.bc.ca>,
	freebsd-gnats-submit@freebsd.org
Subject: Re: kern/5355: Fix for NULLFS problems 
Date: Fri, 19 Mar 1999 12:21:11 -0800

 Sure, I'll test it out tonight (or tomorrow morning) after work.
 
 
 Regards,                       Phone:  (250)387-8437
 Cy Schubert                      Fax:  (250)387-5766
 Open Systems Group          Internet:  Cy.Schubert@uumail.gov.bc.ca
 ITSD                                   Cy.Schubert@gems8.gov.bc.ca
 Province of BC            
                                        
 In message <90310.921850829@axl.noc.iafrica.com>, Sheldon Hearn 
 writes:
 > 
 > Hi Cy,
 > 
 > Now that we have 3.1-STABLE and 4.0-CURRENT, can you offer any feedback
 > on your PR (kern/5355) and the state of NULLFS in either of those?
 > 
 > Thanks,
 > Sheldon.
 
 
 

From: Cy Schubert <cschuber@uumail.gov.bc.ca>
To: Sheldon Hearn <sheldonh@iafrica.com>
Cc: Cy Schubert <cschuber@uumail.gov.bc.ca>,
	freebsd-gnats-submit@freebsd.org
Subject: Re: kern/5355: Fix for NULLFS problems 
Date: Fri, 19 Mar 1999 14:40:31 -0800

 The problem is still there in 3.1, even with Bruce's 
 "(void)nullfs_statfs(mp, &mp->mnt_stat, p);" fix in place.  My 
 patch fixes the divide by zero panic.
 
 I've tested Vladimir Grebenschikov's problem, a page not present 
 panic.  I cannot recreate his problem.
 
 
 Regards,                       Phone:  (250)387-8437
 Cy Schubert                      Fax:  (250)387-5766
 Open Systems Group          Internet:  Cy.Schubert@uumail.gov.bc.ca
 ITSD                                   Cy.Schubert@gems8.gov.bc.ca
 Province of BC            
                                        
 In message <90310.921850829@axl.noc.iafrica.com>, Sheldon Hearn 
 writes:
 > 
 > Hi Cy,
 > 
 > Now that we have 3.1-STABLE and 4.0-CURRENT, can you offer any feedback
 > on your PR (kern/5355) and the state of NULLFS in either of those?
 > 
 > Thanks,
 > Sheldon.
 
 
 
State-Changed-From-To: feedback->open 
State-Changed-By: adrian 
State-Changed-When: Wed Mar 15 14:56:17 PST 2000 
State-Changed-Why:  
Feedback did arrive .. 

Noticed by: Marius <mbendiks@eunet.no> 
Responsible-Changed-From-To: freebsd-bugs->bp 
Responsible-Changed-By: phantom 
Responsible-Changed-When: Sun Oct 22 07:33:48 PDT 2000 
Responsible-Changed-Why:  
Boris is our nullfs guru, it's time to pass him related PRs 

http://www.freebsd.org/cgi/query-pr.cgi?pr=5355 
State-Changed-From-To: open->closed 
State-Changed-By: des 
State-Changed-When: Mon Mar 12 16:08:50 PST 2001 
State-Changed-Why:  


http://www.freebsd.org/cgi/query-pr.cgi?pr=5355 
State-Changed-From-To: closed->open 
State-Changed-By: des 
State-Changed-When: Mon Mar 12 16:10:06 PST 2001 
State-Changed-Why:  
Closed by mistake. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=5355 
State-Changed-From-To: open->closed 
State-Changed-By: bp 
State-Changed-When: Mon Jun 25 21:26:39 PDT 2001 
State-Changed-Why:  
Most of nullfs bugs fixed in the -current and RELENG_4. 


http://www.FreeBSD.org/cgi/query-pr.cgi?pr=5355 
>Unformatted:
