| Message ID | 20210830212538.148729-1-mcgrof@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | block: first batch of add_disk() error handling conversions | expand |
On 2021/08/31 6:25, Luis Chamberlain wrote: > Jens, > > I think this first set is ready, but pending review of just two patches: > > * mmc/core/block > * dm > > All other patches have a respective Reviewed-by tag. The above two > patches were integrated back into the series once I understood > Christoph's concerns, and adjusted the patch as such. > > This goes rebased onto your for-next as of today. If anyone wants to > explore the pending full set this is up on my linux-next branch > 20210830-for-axboe-add-disk-error-handling-next [0]. Are the changes by add_disk() made atomically against the caller? If there is a moment where "struct block_device_operations"->open can be called when add_disk() might still fail, how is it protected from the kfree() path? > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20210830-for-axboe-add-disk-error-handling-next > > Luis Chamberlain (8): > scsi/sd: add error handling support for add_disk() > scsi/sr: add error handling support for add_disk() > nvme: add error handling support for add_disk() > mmc/core/block: add error handling support for add_disk() > md: add error handling support for add_disk() > dm: add add_disk() error handling > loop: add error handling support for add_disk() > nbd: add error handling support for add_disk() > > drivers/block/loop.c | 9 ++++++++- > drivers/block/nbd.c | 6 +++++- > drivers/md/dm.c | 4 +++- > drivers/md/md.c | 7 ++++++- > drivers/mmc/core/block.c | 7 ++++++- > drivers/nvme/host/core.c | 9 ++++++++- > drivers/scsi/sd.c | 6 +++++- > drivers/scsi/sr.c | 5 ++++- > 8 files changed, 45 insertions(+), 8 deletions(-) >
On Wed, Sep 01, 2021 at 01:19:44PM +0900, Tetsuo Handa wrote: > Are the changes by add_disk() made atomically against the caller? > If there is a moment where "struct block_device_operations"->open can be > called when add_disk() might still fail, how is it protected from the > kfree() path? The new add_disk is structured so tht it won't fail after the block device inode is hashed. That is, the last possible failure is before ->open can be called.