Currently the filestsystem-specific mount arguments are copied to/from
userspace by the filesystem-specific VFS_MOUNT() code.  The length of
the data is only known to the filessytem code.

This is a major problem in several cases:
1) Calls to mount from within the kernel (eg from compat code).
2) Programs specifying MNT_GETARGS have no easy way of stopping a buffer
   overrun.

Moving the copyin/out to the sys_mount code would solve (1), but the
code has no way of determining the valid length.

Ideally the mount library routine and system call need updating to
pass the buffer length through - which can then be passed through the
VFS_MOUNT call.   However this would be cause massive compatibility
problems, especialy in the short term.

Adding a length parameter to 'struct vfsops' would allow the existing
mount call to be used, but would cause problems with any filesystems
that support multiple versions of the mount arguments.

There is also the possibility of filesystems that support some form
of variable length mount arguments.

I'm beginning to think that both changes are needed:
1) Add a new mount system call and library function that passes the
   length of the 'data' buffer into the kernel (and returns it for
   MNT_GETARGS).
2) Default the buffer size to that from 'struct vfsops' when none
   provided.

The buffer size probably needs bounding inside the sys_mount code (for
sanity reasons) - but the limit could be 64k+

It would also be useful to modify some fs to not have pointers to other
userspace buffers inside the mount args (which umapfs and nfs seem to do,
the former for no good reason at all).

Changing the current filesystems isn't hard, I'd also add the 'data length'
parameter at the start of 'struct vfsops' - where it would replace a
pointer which can be detected to absolutely stop an old loadable module
running.

Any thoughts before I change another vital kernel interface ?

	David

-- 
David Laight: david@l8s.co.uk