On Sat, 26 Nov 2016 10:06:22 +0800 Wei Fang <fangwei1@xxxxxxxxxx> wrote: > ->bd_disk is assigned to NULL in __blkdev_put() when no one is holding > the bdev. After that, ->bd_inode still can be touched in the > blockdev_superblock->s_inodes list before the final iput. So iterate_bdevs() > can still get this inode, and start writeback on mapping dirty pages. > ->bd_disk will be dereferenced in mapping_cap_writeback_dirty() in this > case, and a NULL dereference crash will be triggered: > > Unable to handle kernel NULL pointer dereference at virtual address 00000388 > ... > [<ffff8000004cb1e4>] blk_get_backing_dev_info+0x1c/0x28 > [<ffff8000001c879c>] __filemap_fdatawrite_range+0x54/0x98 > [<ffff8000001c8804>] filemap_fdatawrite+0x24/0x2c > [<ffff80000027e7a4>] fdatawrite_one_bdev+0x20/0x28 > [<ffff800000288b44>] iterate_bdevs+0xec/0x144 > [<ffff80000027eb50>] sys_sync+0x84/0xd0 > > Since mapping_cap_writeback_dirty() is always return true about > block device inodes, no need to check it if the inode is a block > device inode. > > ... > > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -334,8 +334,9 @@ int __filemap_fdatawrite_range(struct address_space *mapping, loff_t start, > .range_end = end, > }; > > - if (!mapping_cap_writeback_dirty(mapping)) > - return 0; > + if (!sb_is_blkdev_sb(mapping->host->i_sb)) > + if (!mapping_cap_writeback_dirty(mapping)) > + return 0; > > wbc_attach_fdatawrite_inode(&wbc, mapping->host); > ret = do_writepages(mapping, &wbc); This seems wrong to me. If __blkdev_put() has got so deep into the release process as to be zeroing out ->bd_disk then the blockdev's inode shouldn't be visible to iterate_bdevs()? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>