On Mon, May 12, 2014 at 11:00:23PM +0800, Liu Bo wrote: > On Thu, May 08, 2014 at 07:16:19PM -0400, Zach Brown wrote: > > uncompress_inline() is silently dropping an error from > > btrfs_decompress() after testing it and zeroing the page that was > > supposed to hold decompressed data. This can silently turn compressed > > inline data in to zeros if decompression fails due to corrupt compressed > > data or memory allocation failure. > > > > I have no idea why uncompress_inline() is zeroing the page for an error > > from btrfs_decompress() but not for the earlier ENOMEM from kmalloc(). > > Can someone explain this? > > I guess that's because decompress() may have put part of real data on the page > and then bail out, and we don't want those data to be exposed to users in this > error case. > > And kmalloc() 's ENOMEM runs before that decompress(), page has whatever random > data. But we don't return any data in case of error. In the unpatched code, there's no error so a zeroed page is returned, but this would not happen after Zach's fix. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
