[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140318123919.GA25897@thunk.org>
Date: Tue, 18 Mar 2014 08:39:19 -0400
From: tytso@....edu
To: Lukáš Czerner <lczerner@...hat.com>@thunk.org
Cc: linux-ext4@...r.kernel.org
Subject: Re: [PATCH 0/6 v2] Introduce FALLOC_FL_ZERO_RANGE flag for fallocate
On Tue, Mar 18, 2014 at 12:37:47PM +0100, Lukáš Czerner wrote:
> Ok, finally I got it. The problem is that we now have commit
>
> 97d39798f77aef626130db8590cc79195300227b ext4: delete path dealloc
> code in ext4_ext_handle_uninitialized_extents
>
> which I was not aware of before. And when merging you have used the
> same out2 label out of the function. However when creating my new
> function ext4_ext_convert_initialized_exten() so I've done the same
> thing as with ext4_ext_handle_uninitialized_extents() and freed the
> path. And since we do not set path to NULL in ext4_ext_map_blocks
> after calling ext4_ext_convert_initialized_extent() when we hit the
> condition at the out2:
>
> if (path) {
> ext4_ext_drop_refs(path);
> kfree(path);
> }
>
> we will double-free possibly destroying data from someone else. That
> is why we've seen what looked like a random memory corruption.
My bad! I remember noticing that particular semantic conflict, and I
*thought* I had fixed it up. The fixup must have gotten lost when I
was doing some patch wrangling (I was moving aronud some patch hunks
around to be the most logical with respect to the COLLAPSE RANGE, and
I must have dropped the fixup somewhere along the way).
Thanks for finding it!
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists