Hi, Jan, On 2016/11/28 18:07, Jan Kara wrote: > Good catch but I don't like sprinkling checks like this into the writeback > code and furthermore we don't want to call into writeback code when block > device is in the process of being destroyed which is what would happen with > your patch. That is a bug waiting to happen... Agreed. Need another way to fix this problem. I looked through the writeback cgroup code in __filemap_fdatawrite_range(), found if we turn on CONFIG_CGROUP_WRITEBACK, a new crash will happen. Thanks, Wei > As I'm looking into the code, we need a serialization between bdev writeback > and blkdev_put(). That should be doable if we use writeback_single_inode() > for writing bdev inode instead of simple filemap_fdatawrite() and then use > inode_wait_for_writeback() in blkdev_put() but it needs some careful > thought. > > Frankly that whole idea of tearing block devices down on last close is a > major headache and keeps biting us. I'm wondering whether it is still worth > it these days... > > Honza > >> --- >> mm/filemap.c | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/mm/filemap.c b/mm/filemap.c >> index 235021e..d607677 100644 >> --- 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); >> -- >> 2.4.11 >> -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html