From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 14:44:18 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 0821B1065696 for ; Mon, 23 Aug 2010 14:44:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 77A188FC17 for ; Mon, 23 Aug 2010 14:44:16 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7NEhXQh078108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Aug 2010 17:43:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7NEhWEH016605; Mon, 23 Aug 2010 17:43:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7NEhWsp016604; Mon, 23 Aug 2010 17:43:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Aug 2010 17:43:32 +0300 From: Kostik Belousov To: Ian FREISLICH Message-ID: <20100823144332.GH2396@deviant.kiev.zoral.com.ua> References: <20100823140149.GG2396@deviant.kiev.zoral.com.ua> <201008230826.49509.jhb@freebsd.org> <20100823132551.GE2396@deviant.kiev.zoral.com.ua> <20100823133555.GA64651@hoeg.nl> <20100823134459.GF2396@deviant.kiev.zoral.com.ua> <20100823134723.GC64651@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KyN5VKAiO6iH4v7I" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: Ed Schouten , 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 14:44:18 -0000 --KyN5VKAiO6iH4v7I Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 23, 2010 at 04:32:58PM +0200, Ian FREISLICH wrote: > Kostik Belousov wrote: > >=20 > > --7hK5U8dVDlZxii7z > > Content-Type: text/plain; charset=3Dus-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > >=20 > > On Mon, Aug 23, 2010 at 03:47:23PM +0200, Ed Schouten wrote: > > > * Kostik Belousov wrote: > > > > On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote: > > > > > * Kostik Belousov wrote: > > > > > > Which most likely means that fusesfs filled its own struct file= ops > > > > > > without properly initializing fo_truncate member. > > > > >=3D20 > > > > > It's a bit misleading that cdevs automatically patch the table, w= hile > > > > > the fileops don't. Maybe it would be a good idea to patch finit()= to > > > > I do not understand your first sentence. Would you please elaborate= ? > > >=3D20 > > > Say, you create a cdev, if you don't implement all ops, it will check > > > for null pointers and return error codes accordingly. This doesn't > > > happen for fileops, which is probably one of the reasons why people > > > sometimes forget to implement them. > > >=3D20 > > > Wouldn't it be better to prevent this form of footshooting by adding > > > assertions? This will add some overhead for any file descriptor creat= ed, > > > but a kernel with INVARIANTS isn't meant to be fast. > > Thanks, I see it now. > >=20 > > The cdev interface definitely falls into the public kernel interface. > > Having to fill all cdevsw methods for a random driver is too much > > burden put on the several dozens maintainers. > >=20 > > On the other hand, file level is not much widely used by third-party > > components, and even in-tree code implements only ten different file > > types. > >=20 > > I would not object loudly if someone put such checks as proposed > > under INVARIANTS, but also I do not see a real point in having them. > > Might be slightly better to put the checks, again under INVARIANTS, > > in the fo_XXX() wrappers. >=20 > So, in this case is the fusefs module broken? I'm guessing it is. > I don't like the way fuse_fileops is initialised in fuse4bsd. I > would prefer for the struct to be zeroed and then the fo_xxx > implimented bits set as appropriate. That way when the struct is > changed, you don't get stung again. >=20 > Patch attached to that makes fusefs-kmod not blowup kernels post this cha= nge. >=20 > Ian >=20 > --=20 > Ian Freislich >=20 > Index: files/patch-fuse_module__fuse_vnops.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/ports/sysutils/fusefs-kmod/files/patch-fuse_module__= fuse_vnops.c,v > retrieving revision 1.4 > diff -u -d -r1.4 patch-fuse_module__fuse_vnops.c > --- files/patch-fuse_module__fuse_vnops.c 30 Oct 2008 15:36:35 -0000 1.4 > +++ files/patch-fuse_module__fuse_vnops.c 23 Aug 2010 14:27:17 -0000 > +@@ -214,6 +214,7 @@ > + * following fields are filled from vnops, but "vnops.foo" is n= ot > + * legitimate in a definition, so we set them at module load ti= me > + */ > ++ .fo_truncate =3D NULL, > + .fo_ioctl =3D NULL, > + .fo_poll =3D NULL, > + .fo_kqfilter =3D NULL, Did you tested this ? I suppose that it would not change anything. Fuse, most likely, lacks real implementation of .fo_truncate method. The implementation was required for long time, otherwise file truncation would not work. --KyN5VKAiO6iH4v7I Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxyiRQACgkQC3+MBN1Mb4jU1gCdGGyYoMujuWFSPy8ZM1wIVYeq 2y4An2RCVdK6QJsvTTISBOnnHUFwxYxL =73Dj -----END PGP SIGNATURE----- --KyN5VKAiO6iH4v7I--