From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751806AbbC2KNe (ORCPT ); Sun, 29 Mar 2015 06:13:34 -0400 Received: from mail-yk0-f171.google.com ([209.85.160.171]:35110 "EHLO mail-yk0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750952AbbC2KNa (ORCPT ); Sun, 29 Mar 2015 06:13:30 -0400 MIME-Version: 1.0 In-Reply-To: <1427309152-25129-1-git-send-email-boqun.feng@gmail.com> References: <1427309152-25129-1-git-send-email-boqun.feng@gmail.com> Date: Sun, 29 Mar 2015 12:13:29 +0200 Message-ID: Subject: Re: [PATCH v2] vfs: avoid recopying file names in getname_flags From: Richard Weinberger To: Boqun Feng Cc: linux-fsdevel , LKML , Al Viro , Paul Moore Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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, 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