Fix MNAMELEN or reimplement struct statfs

[Konstantin Belousov]

On Thu, Nov 21, 2013 at 09:40:28AM -0800, Doug Ambrisko wrote:
> On Wed, Nov 20, 2013 at 09:55:31AM +0200, Konstantin Belousov wrote:
> | On Tue, Nov 19, 2013 at 09:42:16AM -0800, Doug Ambrisko wrote:
> | > I was talking about the more general case since the system tries to keep
> | > the path in the stat structure.  My prior approach which had more issues
> | > was to modify the stat structure of which I was pointed to NetBSD and their
> | > change to statvfs which doesn't really solve the problem.  They don't
> | > have the check to see if the mount is longer then VFS_MNAMELEN (in their case)
> | > and just truncate things.
> | > 
> | > If we are just talking about adding it to the mount structure that
> | > would be okay since it isn't exposed to user land.  I can add that.
> |
> | Yes, this is exactly what I mean.  Add a struct mount field, and use
> | it for kernel only.  In fact, it only matters for sys_unmount() and
> | kern_jail.c, other locations in kernel use the path for warnings, and
> | this could be postponed if you prefer to minimize the patch.
> 
> Okay, I went through all of the occurances and compile tested (except
> for #DEBUG).  I united a few things but should do more once I get
> consensus on the approach.  I found a few spots that should be updated as
> well and made the length check more consistant.  Some were doing >= and others
> >.  So this should be better, however, a lot larger.  On the plus side
> when we figure out how to return the longer path length to user land
> that can be more flexible since the kernel is tracking the longer length.
> Probably things to note are changes in:
> 	ZFS to mount snapshot
> 	cd9660 for symlinks
> 	fuse to return full path
> 	jail to check statfs and mount
> 	mount/umount to save and check full path
> 	mountroot to save new field for full path
> 	
> Just in case it doesn't make it in email the full patch is at:
> 	http://people.freebsd.org/~ambrisko/mount_bigger.patch
> 
Yes, this is closer to the patch I can agree with :).

Two notes, one was already made, about off by one.

Second is, I suggest to make the mnt_path member a char *. Usually, the
mount point path length is quite short, so 1024 bytes for the buffer is
excessive. You can allocate exact needed buffer, which would save in
around 10KB of kernel memory even for relatively modest amount of 10
mounts.

For additional cleverness, mnt_path could point to f_mntonname when
the length is less than MNAMELEN.  Since mp deallocation is centralized,
code for the trick should be not too hard.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20131122/1d94b22d/attachment.sig>