From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 01:05:35 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06A126CB; Tue, 20 Jan 2015 01:05:35 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DA389617; Tue, 20 Jan 2015 01:05:34 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id B182A266C; Mon, 19 Jan 2015 17:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1421715933; x=1421730333; bh=BuhBwC5RnOIR/gfHROfzE1pBsc1aK+DL8X1kEpzOJb0=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=t9j0ru/YoUgeeDDWopbvfGW/xaWTPWYNHLhZT6chBYsfwm8Ofgv3b6D/z/aJwTrdF +vYTwxCh+s5dtihibpA4SYD4s6dpMlWdBcbspSusN3aHU34F1Jpk2SEZRds0IfOh2L EoBBNiCWqa1HW/9pB25+dOCHb+JrGzb+ndUVB2Z4= Message-ID: <54BDA9DD.5040608@delphij.net> Date: Mon, 19 Jan 2015 17:05:33 -0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Garrett Cooper , Brandon Allbery Subject: Re: old bug: mount_nfs path/name is limited to 88 chars References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> In-Reply-To: <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: mexas@bris.ac.uk, rmacklem@uoguelph.ca, freebsd-stable , freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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: Tue, 20 Jan 2015 01:05:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/19/15 13:20, Garrett Cooper wrote: > On Jan 19, 2015, at 8:46, Brandon Allbery > wrote: > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht >> wrote: >> >>> So perhaps changing MNAMELEN will break statfs(2) on -stable >>> too? >>> >> >> I believe the context there is not so much "-current is special", >> as "changing it for everyone is bad news" (and this would >> necessarily need to originate in -current). > > A compat layer needs to be created for all of the affected > syscalls, and the change needs to be made. That’s it in a > nutshell. > > Doing it in 11 makes sense since there is a compat layer for 10 > now… if I knew all of the steps I would happily do them as annoys > me from time to time as well with the path length issue. Compat layer may break applications in other funny ways and we probably have to return e.g. ENAMETOOLONG for legacy applications if the names are too long to fit into the buffer, but I don't see any easy solution either: I wish we have bumped it in 2003 when the struct receives its first big revamp by bumping all statistic fields to 64-bit. I personally think we probably better create a new API and keep the existing one for (limited) compatibility. For instance, it may be sensible to make f_mntfromname and f_mntonname fields variable length and have the caller pass a pointer and their length. If we set an arbitrary limit, no matter it's 88, 256 or 4096, one will hit it some time. BTW. If someone wants to change statfs(2), please make sure to create reverse-compatibility shims at the same time (see lib/libc/sys/fcntl.c for an example). The statfs(2) API is used in a lot of places, especially fts(3), and breaking it either way (running new world with old kernel, or running old world with new kernel) would be a big pain to recover from. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.1 (FreeBSD) iQIcBAEBCgAGBQJUvanaAAoJEJW2GBstM+nsgoQP/0+Ulfmmmj9n9cWA0h1NxD3O a59aZXxbFtRu2SkIZprzFOL4TLnmyKEthFGmUgRSm7SH3GuaWVPBsgHTjSddYA/f vD3fBei780akT/higazmSENKR0eWqL0zENG8HJndQ0XLLcv8eeHZEFFhbUlYA4JU 4ArzoKEwsxiQ4jKB+KSFRU4QR4Raarljx6m4gQyXO6QAPEcyO035YH+bJlMSPjYg wcJZiZXmsRYsjZMhKDGeO5tIiD8R/UwOcMKsaQ/O+bwCgWtHFe5gLDKxGjMlLc9c NuhXE2/xlyBdAf3OHTlgr61dPmArQl0pyLXDUfd8K0s05FQ22bGHaSCT0FyNNG0J 55rnr30iDczVjQV1rTk9AwvsTJzACyaRrCV3zXGpxr86XwGFRta4ebMYZNuRXhdZ sLsTZWpIc3gnvOH4CiZHPmr1mbHoAY1RN9G23T5ENu2zYNJVozXhJ4NkoZkKzxUj b19qox4aKtG9QT7h5HU7R7Q64Sz2dYty8VD4OZ/azQrLGjVdI+2KUq6M3SAIRBro IAmGY62OQyz8aDVhr/Ap/N7GnV4suCZf08kgg3+oREU0a8QAxEHCDnNH4MJ9xz6v +2GpYWp0AuCFJ77XQC7IB6va1hK+PZnuOZ9yNVKTTadEwSk4GK2fQv6YwLjiyYKM PiOk31dmRfQB+3mqZ+Oj =a3fA -----END PGP SIGNATURE-----