NetBSD Problem Report #31507

From simonb@thistledown.com.au  Sat Oct  8 12:50:57 2005
Return-Path: <simonb@thistledown.com.au>
Received: from thoreau.thistledown.com.au (thoreau.thistledown.com.au [203.217.30.154])
	by narn.netbsd.org (Postfix) with ESMTP id 0239663B8C8
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  8 Oct 2005 12:50:55 +0000 (UTC)
Message-Id: <20051008125043.AD628236E8@thoreau.thistledown.com.au>
Date: Sat,  8 Oct 2005 22:50:43 +1000 (EST)
From: Simon Burge <simonb@netbsd.org>
Reply-To: Simon Burge <simonb@netbsd.org>
To: gnats-bugs@netbsd.org
Subject: getcwd returns ERANGE after directory move across null mount
X-Send-Pr-Version: 3.95

>Number:         31507
>Category:       kern
>Synopsis:       getcwd returns ERANGE after directory move across null mount
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Oct 08 12:51:00 +0000 2005
>Closed-Date:    Sun Jul 31 22:48:20 +0000 2016
>Last-Modified:  Sun Jul 31 22:48:20 +0000 2016
>Originator:     Simon Burge <simonb@wasabisystems.com>
>Release:        NetBSD 3.0_BETA, September 6 2005 sources
>Organization:
Wasabi Systems
>Environment:
System: NetBSD thoreau 3.0_BETA NetBSD 3.0_BETA (THOREAU) #1:
	Tue Sep 6 01:13:10 EST 2005
	simonb@thoreau:/usr/obj/sys/arch/i386/compile/THOREAU i386
Architecture: i386
Machine: i386
>Description:
	Moving a directory from the "top" part of a null mount to the
	"bottom" part of a null mount and then calling getcwd(2) gets an
	ERANGE error.  This problem exists on the netbsd-3 branch but
	doesn't exist in -current (as of around Sep 29 2005).

>How-To-Repeat:
	In one window:

		thoreau 1> mount | grep home
		/data/00/home on /home type null (hidden, NFS exported, local)
		thoreau 2> df .
		Filesystem    1K-blocks      Used     Avail Capacity  Mounted on
		/data/00/home 102985734  87545602  10290846    89%    /home
		thoreau 3> mkdir foo
		thoreau 4> cd foo
		thoreau 5> pwd
		/home/simonb/foo

	In another window:

		thoreau 1# mv /home/simonb/foo /data/00/foofoo

	Back in the first window:

		thoreau 6> pwd
		pwd: Result too large or too small
		 (this is getcwd(2) returning ERANGE)

	Using a small program that uses a 1MB buffer passed to getcwd(2)
	still fails with ERANGE.  A ktrace of mv shows that rename(2) is
	used instead of copying:

		10169 mv       CALL  rename(0xbfbfe9ef,0xbfbfea00)
		10169 mv       NAMI  "/home/simonb/foo"
		10169 mv       NAMI  "/data/00/foofoo"
		10169 mv       RET   rename 0

>Fix:
	None given.

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: pooka@narn.netbsd.org
State-Changed-When: Sun, 20 Jan 2008 16:51:12 +0200
State-Changed-Why:
upgrade to NetBSD4? ;)


State-Changed-From-To: feedback->open
State-Changed-By: simonb@NetBSD.org
State-Changed-When: Mon, 05 May 2008 05:26:01 +0000
State-Changed-Why:
On a NetBSD 4 machine (with X) this just paniced/rebooted, instead
of giving an error.  Much worse behaviour :-(

Will try to get details on a machine with serial console.


From: Simon Burge <simonb@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: Re: kern/31507: getcwd returns ERANGE after directory move across null mount 
Date: Mon, 05 May 2008 16:41:37 +1000

 With netbsd-4 from October 26 2007, the same test just traps/panics.
 A backtrace from core dump doesn't show anything useful really (stack
 corruption?):

   (gdb) bt
   #0  0xc04ef80a in cpu_reboot (howto=0, bootstr=0x0)
       at ./sys/arch/i386/i386/machdep.c:896
   #1  0xc04571bb in panic (fmt=0x0) at ./sys/kern/subr_prf.c:246
   #2  0xc04f9f5f in trap (frame=0xd13ea754) at ./sys/arch/i386/i386/trap.c:339
   #3  0xc010b239 in calltrap ()
   #4  0xd13ea754 in ?? ()
   #5  0xd13e0010 in ?? ()
   #6  0xd13e0030 in ?? ()
   #7  0xc0a30010 in playstats ()
   #8  0x00000010 in ?? ()
   #9  0x00000002 in ?? ()
   #10 0x00000002 in ?? ()
   #11 0xd13ea79c in ?? ()
   #12 0x00000004 in ?? ()
   #13 0x00000000 in ?? ()

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: simonb@NetBSD.org
Subject: Re: kern/31507 (getcwd returns ERANGE after directory move across
	null mount)
