On Mon, Jul 11, 2016 at 06:54:02PM -0400, Chris Mason wrote: > On Mon, Jul 11, 2016 at 03:48:38PM -0700, Liu Bo wrote: > > On Mon, Jul 11, 2016 at 02:27:39PM -0400, Chris Mason wrote: > > > > > > > > > On 07/11/2016 01:39 PM, Liu Bo wrote: > > > > eb->io_pages is set in read_extent_buffer_pages(). > > > > > > > > In case of readpage failure, for pages that have been added to bio, > > > > it calls bio_endio and later readpage_io_failed_hook() does the work. > > > > > > > > When this eb's page (couldn't be the 1st page) fails to add itself to > > > > bio > > > > due to failure in merge_bio(), it cannot decrease eb->io_pages via > > > > bio_endio, > > > > and ends up with a memory leak eventually. > > > > > > > > This lets __do_readpage propagate errors to callers and adds the > > > > 'atomic_dec(&eb->io_pages)'. > > > > > > Thanks for looking at this Liu, how is it currently being tested? > > > > I have a btrfs disk image which was corrupted by btrfs-corrupt-block > > tool, in that image, the chunk tree's content has been removed while the > > chunk node can be read from read successfully, so we'd get -EIO when > > trying to read tree root's node since __btrfs_map_block() would fail to > > find the right item in chunk mapping_tree. Thus, we can test our error > > handling path in read_extent_buffer_pages(). > > Fantastic. Can you please make this an xfstest, maybe along with a dm-flakey? > as the second phase?
Sure, this depends on a btrfs-corrupt-block patch, which I've not sent out, I'll try to work out a xfstests case :) Btw, I'm also planning to add this into our fuzz images of btrfs-progs. Thanks, -liubo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
