All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Steve Leung <sjleung@shaw.ca>, linux-btrfs@vger.kernel.org
Subject: Re: off-by-one uncompressed invalid ram_bytes corruptions
Date: Tue, 5 Jun 2018 13:30:50 +0800	[thread overview]
Message-ID: <5eac8b95-b6cd-87ef-2f16-573be326ef37@gmx.com> (raw)
In-Reply-To: <87lgc2mrud.fsf@shaw.ca>


[-- Attachment #1.1: Type: text/plain, Size: 1461 bytes --]



On 2018年05月29日 22:58, Steve Leung wrote:
> Qu Wenruo <quwenruo.btrfs@gmx.com> writes:
> 
>> On 2018年05月28日 11:47, Steve Leung wrote:
>>> On 05/26/2018 06:57 PM, Qu Wenruo wrote:
>>>>
>>>>
[snip]
>> Still nope.
>> What about encrypt it and upload it to some public storage provider like
>> google drive/dropbox?
> 
> Ok, uploaded to Google Drive.  You'll need to request access to it.
> 
>   https://drive.google.com/file/d/16NM1NVoMVgkJ_JiePi8VfAzit5_Onz2H/view?usp=sharing
> 
> sha256sum for the file should be:
> 
>   ea0abc21fcbc3a71c68b7307d57b26763ac711bd3437a60e32db3144facfeb3f
Sorry for the slow reply.

After all the testing, the result is a little surprising.

It's indeed *CORRUPTED*! And tree-checker code exposed it.

It's just btrfs-progs and kernel print-tree code doesn't use correct
ram_bytes to output, thus pretty tricky to expose.

The problem is the ram_bytes of that inlined extent, it's indeed larger
than it should, just by one byte.

I'm not completely sure how it's happened, but according to the
timestamp it's 4 years ago and I think some kernel off-by-one error
happens and fixed.

And current kernel can handle it pretty well without reading out the
last byte.
However it's still a corruption.

Although it's not a big problem, and can be fixed easily.
I'll submit a btrfs-progs patch to allow btrfs-check to fix in this week.

Thanks,
Qu

> Thanks!
> 
> Steve
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2018-06-05  5:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-18  5:23 off-by-one uncompressed invalid ram_bytes corruptions Steve Leung
2018-05-18  5:49 ` Qu Wenruo
2018-05-18  9:42   ` james harvey
2018-05-18  9:56     ` Qu Wenruo
2018-05-19 23:40   ` Steve Leung
2018-05-20  1:02     ` Qu Wenruo
2018-05-20 20:43       ` Steve Leung
2018-05-21  1:07         ` Qu Wenruo
2018-05-26 14:06           ` Steve Leung
2018-05-27  0:57             ` Qu Wenruo
2018-05-28  3:47               ` Steve Leung
2018-05-28  5:11                 ` Qu Wenruo
2018-05-29 14:58                   ` Steve Leung
2018-06-05  5:30                     ` Qu Wenruo [this message]
2018-06-06  4:06                       ` Steve Leung
2018-05-29 18:49           ` Hans van Kranenburg
2018-06-05  5:24             ` Qu Wenruo

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=5eac8b95-b6cd-87ef-2f16-573be326ef37@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=sjleung@shaw.ca \
    /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.