From garrigue@kurims.kyoto-u.ac.jp  Mon Jan 27 01:16:04 2003
Return-Path: <garrigue@kurims.kyoto-u.ac.jp>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 4B73937B401
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 27 Jan 2003 01:16:04 -0800 (PST)
Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1])
	by mx1.FreeBSD.org (Postfix) with ESMTP id B001843E4A
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 27 Jan 2003 01:16:02 -0800 (PST)
	(envelope-from garrigue@kurims.kyoto-u.ac.jp)
Received: from localhost (tet.kurims.kyoto-u.ac.jp [130.54.16.184])
	by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id SAA24106;
	Mon, 27 Jan 2003 18:16:00 +0900 (JST)
Message-Id: <20030127181522G.garrigue@kurims.kyoto-u.ac.jp>
Date: Mon, 27 Jan 2003 18:15:22 +0900
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: FreeBSD-gnats-submit@freebsd.org
Subject: tar buggy on memory disk partitions
X-Send-Pr-Version: 3.113

>Number:         47538
>Category:       bin
>Synopsis:       tar buggy on memory disk partitions
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 27 01:20:00 PST 2003
>Closed-Date:    Thu Jan 22 16:51:06 PST 2004
>Last-Modified:  Thu Jan 22 16:51:06 PST 2004
>Originator:     Jacques Garrigue
>Release:        FreeBSD 5.0-RELEASE i386
>Organization:
Kyoto University
>Environment:
System: FreeBSD tet.kurims.kyoto-u.ac.jp 5.0-RELEASE FreeBSD 5.0-RELEASE #2: Mon Jan 27 08:02:56 JST 2003 garrigue@tet.kurims.kyoto-u.ac.jp:/usr/src/sys/i386/compile/KABOSU i386

>Description:

When used on a memory disk (md), tar exhibits buggy behaviour,
corrupting the data in subtle ways.

As a result, specifying PKG_TMPDIR to /tmp, when /tmp is a swap-backed
memory disk as described in mdconfig(8), will corrupt the installed
packages.

This may seem a minor problem, but amateurs of vn and memfs (both
victims of take-over from md) are going to have serious problems with
5.0.

>How-To-Repeat:

Mount a memory disk on /tmp, as described in mdconfig(8)

	mdconfig -a -t swap -s 128M -u 10
        newfs -U /dev/md10
        mount /dev/md10 /tmp
        chmod 1777 /tmp

Use pkg_add to install some big package

        pkg_add -r phoenix

Try to use the package:

        phoenix
	Segmentation fault

You can check the corruption by expanding the package somewhere else
and doing a diff -r.

Alternatively, you can copy some large amount of data from somewhere:

tar cf - -C /usr bin | tar xvf - -C /tmp
diff -r /usr/bin /tmp/bin

>Fix:

I have no fix, but I could check that pax does not exhibit such
behaviour.
So if you only need to copy some data to a memory disk, you can use
pax.
>Release-Note:
>Audit-Trail:

From: Giorgos Keramidas <keramida@FreeBSD.ORG>
To: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
Cc: bug-followup@FreeBSD.ORG
Subject: Re: bin/47538: tar buggy on memory disk partitions
Date: Mon, 27 Jan 2003 19:16:19 +0200

 On 2003-01-27 18:15, Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> wrote:
 > When used on a memory disk (md), tar exhibits buggy behaviour,
 > corrupting the data in subtle ways. [...]
 >
 > Alternatively, you can copy some large amount of data from
 > somewhere:
 >
 > tar cf - -C /usr bin | tar xvf - -C /tmp
 > diff -r /usr/bin /tmp/bin
 
 Can you try a newer version of the 5.X branch?
 It seems that this is fixed in -CURRENT.
 
 $ uname -v
 FreeBSD 5.0-CURRENT #4: Mon Jan 27 12:46:21 EET 2003 [...]
 $ mount | grep /tmp
 /dev/md10c on /tmp (ufs, local, soft-updates)
 $ cd /tmp
 $ tar cf - -C /usr bin | tar xf -
 $ diff -r /usr/bin /tmp/bin
 $
 

