From owner-freebsd-fs@FreeBSD.ORG Thu Mar 1 11:05:17 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6B041065679 for ; Thu, 1 Mar 2012 11:05:17 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 5721B8FC13 for ; Thu, 1 Mar 2012 11:05:17 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q21B5DOc028742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Mar 2012 22:05:15 +1100 Date: Thu, 1 Mar 2012 22:05:13 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <20120301084801.GP55074@deviant.kiev.zoral.com.ua> Message-ID: <20120301214559.N3748@besplex.bde.org> References: <201202292037.q1TKbJDI072739@freefall.freebsd.org> <20120301115156.X1922@besplex.bde.org> <20120301084801.GP55074@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: kern/165559: [ufs] [patch] ufsmount.h uses the 'export' keyword as a structure member name X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 11:05:17 -0000 On Thu, 1 Mar 2012, Konstantin Belousov wrote: > On Thu, Mar 01, 2012 at 01:08:49PM +1100, Bruce Evans wrote: >> ... >> To summarise, even ffs utilities should be using this header. There are >> 1 or 2 ffs utilities that can reasonably use it, and a few non-ffs >> utilities that use since they haven't been converted to nmount(). amd >> is the only significant remaining one. >> > Yes. amd seems to have no references to `export' (it does have references to fspec). Thus the problem is very small. > I expect the bug submitter to finish the work and provide a complete > patch for renaming. That's asking a lot. > FWIW, the export_ is ugly, some reasonable name should be used. It could probably be renamed to `foo', or better yet, to `ugly' for userland only, and almost nothing would notice (I only noticed fsck_ffs accessing it, and that access was bogus (better done with bzero()) and went away with conversion to nmount()). Of course, the correct name is something like fa_export (fa = ffs args). In old mount(8), args.export was only used to initialize args.export.ex_root to DEFAULT_ROOTUID = -2 (uids can't be negative and this gets type-punned to 0xfffffffe) and args.export.ex_flags to either MNT_EXRDONLY or to 0 depending on whether the mount is r/o. I wonder how this works now. Current mount code doesn't pass "export" and doesn't define DEFAULT_ROOTUID. mountd still has a more-magic -2. and OP_MAPROOT to change it. Other callers of mount() didn't bother to set DEFAULT_ROOTUID or MNT_EXRDONLY. One in fsck_ffs even seems to pass stack garbage for the entire args.export. df still uses mount() and a ufs_args struct. It doesn't bother setting anything, but doesn't pass stack garbage since it uses a static args struct. Bruce