NetBSD Problem Report #2856

Received: (qmail-queue invoked from smtpd); 17 Oct 1996 18:18:08 -0000
Message-Id: <199610171816.UAA28213@kurt.tools.de>
Date: Thu, 17 Oct 1996 20:16:13 +0200
From: ws@kurt.tools.de (Wolfgang Solfrank)
Reply-To: ws@kurt.tools.de
To: gnats-bugs@gnats.netbsd.org
Subject: Mounting on directories provided by pseudo-filesystems can be lost
X-Send-Pr-Version: 3.95

>Number:         2856
>Category:       kern
>Synopsis:       Mounting on directories provided by pseudo-filesystems can be lost
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Oct 17 11:20:03 +0000 1996
>Closed-Date:    
>Last-Modified:  Mon Jun 05 22:16:24 +0000 2000
>Originator:     
>Release:        19961017
>Organization:
NetBSD Hackers
>Environment:

System: NetBSD august 1.2A NetBSD 1.2A (GENERIC) #23: Tue Oct 15 16:22:05 MET DST 1996
     ws@kurt:/home/NetBSD/kernel/NetBSD/sys/arch/powerpc/compile/GENERIC PowerPC

>Description:

Some pseudo-filesystems provide directories.  E.g the proc filesystem has
a directory for every process in the system.  These directories can get lost
independent of any filesystem activity.  When you mount some filesystem on
such a directory, you may loose the filesystem as you can neither access any
files on it nor even do an unmount of it.

A similar problem might be in nfs, when a client does a rmdir on some
directory the server has mounted something on, or when a server does an
rmdir of a directory a client has mounted something on (albeit the latter
will at least result in some ESTALE errors), but I cannot test this at
the moment.

>How-To-Repeat:

$ mount -t msdos /dev/ofdisk0c /proc/curproc

Subsequent mount calls will reveal a mount on /proc/xxx with xxx being some
process number, but ls /proc will not show this.

>Fix:

Unknown.
>Release-Note:
>Audit-Trail:
>Unformatted:

Home	PR Database Search