On Thu 26-01-17 22:15:06, Dan Williams wrote: > On Thu, Jan 26, 2017 at 9:45 AM, Jan Kara <jack@xxxxxxx> wrote: > > Hello, > > > > this patch series attempts to solve the problems with the life time of a > > backing_dev_info structure. Currently it lives inside request_queue structure > > and thus it gets destroyed as soon as request queue goes away. However > > the block device inode still stays around and thus inode_to_bdi() call on > > that inode (e.g. from flusher worker) may happen after request queue has been > > destroyed resulting in oops. > > > > This patch set tries to solve these problems by making backing_dev_info > > independent structure referenced from block device inode. That makes sure > > inode_to_bdi() cannot ever oops. The patches are lightly tested for now > > (they boot, basic tests with adding & removing loop devices seem to do what > > I'd expect them to do ;). If someone is able to reproduce crashes on bdi > > when device goes away, please test these patches. > > This survives a several runs of the libnvdimm unit tests which stress > del_gendisk() and blk_cleanup_queue(). I'll keep testing since the > failure was intermittent, but this is looking good. Thanks for testing! > > I'd also appreciate if people had a look whether the approach I took looks > > sensible. > > Looks sensible, just the kref comment. > > I also don't see a need to try to tag on the bdi device name reuse > into this series. I'm wondering if we can handle that separately with > device_rename(bdi->dev, ...) when we know scsi is done with the old > bdi but it has not finished being deleted Do you mean I should not speak about it in the changelog? The problems I have are not as much with reusing device *name* here (and resulting sysfs conflicts) but rather a major:minor number pair which results in reusing block device inode and we are not prepared for that since the bdi associated with that inode may be already unregistered and reusing it would be difficult. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
