Date: Thu, 30 Oct 2014 16:58:04 +0100 From: Harald Schmalzbauer <h.schmalzbauer@omnilan.de> To: freebsd-hackers@freebsd.org Subject: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <5452600C.5030003@omnilan.de> In-Reply-To: <20140415233133.GA14686@ambrisko.com> References: <20140415233133.GA14686@ambrisko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Hello, first sorry for the missing thread references in the header, I'm not subscribed to hackers@. bdrewery@ pointed me to this discussion in response to my question to stable@ (http://lists.freebsd.org/pipermail/freebsd-fs/2014-August/019949.html) Last promising post I found: > |/ > I have a new patch at: > /|/ > http://people.freebsd.org/~ambrisko/mount_bigger_2.patch <http://people.freebsd.org/%7Eambrisko/mount_bigger_2.patch>; > /|/ > that I tested against head. This should be pretty close to commiting > /|/ > unless people find some issues with it. > /|/ > /|/ In sys/kern/vfs_mount.c: > /|/ + mp->mnt_path = malloc(strlen(fspath), M_MOUNT, M_WAITOK); > /|/ + strlcpy((char *)mp->mnt_path, fspath, strlen(fspath)); > /|/ > /|/ This always strips the last byte off the fspath. > /|/ > /|/ I like that this only touches the kernel, so it does not break anything > /|/ regarding mount/umount of filesystems with short paths, including > /|/ (NFS) filesystems that do not respond. > /|/ > /|/ The patch does not enlarge f_mntfromname which may be a problem for > /|/ nullfs. It is certainly a step forwards for poudriere but [ENAMETOOLONG] > /|/ errors could still occur in more extreme situations. > / > Good point on nullfs. I'll look at fixing that. To do that I'm > changing mnt_path to mnt_topath so then I can have a mnt_frompath. > I'll add nullfs to my test cases. I'll need to run through the uses > of f_mntfromname. It was pretty easy with f_mntonname since it was > only allocated in one place just used a bunch of other place. I assume > that mount root would be short. Thanks a lot so far for working hard on that problem! Is there anything newer than "mount_bigger_2.patch", which considers potential nullfs problems? I'm heavily using nullfs (without poudriere), but I'd give it a try on my rather lightly loaded local 10.1 storage box – almost all snapshots are useless, can't access them in case of the case; which happens frequently :-( Would I have to expect any nullfs regressions with the april (mount_bigger_2) patch?? Thanks, -Harry [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlRSYAwACgkQLDqVQ9VXb8ir2wCferAaRr0Zc86cFqifNQDc3+6U 9ysAoMeuk84ezCMsllfM6SHRu7ojUJsG =JLEc -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5452600C.5030003>