Re: off-by-one uncompressed invalid ram_bytes corruptions

[Steve Leung <sjleung@shaw.ca>]

On 06/04/2018 11:30 PM, Qu Wenruo wrote:
> 
> 
> 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.

Ok great to hear!  I'll give it a test whenver you have it.

Steve