From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: keramida@FreeBSD.ORG
Cc: bug-followup@FreeBSD.ORG
Subject: Re: bin/47538: tar buggy on memory disk partitions
Date: Tue, 28 Jan 2003 12:55:39 +0900

 From: Giorgos Keramidas <keramida@FreeBSD.ORG>
 > On 2003-01-27 18:15, Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> wrote:
 > > When used on a memory disk (md), tar exhibits buggy behaviour,
 > > corrupting the data in subtle ways. [...]
 > >
 > > Alternatively, you can copy some large amount of data from
 > > somewhere:
 > >
 > > tar cf - -C /usr bin | tar xvf - -C /tmp
 > > diff -r /usr/bin /tmp/bin
 > 
 > Can you try a newer version of the 5.X branch?
 > It seems that this is fixed in -CURRENT.
 
 Thanks for your answer.
 I tried with -CURRENT of this morning, and could repeat the problem.
 I confirm that this is a tar specific problem: it is avoided with pax.
 There seems to be some caching going on, so you may have to tweak sizes.
 Immediately after boot, copy /usr/bin only is not enough to trigger
 the problem. But if I also copy /usr/local/bin (30MB), then diff -r on
 the previously copied /usr/bin finds differences!
 Note that I am working on an old laptop, with only 64MB of memory, so
 that the swap is really used. My swap partition is 256MB.
 Note also that the problem is not swap specific: I could reproduce it
 with a file-backed md, the file on a ufs partition.
 
 I profit from the occasion to confirm also PR i386/45558. Writing on a
 file backed md hangs, when the file is on an msdos partition.
 
 Actually I have another related problem: creating a big file on an
 msdos partition with
 	dd if=/dev/null of=/dos/myfile seek=200000
 hangs also, after allocating the file (scandisk recovers it).
 
 ---------------------------------------------------------------------------
 Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
 		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>

From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: keramida@FreeBSD.ORG
Cc: bug-followup@FreeBSD.ORG
Subject: Re: bin/47538: tar buggy on memory disk partitions
Date: Mon, 12 May 2003 16:24:13 +0900

 Just a small followup to this PR, as this bug is definitely still
 present in 5.1-BETA (using GENERIC kernel).
 
 I did the same test on a different machine, with 256MB physical memory
 and a md of size 256M, and again obtained discrepancies when filling
 it with tar.
 
 If this problem cannot be solved before 5.1-RELEASE, I think it would
 be a good idea to mention it somewhere, as there seems to be lots of
 people around who used memfs for /tmp under 4.x, and may end up with
 corrupted data because of that.
 
 Cheers,
 
 Jacques Garrigue

