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:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.