From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753111AbbC2PKG (ORCPT ); Sun, 29 Mar 2015 11:10:06 -0400 Received: from mail-pd0-f175.google.com ([209.85.192.175]:34175 "EHLO mail-pd0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752915AbbC2PKE (ORCPT ); Sun, 29 Mar 2015 11:10:04 -0400 Date: Sun, 29 Mar 2015 23:10:12 +0800 From: Boqun Feng To: Richard Weinberger Cc: linux-fsdevel , LKML , Al Viro , Paul Moore Subject: Re: [PATCH v2] vfs: avoid recopying file names in getname_flags Message-ID: <20150329151012.GB1477@fixme-laptop> References: <1427309152-25129-1-git-send-email-boqun.feng@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Richard, On Sun, Mar 29, 2015 at 12:13:29PM +0200, Richard Weinberger wrote: > On Wed, Mar 25, 2015 at 7:45 PM, Boqun Feng 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 > > --- > > 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, i= name)) > > +#define EMBEDDED_NAME_MAX (PATH_MAX - sizeof(struct filename)) >=20 > *confused* > EMBEDDED_NAME_MAX is currently PATH_MAX - sizeof(struct filename) >=20 > Did you mix original and new source while creating the patch? This patch is based on branch 'for-next' in Al's tree, in that repo commit b2ddab0e5324aec11620666eccc4f0ff64802131 ("kill struct filename.sepa= rate") changes EMBEDDED_NAME_MAX to (PATH_MAX - offsetof(struct filename, iname)) I put the "based-on" information in the version changing log, seems it's better to put it in the commit log to make it clearer for reviewers? Thanks, Boqun Feng >=20 > --=20 > Thanks, > //richard --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJVGBXRAAoJEEl56MO1B/q4gZEH/Rn361qsYt0LXpeElLumkWmS ysF9IuiyLIYqqEAnjzzKr5qFtxG9awOgX4Y1GIbaSR5BG3kFqrOjHEAZJudaNhrv kGPZZMa15/xt1NlZtuHk+A2kNW3iaZ22H8kFa+BmsXxjTs16T1qKvPdwdABPm2m2 UQ9Sgcu8oh6kROHtwia9njDPAbTMtfELCoKWszNiVS9wUvuuCqV7RKhlw1zY9wpk YzJp7N4c5pcBp9a6k1bSSMxwqbxvgQmBU1MEYK+fnZTuahmtaBg944bUvviF65nL aeoTmbUJb858ieQtTkx+3wJ2MdUV35PEpNM2bcWlGwVEe0M4oVxZAoSMQNXLF74= =vXv/ -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG--