From owner-freebsd-current@FreeBSD.ORG Fri Jul 4 05:43:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD7041065674; Fri, 4 Jul 2008 05:43:12 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6B6998FC1A; Fri, 4 Jul 2008 05:43:12 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KEe44-0004zJ-0d; Fri, 04 Jul 2008 07:42:36 +0200 Message-ID: <486DB848.8000408@gwdg.de> Date: Fri, 04 Jul 2008 07:42:32 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.14 (X11/20080609) MIME-Version: 1.0 To: Kostik Belousov References: <486BFFE5.1010808@FreeBSD.org> <20080703193856.GS17123@deviant.kiev.zoral.com.ua> In-Reply-To: <20080703193856.GS17123@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Doug Barton , freebsd-current@freebsd.org Subject: Re: Panic using rsync to msdosfs filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2008 05:43:13 -0000 The panic when moving files on msdosfs also disappeared. Thank you for the patch. Rainer Hurling On 03.07.2008 21:38 (UTC+1), Kostik Belousov wrote: > On Wed, Jul 02, 2008 at 03:23:33PM -0700, Doug Barton wrote: >> I have a western digital passport USB hard drive that I use for >> backups. It's always worked fine in FreeBSD and Windows doing straight >> copies. Today I tried to get fancy and use rsync and it blew up on me. >> >> It is a large disk (160G) and I use the following options in fstab: >> /dev/da0s1 /mnt/wd msdosfs rw,noauto,-olarge,-m775 0 0 >> >> Using the following command line for rsync I get a panic as soon as I >> hit return: rsync -vv --backup -u -rlt source/ destination/ >> >> I'm using -current as of r180191. Here is the stack trace: >> Unread portion of the kernel message buffer: >> panic: stack overflow detected; backtrace may be corrupted >> cpuid = 1 >> Uptime: 1h52m1s >> Physical memory: 2029 MB >> Dumping 133 MB: 118 102 86 70 54 38 22 6 >> >> Reading symbols from /boot/modules/nvidia.ko...Reading symbols from >> /boot/modules/nvidia.ko.symbols...done. >> done. >> Loaded symbols for /boot/modules/nvidia.ko >> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >> /boot/kernel/acpi.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/acpi.ko >> Reading symbols from /boot/kernel/if_bge.ko...Reading symbols from >> /boot/kernel/if_bge.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/if_bge.ko >> Reading symbols from /boot/kernel/linux.ko...Reading symbols from >> /boot/kernel/linux.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/linux.ko >> Reading symbols from /boot/kernel/msdosfs.ko...Reading symbols from >> /boot/kernel/msdosfs.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/msdosfs.ko >> #0 doadump () at pcpu.h:196 >> 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); >> (kgdb) where >> #0 doadump () at pcpu.h:196 >> #1 0xc057a9ce in boot (howto=260) >> at /usr/local/src/sys/kern/kern_shutdown.c:418 >> #2 0xc057ac93 in panic (fmt=Variable "fmt" is not available. >> ) at /usr/local/src/sys/kern/kern_shutdown.c:572 >> #3 0xc059c5b2 in __stack_chk_fail () >> at /usr/local/src/sys/kern/stack_protector.c:17 >> #4 0xc652384a in msdosfs_rename (ap=0xc644aca4) >> at >> /usr/local/src/sys/modules/msdosfs/../../fs/msdosfs/msdosfs_vnops.c:1286 >> #5 0xc07b4df5 in VOP_RENAME_APV (vop=0xc6525cc0, a=0xe9e59c1c) >> at vnode_if.c:1184 >> #6 0xc0605619 in kern_renameat (td=0xc58f1d20, oldfd=-100, >> old=0xbfbfc4a0
, newfd=-100, >> new=0xbfbfcca0
, >> pathseg=UIO_USERSPACE) >> at vnode_if.h:622 >> #7 0xc06057a6 in kern_rename (td=0xc58f1d20, >> from=0xbfbfc4a0
, >> to=0xbfbfcca0
, >> pathseg=UIO_USERSPACE) >> at /usr/local/src/sys/kern/vfs_syscalls.c:3526 >> #8 0xc06057d9 in rename (td=0xc58f1d20, uap=0xe9e59cf8) >> at /usr/local/src/sys/kern/vfs_syscalls.c:3503 >> #9 0xc07a6283 in syscall (frame=0xe9e59d38) >> at /usr/local/src/sys/i386/i386/trap.c:1081 >> #10 0xc078bb80 in Xint0x80_syscall () >> at /usr/local/src/sys/i386/i386/exception.s:261 >> #11 0x00000033 in ?? () >> Previous frame inner to this frame (corrupt stack?) >> >> >> Let me know what I can do to help. > > Looks like this is the first casuality of the -fstack-protector. > Try this: > > diff --git a/sys/fs/msdosfs/msdosfs_vnops.c b/sys/fs/msdosfs/msdosfs_vnops.c > index 8a1484f..fe673e0 100644 > --- a/sys/fs/msdosfs/msdosfs_vnops.c > +++ b/sys/fs/msdosfs/msdosfs_vnops.c > @@ -982,7 +982,7 @@ msdosfs_rename(ap) > struct componentname *tcnp = ap->a_tcnp; > struct componentname *fcnp = ap->a_fcnp; > struct denode *ip, *xp, *dp, *zp; > - u_char toname[11], oldname[11]; > + u_char toname[12], oldname[11]; > u_long from_diroffset, to_diroffset; > u_char to_count; > int doingdirectory = 0, newparent = 0;