Re: question about fs/super.c

Martin von Loewis (
Fri, 25 Apr 1997 00:09:10 +0200

> anyone knows why we do this in copy_mount_options():
[... current code deleted ...]
> shouldnt this be enough:
> if (!(page = __get_free_page(GFP_KERNEL)))
> return -ENOMEM;
> if (copy_from_user((void *) page,data,i)) {
> free_page(page);
> return -EFAULT;
> }
> ? Or is this some early-boot-maybe-bolixed situation?

My guess is that this code was just not updated when we
got exception handling. AFAIK, the history of this is:
- The mount system call does not support passing a length of the
per-fs data. This is probably a sign of its BSD history (no
offense intended, but they *do* have a strange approach to mount)
- So instead, the kernel offers to find out on its own how much
data there is, but allows for at most a page.
- The old verify_area did not support such an interface, since it
needs to know in advance how much data is available.

Since mount(2) is inherently broken in this respect and cannot be
fixed, I suggest to at least change the VFS to add the length of
the available data. The above code would then become

if (!(page = __get_free_page(GFP_KERNEL)))
return -ENOMEM;
remain=copy_from_user((void *) page,data,PAGE_SIZE)
/* the data pointer was entirely invalid */
return -EFAULT;
return PAGE_SIZE-remain;

Please note that it is possible to get less than a page: mount(8)
could copy the options to memory obtained from malloc(3), which
could be inside the last page of the vma.

Since mount(8) from util-linux passes essentially the -o argument
to the kernel, most file systems expect a null terminated string
and won't care if there is more data. Funny things might happen if
the mount options exceed a page, so file systems COULD be updated
to make sure the last byte of the valid data is '\0'.