Date: Sat, 19 Sep 2009 19:39:33 +0000

 On Mon, May 05, 2008 at 05:26:02AM +0000, simonb@NetBSD.org wrote:
  > Synopsis: getcwd returns ERANGE after directory move across null mount

 Attempting this should just give EXDEV - is there some reason that
 mixing FSes like this is supposed to be allowed? What FS were you
 using under the null mount?

 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 19 Sep 2009 19:59:35 +0000
State-Changed-Why:
I have a question.


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 01 May 2011 00:35:39 +0000
State-Changed-Why:
No answer to my question. But, without knowing what FS was under the null
mount, it's hard to know what steps to take. FFS in -4 should yield EXDEV
in this case... or so I believe anyway, but I might be wrong...


From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/31507 (getcwd returns ERANGE after directory move across
 null mount)
Date: Sun, 1 May 2011 01:40:43 +0000

 On Sun, May 01, 2011 at 12:35:40AM +0000, dholland@NetBSD.org wrote:
  > No answer to my question. But, without knowing what FS was under the null
  > mount, it's hard to know what steps to take. FFS in -4 should yield EXDEV
  > in this case... or so I believe anyway, but I might be wrong...

 Nope, I'm wrong. It appears that because the EXDEV checks are under
 the VFS interface, and because layer_bypass is too permissive, you can
 set up like this:

    mkdir /tmp/tree
    mkdir /tmp/tree/oak
    mkdir /tmp/tree/oak/leaf
    mkdir /tmp/null
    mount -t null /tmp/tree /tmp/null
    cd /tmp/null/oak/leaf

 then do:

    mv /tmp/null/oak/leaf /tmp/tree/

 and it will succeed. This doesn't crash -current, even if the moved
 directory is your working directory; it leaves you in the same state
 as if your working directory is rmdir'd under you.

 However, it ought not to be allowed.

 There is no legitimate reason to allow operations like this, so I'm
 highly inclined to add cross-device checks to do_sys_rename (like
 rmind recently did for link) and then pull them up to -4 and -5.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Alan Barrett <apb@cequrux.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/31507 (getcwd returns ERANGE after directory move across
 null mount)
Date: Tue, 3 May 2011 14:02:48 +0200

 On Sun, 01 May 2011, David Holland wrote:
 > Nope, I'm wrong. It appears that because the EXDEV checks are under
 > the VFS interface, and because layer_bypass is too permissive, you can
 > set up like this:
 >
 >    mkdir /tmp/tree
 >    mkdir /tmp/tree/oak
 >    mkdir /tmp/tree/oak/leaf
 >    mkdir /tmp/null
 >    mount -t null /tmp/tree /tmp/null
 >    cd /tmp/null/oak/leaf
 >
 > then do:
 >
 >    mv /tmp/null/oak/leaf /tmp/tree/
 >
 > and it will succeed. This doesn't crash -current, even if the moved
 > directory is your working directory; it leaves you in the same state
 > as if your working directory is rmdir'd under you.
 >
 > However, it ought not to be allowed.

 mv(1) should allow that, and should implement it using copy and 
 delete.  rename(2) should not allow it.

 --apb (Alan Barrett)

State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 31 Jul 2016 22:48:20 +0000
State-Changed-Why:
Since the rename fixes in -5 this actually works -- the last behavior I
observed was actually mv doing copy-and-delete.

If you try to do mv /tmp/null/oak/leaf /tmp/tree/oak/leaf, it causes mv to
get horribly confused, but it doesn't crash the system. "don't do that"


>Unformatted:

Home	PR Database Search