From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 13:29:10 2010 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 19D4D1065694; Mon, 23 Aug 2010 13:29:10 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 5851D8FC1A; Mon, 23 Aug 2010 13:29:09 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OnX5H-0004I9-M4; Mon, 23 Aug 2010 15:29:07 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnX5G-0001O3-PV; Mon, 23 Aug 2010 15:29:06 +0200 Message-Id: From: Ian FREISLICH X-Attribution: BOFH Date: Mon, 23 Aug 2010 15:29:06 +0200 Cc: freebsd-current@freebsd.org Subject: Re: fusefs-kmod broken? 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: Mon, 23 Aug 2010 13:29:10 -0000 Ian FREISLICH wrote: > John Baldwin wrote: > > The uart thing is a red herring, notice the actual PC value is '0'. Someth ing > > in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x35' in > > kgdb would be a good start of where to look. > > (kgdb) l *kern_open+0x35 > 0xc0649ce5 is in kern_open (/usr/src/sys/kern/vfs_syscalls.c:1040). > 1035 kern_open(struct thread *td, char *path, enum uio_seg pathseg, int fl ags, > 1036 int mode) > 1037 { > 1038 > 1039 return (kern_openat(td, AT_FDCWD, path, pathseg, flags, mode) ); > 1040 } > 1041 > 1042 int > 1043 kern_openat(struct thread *td, int fd, char *path, enum uio_seg paths eg, > 1044 int flags, int mode) > > That's what my reading seemed indicate. I had to downgrade the > system back to 8.0-STABLE at around 21 April 2010, to get the system > working. > > I'm currently doing a binary search to find offending commit, since > CURRENT and STABLE panic reliably, and in the same way I'm sure > that the problem is common to both. > > I'm down to a window of 9 hours. My money is currently on: > > Working file: sys/kern/vfs_syscalls.c > Approved by: re (bz) > ---------------------------- > revision 1.487.2.7 > date: 2010/04/27 10:47:54; author: kib; state: Exp; lines: +2 -15 > SVN rev 207270 on 2010-04-27 10:47:54Z by kib > > MFC r206547: > Handle a case in kern_openat() when vn_open() change file type from > DTYPE_VNODE. > ---------------------------- Confirmed. 1.487.2.6 doesn't panic, 1.487.2.7 does. This is the change that results in the panic. --- sys/kern/vfs_syscalls.c 16 Apr 2010 08:32:08 -0000 1.487.2.6 +++ sys/kern/vfs_syscalls.c 27 Apr 2010 10:47:54 -0000 1.487.2.7 @@ -35,7 +35,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.487.2.6 2010/04/16 08:32:08 kib Exp $"); +__FBSDID("$FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.487.2.7 2010/04/27 10:47:54 kib Exp $"); #include "opt_compat.h" #include "opt_kdtrace.h" @@ -1047,8 +1047,6 @@ struct filedesc *fdp = p->p_fd; struct file *fp; struct vnode *vp; - struct vattr vat; - struct mount *mp; int cmode; struct file *nfp; int type, indx, error; @@ -1141,7 +1139,7 @@ } VOP_UNLOCK(vp, 0); - if (flags & (O_EXLOCK | O_SHLOCK)) { + if (fp->f_type == DTYPE_VNODE && (flags & (O_EXLOCK | O_SHLOCK)) != 0) { lf.l_whence = SEEK_SET; lf.l_start = 0; lf.l_len = 0; @@ -1158,18 +1156,7 @@ atomic_set_int(&fp->f_flag, FHASLOCK); } if (flags & O_TRUNC) { - if ((error = vn_start_write(vp, &mp, V_WAIT | PCATCH)) != 0) - goto bad; - VATTR_NULL(&vat); - vat.va_size = 0; - vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); -#ifdef MAC - error = mac_vnode_check_write(td->td_ucred, fp->f_cred, vp); - if (error == 0) -#endif - error = VOP_SETATTR(vp, &vat, td->td_ucred); - VOP_UNLOCK(vp, 0); - vn_finished_write(mp); + error = fo_truncate(fp, 0, td->td_ucred, td); if (error) goto bad; } mount: /dev/fuse0 on /1-wire (fusefs, local, synchronous) Something about it has a write echo -n 192 > /1-wire/29.A52A03000000/PIO.BYTE Panic. But not like: echo -n 192 >> /1-wire/29.A52A03000000/PIO.BYTE I suspect the truncate is not safe. Or, at least this fuse presented fite cannot be truncated. Ian -- Ian Freislich