• Al Viro's avatar
    cifs: allocate buffer in the caller of build_path_from_dentry() · f6a9bc33
    Al Viro authored
    build_path_from_dentry() open-codes dentry_path_raw().  The reason
    we can't use dentry_path_raw() in there (and postprocess the
    result as needed) is that the callers of build_path_from_dentry()
    expect that the object to be freed on cleanup and the string to
    be used are at the same address.  That's painful, since the path
    is naturally built end-to-beginning - we start at the leaf and
    go through the ancestors, accumulating the pathname.
    
    Life would be easier if we left the buffer allocation to callers.
    It wouldn't be exact-sized buffer, but none of the callers keep
    the result for long - it's always freed before the caller returns.
    So there's no need to do exact-sized allocation; better use
    __getname()/__putname(), same as we do for pathname arguments
    of syscalls.  What's more, there's no need to do allocation under
    spinlocks, so GFP_ATOMIC is not needed.
    
    Next patch will replace the open-coded dentry_path_raw() (in
    build_path_from_dentry_optional_prefix()) with calling the real
    thing.  This patch only introduces wrappers for allocating/freeing
    the buffers and switches to new calling conventions:
    	build_path_from_dentry(dentry, buf)
    expects buf to be address of a page-sized object or NULL,
    return value is a pathname built inside that buffer on success,
    ERR_PTR(-ENOMEM) if buf is NULL and ERR_PTR(-ENAMETOOLONG) if
    the pathname won't fit into page.  Note that we don't need to
    check for failure when allocating the buffer in the caller -
    build_path_from_dentry() will do the right thing.
    Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
    f6a9bc33
file.c 124 KB