[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEkB2ERBSfAad=EChgH+X9vrPGjH8_sBvb2W9ur8n1Fnh_NuUg@mail.gmail.com>
Date: Wed, 2 Oct 2019 11:59:40 -0500
From: Navid Emamdoost <navid.emamdoost@...il.com>
To: David Sterba <dsterba@...e.cz>
Cc: Markus Elfring <Markus.Elfring@....de>,
"Gustavo A. R. Silva" <gustavo@...eddedor.com>,
Deepa Dinamani <deepa.kernel@...il.com>,
Jeff Layton <jlayton@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
David Sterba <dsterba@...e.com>,
Navid Emamdoost <emamd001@....edu>, Kangjie Lu <kjlu@....edu>,
Stephen McCamant <smccaman@....edu>,
linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH v2] fs: affs: fix a memory leak in affs_remount
Thanks David,
On Wed, Oct 2, 2019 at 4:22 AM David Sterba <dsterba@...e.cz> wrote:
>
> On Mon, Sep 30, 2019 at 04:01:10PM -0500, Navid Emamdoost wrote:
> > In affs_remount if data is provided it is duplicated into new_opts.
> > The allocated memory for new_opts is only released if pare_options fail.
> > The release for new_opts is added.
>
> A variable that is allocated and freed without use should ring a bell to
> look closer at the code. There's a bit of history behind new_options,
> originally there was save/replace options on the VFS layer so the 'data'
> passed must not change (thus strdup), this got cleaned up in later
> patches. But not completely.
>
> There's no reason to do the strdup in cases where the filesystem does
> not need to reuse the 'data' again, because strsep would modify it
> directly.
>
> So new_opts should be removed.
I will send a new patch with the unused variable removed.
--
Navid.
Powered by blists - more mailing lists