[3.8.y.z extended stable] Patch "ext4: fix premature freeing of partial clusters split across leaf blocks" has been added to staging queue

Eric Whitney enwlinux at gmail.com
Fri Apr 18 21:32:54 UTC 2014


* tytso at mit.edu <tytso at mit.edu>:
> On Fri, Apr 18, 2014 at 10:23:27AM -0700, Kamal Mostafa wrote:
> > On Thu, 2014-04-17 at 16:30 -0700, Kamal Mostafa wrote:
> > > This is a note to let you know that I have just added a patch titled
> > > 
> > >     ext4: fix premature freeing of partial clusters split across leaf blocks
> > > 
> > > to the linux-3.8.y-queue branch of the 3.8.y.z extended stable tree 
> > 
> > This patch won't cleanly apply to 3.8 without a prerequisite that has
> > now been dropped from the queue (ext4: make punch hole code path work
> > with bigalloc).
> > 
> > So this patch (ext4: fix premature freeing) will also be dropped from
> > the 3.8-stable queue, unless one of the ext4 folks would like to provide
> > a backport which applies to 3.8-stable's fs/ext4/extents.c[0], or advice
> > about what that "if partial_cluster" line should look like when all is
> > said and done.
> 
> I believe the problem which this patches is trying to address only
> happens if punch_hole is enabled for bigalloc. (That is, it should
> never happen if we are just truncating the file), so this should be
> OK.
> 
> Eric, can you confirm?
> 

Dropping this patch from Ubuntu's 3.8 stable queue is fine.  It fixes a bug
introduced during the 3.10 release cycle that can be triggered by
truncation as well as hole punching on bigalloc file systems (see d23142c627
upstream).

By inspection, the relevant code in 3.8 contains an expression -
ex >= EXT_FIRST_EXTENT(eh) - that should be equivalent in effect to the one
added by my patch.  Removal of that expression by d23142c627 caused the bug.

The xfstests that exposed the bug during 3.14 regression, generic/311 and
shared/298, did not exist at the time of the 3.8 or 3.10 releases.  I built
a 3.8 kernel and ran those tests on it - they both passed as expected.

Please let me know if you have any more questions.

Eric







More information about the kernel-team mailing list