All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard.weinberger@gmail.com>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>, Paul Moore <pmoore@redhat.com>
Subject: Re: [PATCH v2] vfs: avoid recopying file names in getname_flags
Date: Sun, 29 Mar 2015 12:13:29 +0200	[thread overview]
Message-ID: <CAFLxGvzBgwA0UB6hdAetoBWwtE3DSf9PhH2MSj2jn6kddLCxwg@mail.gmail.com> (raw)
In-Reply-To: <1427309152-25129-1-git-send-email-boqun.feng@gmail.com>

On Wed, Mar 25, 2015 at 7:45 PM, Boqun Feng <boqun.feng@gmail.com> wrote:
> In the current implementation of getname_flags, a file name in the
> user-space will be recopied if it takes more space that
> EMBEDDED_NAME_MAX, however, at this moment, EMBEDDED_NAME_MAX bytes of
> the file name are already copied into kernel address space, the only
> reason why the recopy is needed is that "kname", which points to the
> string of the file name, needs to be relocated.
>
> And the recopy can be avoided if we change the memory layout of the
> `names_cachep` allocation. By putting `struct filename` at the tail of
> the allocation instead of the head, relocation of kname is avoided.
> Once putting the struct at the tail, each byte in the user space will be
> copied only one time, so the recopy is avoided.
>
> Of course, other functions aware of the layout of the `names_cachep`
> allocation, i.e., getname_kernel and putname also need to be modified to
> adapt to the new layout.
>
> Since we change the layout of `names_cachep` allocation, in order to
> figure out whether kname and the struct are separate, we now need to
> check whether the file name string starts at the address
> EMBEDDED_NAME_MAX bytes before the address of the struct.  As a result,
> `iname`, which points the end of `struct filename`, is not needed
> anymore.
>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> ---
> v1 --> v2:
> Rebase the patch onto the for-next branch of Al's vfs repo.
>
>
>  fs/namei.c         | 45 ++++++++++++++++++++++++++++-----------------
>  include/linux/fs.h |  1 -
>  2 files changed, 28 insertions(+), 18 deletions(-)
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 7a11ec1..6d04029 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -119,7 +119,7 @@
>   * PATH_MAX includes the nul terminator --RR.
>   */
>
> -#define EMBEDDED_NAME_MAX      (PATH_MAX - offsetof(struct filename, iname))
> +#define EMBEDDED_NAME_MAX      (PATH_MAX - sizeof(struct filename))

*confused*
 EMBEDDED_NAME_MAX is currently PATH_MAX - sizeof(struct filename)

Did you mix original and new source while creating the patch?

-- 
Thanks,
//richard

  parent reply	other threads:[~2015-03-29 10:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-25 18:45 [PATCH v2] vfs: avoid recopying file names in getname_flags Boqun Feng
2015-03-29  4:27 ` Boqun Feng
2015-03-29 10:14   ` Richard Weinberger
2015-03-29 15:23     ` Boqun Feng
2015-04-07  8:38   ` Boqun Feng
2015-04-11 23:56     ` Al Viro
2015-04-12  1:13       ` Al Viro
2015-04-13  7:34         ` Boqun Feng
2015-04-17 12:35         ` Is it OK to export symbols 'getname' and 'putname'? Boqun Feng
2015-04-18  0:20           ` Boqun Feng
2015-04-20 15:55           ` Jan Kara
2015-04-22  2:38             ` Boqun Feng
2015-04-22  5:50             ` Christoph Hellwig
2015-04-23  5:32               ` Boqun Feng
2015-04-13  6:33       ` [PATCH v2] vfs: avoid recopying file names in getname_flags Boqun Feng
2015-03-29 10:13 ` Richard Weinberger [this message]
2015-03-29 15:10   ` Boqun Feng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFLxGvzBgwA0UB6hdAetoBWwtE3DSf9PhH2MSj2jn6kddLCxwg@mail.gmail.com \
    --to=richard.weinberger@gmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmoore@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.