[Top] [All Lists]

Re: [PATCH] xfs: fix memory leak in xfs_dir2_node_removename

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: [PATCH] xfs: fix memory leak in xfs_dir2_node_removename
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Fri, 27 Sep 2013 12:55:59 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <5245C4FA.7010208@xxxxxxx>
References: <20130927130140.640252809@xxxxxxx> <5245B5E5.7000206@xxxxxxxxxxx> <5245C4FA.7010208@xxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
On 9/27/13 12:48 PM, Mark Tinguely wrote:
> On 09/27/13 11:44, Eric Sandeen wrote:
>> On 9/27/13 8:01 AM, Mark Tinguely wrote:
>>> Free the memory pointed to by state before returning on error from
>>> xfs_dir2_node_removename.c
>>> Signed-off-by: Mark Tinguely<tinguely@xxxxxxx>
>>> ---
>>> Found by Coverity (134681) in userspace, same patch applies there
>>> also.
>> Heh, looks like that one has been around since the dawn of time, thanks.
>> Reviewed-by: Eric Sandeen<sandeen@xxxxxxxxxx>
>> how do we handle the matching userspace fixes, separate patch to
>> be explicit?  Wait for the next syncup?
>> Thanks,
>> -Eric
> <patch delete>
> Good question.
> The user space should be kept up to date with the kernel.
> Since the patches will be identical except the directory name, I was hoping 
> to submit one copy. But I am not trying to invent a policy, just being lazy.
> --Mark.

Was just an offhanded question; it'd just be good to know what we all expect.

I suppose that it could depend on the severity of the flaw; a minor leak before 
isn't a big deal and could wait for a global sync-up; a data corruption fix 
need to be quickly merged to both trees.


<Prev in Thread] Current Thread [Next in Thread>