Bug#910074: linux-image-4.9.0-8-amd64: BTRFS data loss - kernel BUG at .../linux-4.9.110/fs/btrfs/ctree.c:3178
Hi,
> -----Original Message-----
>
> Hi Michael,
>
> On Tue, Oct 02, 2018 at 11:37:45AM +0100, Michael Firth wrote:
> >
> > After this, there was a file that was errored on the filesystem (as
> > reported by 'btrfs check'), and it seems BTRFS doesn't have any tools
> > to resolve the error. Deleting the file at the reported inode has
> > cleared the error from 'btrfs check', but I am not 100% sure that will
> > have fixed all the corruption.
> >
>
> As far as I know, if 'btrfs check' is clean then you're in the clear for any known
> issues involving the fs structure. Of course, a 'btrfs scrub' is necessary to
> check for data and metadata corruption... BTW, if you're using an ssd, make
> sure you're mounting with -o nossd, because as far as I know linux-4.9.x still
> hasn't been patched.
> P.S. that requires a full rebalance to take effect. Make up-to-date backups
> before running that rebalance...
That is good to know. I will run a "scrub" on the partition soon to check for any
other issues. I am running on a VM on top of a hardware RAID array of
spinning disks, so hopefully the SSD issue doesn't apply.
>
> > This issue looks very like the bug described at:
> >
> > https://www.spinics.net/lists/linux-btrfs/msg60984.html
> >
> > And in bug report #708509 for a much older kernel (from 2013)
> >
> > According to the BTRFS mailing list post above, there are patches
> > submitted to fix this issue (or one with the same symptoms).
> > Is there any way to easily determine if these patches are in the
> > Debian version of the V4.9.110 kernel?
>
> The last time I checked I couldn't find any btrfs-specific ones in Debian; I used
> apt-get source and expected to find a quilt series.
There was a BTRFS patch in the update that became available an hour after my
crash:
linux (4.9.110-3+deb9u5) stretch-security; urgency=high
.
.
.
* btrfs: relocation: Only remove reloc rb_trees if reloc control has been
initialized (CVE-2018-14609)
I'm not sure if that is a Debian specific patch or whether it is a Debian specific
merge from another version
>
> > If not, what is the route to get these patches incorporated? Do I need
> > to talk to the BTRFS people about getting the patches in to the stock
> > V4.9 kernel, or is this something that the Debian team would apply
> > directly?
>
> The first of the two patches from that 29 Nov 2016 linux-btrfs email appears
> to be queued for linux-4.9.119:
> https://lore.kernel.org/patchwork/patch/972419/
>
So I guess the related question that I should have asked is whether there is
information on how upstream changes are merged into the Debian kernel, and
what the likely delay between (for example) the 4.9.119 mainline kernel being
released, and the Debian version following it?
> I wasn't able to find status of the second one wrt linux-4.9.x.
Though the description is similar, I don't think patch 972419 is actually either of
the two patches referenced from that mail. I think I will ask on the BTRFS mailing
list what the current status of all of these patches is.
>
> > Kernel bug report output included below, in case it is useful.
> >
> > BTRFS may not be a filesystem that everyone uses, but I feel if it is
> > in the Debian kernel then bugs that can cause data loss should be
> > fixed if a patch already exists.
>
> In principle I agree; although I think it would be safer to coordinate with Greg
> Kroah-Harman about getting them applied upstream before importing them
> into Debian, since (afaik) we don't have any btrfs specialists working on our
> kernel...people who would know if importing one of these patches will
> introduce unintended side-effects or a rabbit hole of patches. Maybe it
> would be safer to look at the delta between btrfs in 4.9.x and 4.14.x and ask
> for backported fixes from 4.14.x to 4.9.x? (eg: more than six months of
> testing in 4.14.x, like the -o ssd bug that is still present in 4.9.x)
>
I agree with this, and with Hans's comment that because it isn't a Debian specific
issue it should be handled upstream. I guess the question comes partly from not
knowing if/how/when upstream V4.9.X kernel changes are merged into the Debian
Stretch kernel.
> Cheers,
> Nicholas
Regards
Michael
Reply to: