Bug#910074: linux-image-4.9.0-8-amd64: BTRFS data loss - kernel BUG at .../linux-4.9.110/fs/btrfs/ctree.c:3178
On Wed, Oct 03, 2018 at 09:56:13AM +0000, Michael Firth wrote:
> >
> > 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.
To find out:
cat /sys/block/your_hardware_raid_block_device/queue/rotational
If it returns "0" then you're affected by the -o ssd bug, but if it
returns "1" then there is nothing to worry about. :-) While this
issue will become obsolete when the fix is backported I'm curious to
learn if hardware RAID registers as nonrotational, so please let me
know. I suspect it will register as nonrotational, because then the
kernel will let the RAID controller merge and reorder IO as it sees
fit.
>
> 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
Oh Nice! I'm really happy to see this. Thank you Ben and kernel team!
> > 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.
Thanks.
> > 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.
The version number is a hint. Looking at the changelog for the
package, you'll see stretch released with 4.9.30-2, was updated with
security fixes in 4.9.30-2+deb9u1, was updated from upstream LTS in
4.9.47-1, etc, and is now at 4.9.110-3+deb9u6.
Cheers,
Nicholas
Reply to: