Re: [PATCH -V14 05/11] vfs: Support null pathname in readlink

From: Nick Piggin
Date: Wed Jul 07 2010 - 11:27:15 EST


On Tue, Jun 15, 2010 at 10:42:55PM +0530, Aneesh Kumar K.V wrote:
> From: NeilBrown <neilb@xxxxxxx>
>
> This enables to use readlink to get the link target name
> from a file descriptor point to the link. This can be used
> with open_by_handle syscall that returns a file descriptor for a link.
> We can then use this file descriptor to get the target name.
>
> Signed-off-by: NeilBrown <neilb@xxxxxxx>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxxxxxxx>
> ---
> fs/stat.c | 30 ++++++++++++++++++++++--------
> 1 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/fs/stat.c b/fs/stat.c
> index c4ecd52..49b95a7 100644
> --- a/fs/stat.c
> +++ b/fs/stat.c
> @@ -284,26 +284,40 @@ SYSCALL_DEFINE2(newfstat, unsigned int, fd, struct stat __user *, statbuf)
> SYSCALL_DEFINE4(readlinkat, int, dfd, const char __user *, pathname,
> char __user *, buf, int, bufsiz)
> {
> - struct path path;
> - int error;
> + int error = 0;
> + struct path path, *pp;
> + struct file *file = NULL;
>
> if (bufsiz <= 0)
> return -EINVAL;
>
> - error = user_path_at(dfd, pathname, 0, &path);
> + if (pathname == NULL && dfd != AT_FDCWD) {
> + file = fget(dfd);
> +
> + if (file)
> + pp = &file->f_path;
> + else
> + error = -EBADF;
> + } else {
> + error = user_path_at(dfd, pathname, 0, &path);
> + pp = &path;
> + }

This (and all the others) is really ugly overloading of syscall
arguments IMO, and the changelog is seriously lacking for such changes.

This also changes the the syscall API of existing calls; from reading
the path at NULL, to switching to a completely different syscall.
Perhaps you're assuming nobody relies on SIGSEGV / mmapped NULL address
there, but even then you surely need to document the changed semantics
somewhere (and document the new syscall semantics properly).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/