APPLIED/cmnt: [SRU] [B/C] [PATCH 0/1] btrfs: raid56: fix page unmapping bug

Andrea Righi andrea.righi at canonical.com
Mon Apr 1 12:29:58 UTC 2019


On Mon, Apr 01, 2019 at 12:33:45PM +0200, Kleber Souza wrote:
> On 3/28/19 6:09 PM, Andrea Righi wrote:
> > [Impact]
> > 
> > Parity page in btrfs raid56 is incorrectly unmapped, allowing to
> > easily trigger a reference counter bug on i386 causing a kernel panic.
> > 
> > The fix unmaps the right rbio pages and adds the proper kunmap() call
> > for the parity page.
> > 
> > [Test Case]
> > 
> > create a raid5 btrfs filesystem:
> >   # mkfs.btrfs -m raid5 -d raid5 /dev/sdb /dev/sdc /dev/sdd /dev/sde
> > 
> > mount it:
> >   # mount /dev/sdb /mnt
> > 
> > run btrfs scrub in a loop:
> >   # while :; do btrfs scrub start -BR /mnt; done
> > 
> > [Fix]
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3897b6f0a859288c22fb793fad11ec2327e60fcd
> > 
> > kunmap(p_page) was completely left out, so we never did an unmap for the
> > p_page and the loop unmapping the rbio page was iterating over the wrong
> > number of stripes: unmapping should be done with nr_data instead of
> > rbio->real_stripes.
> > 
> > [Regression Potential]
> > 
> > This is an upstream fix, tested on the affected platform. The bug is
> > affecting only btrfs raid5/6 users on architectures where kunamp() is
> > not a no-op (like i386). It is also a very small patch, so backport
> > changes are minimal.
> > 
> > Andrea Righi (1):
> >   btrfs: raid56: properly unmap parity page in finish_parity_scrub()
> > 
> >  raid56.c |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > 
> > 
> 
> 
> Applied to bionic/master-next and cosmic/master-next branches.
> 
> The bug report says that it affects xenial and disco as well,
> so I pinged Andrea to confirm if the same patch should be applied
> to those series too.

Patch applies cleanly also to disco/master-next and xenial/master-next
and they both compile cleanly. We can apply the same patch to both
series as well.

Thanks,
-Andrea



More information about the kernel-team mailing list