All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <clm@fb.com>
To: Paul Jones <paul@pauljones.id.au>,
	Zygo Blaxell <ce3g8jdj@umail.furryterror.org>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs rare silent data corruption with kernel data leak
Date: Thu, 22 Sep 2016 16:42:06 -0400	[thread overview]
Message-ID: <c47741e6-76d4-0900-e126-2be4862233db@fb.com> (raw)
In-Reply-To: <ME1PR01MB13788B5A79BF88786A1D571D9EF60@ME1PR01MB1378.ausprd01.prod.outlook.com>

On 09/21/2016 07:14 AM, Paul Jones wrote:
>> -----Original Message-----
>> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
>> owner@vger.kernel.org] On Behalf Of Zygo Blaxell
>> Sent: Wednesday, 21 September 2016 2:56 PM
>> To: linux-btrfs@vger.kernel.org
>> Subject: btrfs rare silent data corruption with kernel data leak
>>
>> Summary:
>>
>> There seem to be two btrfs bugs here: one loses data on writes, and the
>> other leaks data from the kernel to replace it on reads.  It all happens after
>> checksums are verified, so the corruption is entirely silent--no EIO errors,
>> kernel messages, or device event statistics.
>>
>> Compressed extents are corrupted with kernel data leak.  Uncompressed
>> extents may not be corrupted, or may be corrupted by deterministically
>> replacing data bytes with zero, or may not be corrupted.  No preconditions
>> for corruption are known.  Less than one file per hundred thousand seems to
>> be affected.  Only specific parts of any file can be affected.
>> Kernels v4.0..v4.5.7 tested, all have the issue.

Zygo, could you please bounce me your original email?  Somehow exchange 
ate it.

If you're seeing this databases that use fsync, it could be related to 
the fsync fix I put into the last RC.  On my boxes it caused crashes, 
but memory corruptions aren't impossible.

Any chance you can do a controlled experiment to rule out compression?

-chris

  parent reply	other threads:[~2016-09-22 20:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-21  4:55 btrfs rare silent data corruption with kernel data leak Zygo Blaxell
2016-09-21 11:14 ` Paul Jones
2016-09-21 13:02   ` Zygo Blaxell
2016-09-22 17:49     ` Kai Krakow
2016-09-22 19:35       ` Christoph Anton Mitterer
2016-09-22 20:42   ` Chris Mason [this message]
2016-09-24  2:28     ` Zygo Blaxell
2016-09-28 16:18     ` [PATCH][RFC] btrfs rare silent data corruption with kernel data leak (updated, preliminary patch) Zygo Blaxell
2016-10-08  6:10 ` btrfs rare silent data corruption with kernel data leak (updated with some bisection results) Zygo Blaxell
2016-10-08  7:02   ` Zygo Blaxell
2016-10-09  4:11     ` Zygo Blaxell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c47741e6-76d4-0900-e126-2be4862233db@fb.com \
    --to=clm@fb.com \
    --cc=ce3g8jdj@umail.furryterror.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=paul@pauljones.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.