From: Giorgos Keramidas <keramida@freebsd.org>
To: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
Cc: bug-followup@freebsd.org
Subject: Re: bin/47538: tar buggy on memory disk partitions
Date: Thu, 15 May 2003 15:34:50 +0300

 Just a note that mdconfig -d is badly broken here.  This is probably an
 indication of more serious problems of md(4) that might be related to
 this problem report:
 
 : Date: Thu, 15 May 2003 02:24:28 +0300
 : Subject: Panic with swap-backed md devices
 : From: Giorgos Keramidas <keramida@ceid.upatras.gr>
 : To: current@freebsd.org
 : Message-ID: <20030514232428.GA731@gothmog.gr>
 :
 : Trying to create and destroy a swap-backed md device results in panics
 : with today's CURRENT.  I was trying to make a new -t swap md disk to
 : test the problem described in a PR.  Using the following small shell
 : script I noticed that it always causes a panic when mdconfig -d is run:
 :
 : 	mdconfig -a -t swap -s 100m -u 10
 : 	disklabel -r -w md10 auto
 : 	newfs -O 1 -b 8192 -s 1024 md10
 : 	mount /dev/md10 /mnt
 : 	mount
 : 	umount /mnt
 : 	mount
 : 	mdconfig -d -u 10
 :
 : The backtrace, in case anyone can understand from it why the kernel
 : panics is:
 :
 : # gdb -k /usr/obj/usr/src/sys/CELERON/kernel.debug vmcore.10
 : GNU gdb 5.2.1 (FreeBSD)
 : Copyright 2002 Free Software Foundation, Inc.
 : GDB is free software, covered by the GNU General Public License, and you are
 : welcome to change it and/or distribute copies of it under certain conditions.
 : Type "show copying" to see the conditions.
 : There is absolutely no warranty for GDB.  Type "show warranty" for details.
 : This GDB was configured as "i386-undermydesk-freebsd"...
 : panic: from debugger
 : panic messages:
 : ---
 : panic: mutex vm object not owned at /usr/src/sys/vm/vm_pager.c:267
 : Stack backtrace:
 : panic: from debugger
 : Uptime: 58m16s
 : Dumping 511 MB
 : ata0: resetting devices ..
 : done
 :  16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496
 : ---
 : Reading symbols from /usr/obj/usr/src/sys/CELERON/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
 : Loaded symbols for /usr/obj/usr/src/sys/CELERON/modules/usr/src/sys/modules/acpi/acpi.ko.debug
 : Reading symbols from /boot/kernel/star_saver.ko...done.
 : Loaded symbols for /boot/kernel/star_saver.ko
 : #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:238
 : 238		dumping++;
 : (kgdb) bt/x
 : A syntax error in expression, near `x'.
 : (kgdb) bt
 : #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:238
 : #1  0xc01da79d in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:370
 : #2  0xc01daa2f in panic () at /usr/src/sys/kern/kern_shutdown.c:543
 : #3  0xc0138669 in db_panic () at /usr/src/sys/ddb/db_command.c:448
 : #4  0xc013860c in db_command (last_cmdp=0xc03263c0, cmd_table=0x0, aux_cmd_tablep=0xc0322028,
 :     aux_cmd_tablep_end=0xc032202c) at /usr/src/sys/ddb/db_command.c:346
 : #5  0xc01386d7 in db_command_loop () at /usr/src/sys/ddb/db_command.c:470
 : #6  0xc013ac3a in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
 : #7  0xc02c8224 in kdb_trap (type=3, code=0, regs=0xdce06a5c) at /usr/src/sys/i386/i386/db_interface.c:170
 : #8  0xc02d721c in trap (frame=
 :       {tf_fs = -1070858216, tf_es = 16, tf_ds = 16, tf_edi = 256, tf_esi = -1003533952, tf_ebp = -589272416, tf_isp = -589272440, tf_ebx = 0, tf_edx = 0, tf_ecx = -1070041760, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070824307, tf_cs = 8, tf_eflags = 646, tf_esp = -1070554621, tf_ss = -589272388}) at /usr/src/sys/i386/i386/trap.c:593
 : #9  0xc02c9748 in calltrap () at {standard input}:96
 : #10 0xc01da9e7 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:527
 : #11 0xc01d3aac in _mtx_assert (m=0xc43bc000, what=0, file=0xc03195a2 "/usr/src/sys/vm/vm_pager.c", line=267)
 :     at /usr/src/sys/kern/kern_mutex.c:840
 : #12 0xc02a8b8d in vm_pager_deallocate (object=0xc43bc000) at /usr/src/sys/vm/vm_pager.c:267
 : #13 0xc015440b in mddestroy (sc=0xc4448700, td=0xc42f4980) at /usr/src/sys/dev/md/md.c:935
 : #14 0xc01545d7 in mddetach (unit=10, td=0xc42f4980) at /usr/src/sys/dev/md/md.c:1025
 : #15 0xc01546cc in mdctlioctl (dev=0xc037c420, cmd=3249564929, addr=0xc5e5ca00 "", flags=3, td=0xc42f4980)
 :     at /usr/src/sys/dev/md/md.c:1072
 : #16 0xc01ae3d2 in spec_ioctl (ap=0xdce06b88) at /usr/src/sys/fs/specfs/spec_vnops.c:347
 : #17 0xc01add67 in spec_vnoperate (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:123
 : #18 0xc0228047 in vn_ioctl (fp=0xc41e1dd4, com=3249564929, data=0xc5e5ca00, active_cred=0xc1511280, td=0xc42f4980)
 :     at vnode_if.h:488
 : #19 0xc01f68ac in ioctl (td=0xc42f4980, uap=0xdce06d14) at file.h:251
 : #20 0xc02d797d in syscall (frame=
 :       {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134561322, tf_esi = -1077936632, tf_ebp = -1077936888, tf_isp = -589271692, tf_ebx = 3, tf_edx = 0, tf_ecx = 0, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 134516183, tf_cs = 31, tf_eflags = 658, tf_esp = -1077936932, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1021
 : #21 0xc02c979d in Xint0x80_syscall () at {standard input}:138
 : ---Can't read userspace from dump, or kernel process---
 :
 : (kgdb) up 12
 : #12 0xc02a8b8d in vm_pager_deallocate (object=0xc43bc000) at /usr/src/sys/vm/vm_pager.c:267
 : 267		VM_OBJECT_LOCK_ASSERT(object, MA_OWNED);
 : (kgdb) list
 : 262	void
 : 263	vm_pager_deallocate(object)
 : 264		vm_object_t object;
 : 265	{
 : 266
 : 267		VM_OBJECT_LOCK_ASSERT(object, MA_OWNED);
 : 268		(*pagertab[object->type]->pgo_dealloc) (object);
 : 269	}
 : 270
 : 271	/*
 : (kgdb) up
 : #13 0xc015440b in mddestroy (sc=0xc4448700, td=0xc42f4980) at /usr/src/sys/dev/md/md.c:935
 : 935			vm_pager_deallocate(sc->object);
 : (kgdb) list
 : 930			(void)vn_close(sc->vnode, sc->flags & MD_READONLY ?
 : 931			    FREAD : (FREAD|FWRITE), sc->cred, td);
 : 932		if (sc->cred != NULL)
 : 933			crfree(sc->cred);
 : 934		if (sc->object != NULL) {
 : 935			vm_pager_deallocate(sc->object);
 : 936		}
 : 937		if (sc->indir)
 : 938			destroy_indir(sc, sc->indir);
 : 939		if (sc->uma)
 : (kgdb) quit

From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: bin/47538: tar buggy on memory disk partitions
Date: Wed, 17 Dec 2003 10:28:33 +0900

 Good news: I installed 5.2-RC1 a few days ago, and was unable to
 reproduce this bug.
 I'm now happily using an async mounted md disk as /tmp.
 
 I don't know when it was fixed, but I suppose we can close this one.
 
State-Changed-From-To: open->closed 
State-Changed-By: cperciva 
State-Changed-When: Thu Jan 22 16:50:15 PST 2004 
State-Changed-Why:  
Submitter says problem can be closed. 


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