On Thu, Mar 10, 2016 at 06:37:27PM +0100, Jan Kara wrote: > Thanks for spotting the problem. The patch will fix the problem you found. > But what prevents e.g. flusher thread from trying to writeback the block > device inode while that gets invalidated at the same moment? I.e., the > problem doesn't seem to be specific to iterate_bdevs() but rather hits > anything which writes back block device inodes, right? > > Frankly it seems like a catch that mapping_cap_foo() requires block device > to be open (if mapping belongs to a block device) to be safe. The trouble > is we'd need to make inode_to_bdi() result stable while we work with the > block device inode. Christoph, do you have any idea how to cleanly achieve > that? All I'm able to come up with are ugly hacks... I think the whole idea of clearing a queue from a block device just because it's not open is the root of the problem. Or, to dive deeper into the issue our whole object model and life time rules between struct block_device, struct gendisk, struct request_queue and struct backing_dev_info are rather broken. I'd done a few attempt at sorting this out, but it's a huge task and I haven't gotten far. I think for now the patch from Rabin should be fine. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
