From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btZNr-0007Ob-IG for qemu-devel@nongnu.org; Mon, 10 Oct 2016 08:08:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btZNn-0000yY-QC for qemu-devel@nongnu.org; Mon, 10 Oct 2016 08:08:42 -0400 Received: from 14.mo6.mail-out.ovh.net ([46.105.56.113]:37244) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btZNn-0000y2-Jg for qemu-devel@nongnu.org; Mon, 10 Oct 2016 08:08:39 -0400 Received: from player738.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo6.mail-out.ovh.net (Postfix) with ESMTP id 73ECD3D570 for ; Mon, 10 Oct 2016 14:08:38 +0200 (CEST) Date: Mon, 10 Oct 2016 14:08:33 +0200 From: Greg Kurz Message-ID: <20161010140833.726323f7@bahia> In-Reply-To: References: <57fb706a.a8c8c20a.2886d.5bd5@mx.google.com> <20161010132051.7e1b3623@bahia> <20161010132833.0b5b26f7@bahia> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] 9pfs: fix memory leak in v9fs_xattrcreate List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Li Qiang Cc: qemu-devel@nongnu.org, Li Qiang On Mon, 10 Oct 2016 19:54:01 +0800 Li Qiang wrote: > I think the 'xattr_fidp->fs.xattr.name' will not leak as the > 'v9fs_string_copy' will first free the fs.xattr.name. > Indeed! > Thanks. > Cheers. -- Greg > 2016-10-10 19:28 GMT+08:00 Greg Kurz : > > > On Mon, 10 Oct 2016 13:20:51 +0200 > > Greg Kurz wrote: > > > > > On Mon, 10 Oct 2016 03:41:38 -0700 > > > Li Qiang wrote: > > > > > > > From: Li Qiang > > > > > > > > The 'fs.xattr.value' field in V9fsFidState object doesn't consider the > > > > situation that this field has been allocated previously. Every time, it > > > > will be allocated directly. This leads a host memory leak issue. This > > > > patch fix this. > > > > > > > > Signed-off-by: Li Qiang > > > > --- > > > > > > I'll add to the changelog that this may happen if the client sends a > > > Txattrcreate message with the same fid number before the fid was > > > clunked. > > > > > > Reviewed-by: Greg Kurz > > > > > > > Oops I may have answered to fast... what about xattr_fidp->fs.xattr.name ? > > It looks like it is leaked the same way... > > > > > > hw/9pfs/9p.c | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > > > > index 8751c19..e4040dc 100644 > > > > --- a/hw/9pfs/9p.c > > > > +++ b/hw/9pfs/9p.c > > > > @@ -3282,6 +3282,7 @@ static void v9fs_xattrcreate(void *opaque) > > > > xattr_fidp->fs.xattr.flags = flags; > > > > v9fs_string_init(&xattr_fidp->fs.xattr.name); > > > > v9fs_string_copy(&xattr_fidp->fs.xattr.name, &name); > > > > + g_free(xattr_fidp->fs.xattr.value); > > > > xattr_fidp->fs.xattr.value = g_malloc0(size); > > > > err = offset; > > > > put_fid(pdu, file_fidp); > > > > > > >