On Mon, Nov 28, 2016 at 05:27:10PM +0500, Roman Mamedov wrote: > On Mon, 28 Nov 2016 00:03:12 -0500 > Zygo Blaxell <[email protected]> wrote: > > > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c > > index 8e3a5a2..b1314d6 100644 > > --- a/fs/btrfs/inode.c > > +++ b/fs/btrfs/inode.c > > @@ -6803,6 +6803,12 @@ static noinline int uncompress_inline(struct > > btrfs_path *path, > > max_size = min_t(unsigned long, PAGE_SIZE, max_size); > > ret = btrfs_decompress(compress_type, tmp, page, > > extent_offset, inline_size, max_size); > > + WARN_ON(max_size > PAGE_SIZE); > > + if (max_size < PAGE_SIZE) { > > + char *map = kmap(page); > > + memset(map + max_size, 0, PAGE_SIZE - max_size); > > + kunmap(page); > > + } > > kfree(tmp); > > return ret; > > } > > Wasn't this already posted as: > > btrfs: fix silent data corruption while reading compressed inline extents > https://patchwork.kernel.org/patch/9371971/ > > but you don't indicate that's a V2 or something, and in fact the patch seems > exactly the same, just the subject and commit message are entirely different. > Quite confusing.
The previous commit message discussed the related hole-creation bug, including a reproducer; however, this patch does not fix the hole-creation bug and was never intended to. Despite my follow-up clarification, reviewers got distracted by the hole-creation bug discussion and didn't recover, so the patch didn't go anywhere. This patch only fixes _reading_ the holes after they are created, and the new commit message and subject line state that much more clearly. The patch didn't change, so I didn't add 'v2'. There's no 'v1' with the same title, so I thought a 'v2' tag would be more confusing than just starting over. The hole-creation bug is a very old, low-urgency issue. btrfs filesystems in the field have the buggy holes already, and have been creating new ones from 2009(*) to the present. I had to ask a few people before I found one who know whether it was even a bug, or intentional behavior from the beginning. (*) 2009 is the oldest commit date I can find that introduces a change which would only be necessary in the presence of the hole-creation bug. I have not been able to test kernels before 2012 because they crash while running my reproducer. > -- > With respect, > Roman >
signature.asc
Description: Digital signature
