From owner-freebsd-arch@FreeBSD.ORG Wed Mar 20 11:14:33 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9828DE17 for ; Wed, 20 Mar 2013 11:14:33 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 33809F5C for ; Wed, 20 Mar 2013 11:14:32 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r2KBEHXO005520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Mar 2013 22:14:20 +1100 Date: Wed, 20 Mar 2013 22:14:17 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Doug Ambrisko Subject: Re: Increase the mount path to MAXPATHLEN? In-Reply-To: <20130319201145.GA19260@ambrisko.com> Message-ID: <20130320211433.F1007@besplex.bde.org> References: <20130319201145.GA19260@ambrisko.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=L4xF2Jv8 c=1 sm=1 a=irKjImMqKNAA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=YZcamMsAmuoA:10 a=BUiG9MIwPJjOGKL8dl8A:9 a=CjuIK1q_8ugA:10 a=oQh-wOpITFmlJKOk:21 a=QHnQFAiQZv-guDTr:21 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 11:14:33 -0000 On Tue, 19 Mar 2013, Doug Ambrisko wrote: > At work we use lots of chroots and mount things within those chroots > like dev, proc etc. so it looks like a running system. We also do > some trickery so that we chroot into different versions of FreeBSD > and pull in some of the native binaries so things like mount, ps etc. > work inside. We will also create chroots inside that. Since these > things live in home directories and mount points can be in various > tree's the mount points are getting pretty long. It seems that > checking before was weak and let some of these mount worked by accident > in prior versions of FreeBSD. Old versions worked correctly. Presumably this was not accidental. > Now there is better error checking and > the mounts fail since it exceeds MNAMELEN which was 88. I did notice Now there is broken error checking. Mounting is broken just because the data structure (struct statfs) is incapable of holding the full path length. But often nothing needs to know the full path. It is used mainly by df to report mounted file systems, and 88 is already too long for that. df output on freefall is unreadable due to filesystem name lengths of merely about 30. File systems are also incapable of holding the full path length in their super blocks. This is used mainly for "last mounted on" diagnostic messages in mount() and maybe fsck. It would be even more obviously broken to disallow mounting just because this data structure is too small. Despite its obvious brokenness, ext2fs does it, but currently has no effect since although ext2fs's superblock limit is smaller than 88, the check uses ext2fs's in-core superblock limit which is larger than 88 though smaller than MAXPATHLEN. The larger in-core name is completely useless, since broken mount prevents it all being used and the smaller superblock name prevents it being used usefully (the precise sizes are 64 for the disk and 512 for in-core). In ffs, the sizes are 468 for the disk and in-core. The broken mount prevents most of the 468 from being used. > before that sometimes unmount would unmount other things and could > be an issues with multiple scripts running at the same time. This > doesn't seem to be a problem now. Since the pathname reported by statfs() is now complete, it is unique. The old version should have modified the truncated pathnames in some way so that they are unique. They would never match any pathname to a mount point. Actually, if they are unique then they can be used to look up the non-truncated pathnames. > I'd like to bump the mount point to support a larger value then > MNAMELEN (88) and to some what avoid this problem in the future thought > we should just use MAXPATHLEN. I figure that once start hitting that > limit probably a bunch of things are going to pop up. The limited has been hittable for ~30 years, but rarely hit. If it were important, then it would have been expanded when statfs was expanded to support 64-bit sizes on 32-bit systems. Instead, the pathname arrays have shrunk a bit since 4.4BSD where they had size 90. Before that, bits of the pathnames were bitten off to make space for more important fields, and the array size was reduced to 80 in struct ostatfs. THe current struct statfs just unbites for these fields and expands back to size 80. Does using MAXPATHLEN even fix the problem? Absolute pathnames much longer than it can be constructed using relative paths starting in a deep directory, or symlinks. I think mount(2) handle relative paths, but mount(8) uses realpath(3) and the latter is almost necessary for making the pathnames returned by statfs() usable. realpath() is broken as designed. It repeats the design errors of getwd() and only supports pathname lengths of < {PATH_MAX}. This "fixes" the problem that the path length might be longer than that by not supporting such paths. NetBSD "fixed" this long ago by keeping struct statfs unchanged but deprecated, but using _VFS_MNAMELEN = 1024 in struct statvfs. In FreeBSD, statvfs() and struct statvfs are just minimal compatibility cruft, with no names at all in the struct since names are nonstandard. > This means we'll need to create new system calls for stat calls > and compatibility. It is a pain, since you need to build and install > a new kernel before you can run code with the new values. So there > is some pain involved. I've made this change locally on a system Too much pain for me. I still use statfs = ostatfs in sys/syscall.h so that the same (statically linked) userland works on a range of kernels going back to ones that don't have statfs. But since I don't use current userlands I don't really care. Bruce