Fix MNAMELEN or reimplement struct statfs

[Harald Schmalzbauer]

 Hello,

first sorry for the missing thread references in the header, I'm not
subscribed to hackers at .

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20141030/f595dbe8/attachment.sig>