| Message ID | 20211015235219.2191207-7-mcgrof@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | block: add_disk() error handling stragglers | expand |
On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote: > > If nd_integrity_init() fails we'd get del_gendisk() called, > but that's not correct as we should only call that if we're > done with device_add_disk(). Fix this by providing unwinding > prior to the devm call being registered and moving the devm > registration to the very end. > > This should fix calling del_gendisk() if nd_integrity_init() > fails. I only spotted this issue through code inspection. It > does not fix any real world bug. > Just fyi, I'm preparing patches to delete this driver completely as it is unused by any shipping platform. I hope to get that removal into v5.16.
On Fri, Oct 15, 2021 at 05:13:48PM -0700, Dan Williams wrote: > On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote: > > > > If nd_integrity_init() fails we'd get del_gendisk() called, > > but that's not correct as we should only call that if we're > > done with device_add_disk(). Fix this by providing unwinding > > prior to the devm call being registered and moving the devm > > registration to the very end. > > > > This should fix calling del_gendisk() if nd_integrity_init() > > fails. I only spotted this issue through code inspection. It > > does not fix any real world bug. > > > > Just fyi, I'm preparing patches to delete this driver completely as it > is unused by any shipping platform. I hope to get that removal into > v5.16. I'll remove this from my queue, any chance you can review the changes for nvdimm/btt? Luis
On Fri, Oct 15, 2021 at 05:13:48PM -0700, Dan Williams wrote: > On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote: > > > > If nd_integrity_init() fails we'd get del_gendisk() called, > > but that's not correct as we should only call that if we're > > done with device_add_disk(). Fix this by providing unwinding > > prior to the devm call being registered and moving the devm > > registration to the very end. > > > > This should fix calling del_gendisk() if nd_integrity_init() > > fails. I only spotted this issue through code inspection. It > > does not fix any real world bug. > > > > Just fyi, I'm preparing patches to delete this driver completely as it > is unused by any shipping platform. I hope to get that removal into > v5.16. Curious if are you going to nuking it on v5.16? Otherwise it would stand in the way of the last few patches to add __must_check for the final add_disk() error handling changes. Luis
On Tue, Nov 2, 2021 at 5:10 PM Luis Chamberlain <mcgrof@kernel.org> wrote: > > On Fri, Oct 15, 2021 at 05:13:48PM -0700, Dan Williams wrote: > > On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote: > > > > > > If nd_integrity_init() fails we'd get del_gendisk() called, > > > but that's not correct as we should only call that if we're > > > done with device_add_disk(). Fix this by providing unwinding > > > prior to the devm call being registered and moving the devm > > > registration to the very end. > > > > > > This should fix calling del_gendisk() if nd_integrity_init() > > > fails. I only spotted this issue through code inspection. It > > > does not fix any real world bug. > > > > > > > Just fyi, I'm preparing patches to delete this driver completely as it > > is unused by any shipping platform. I hope to get that removal into > > v5.16. > > Curious if are you going to nuking it on v5.16? Otherwise it would stand > in the way of the last few patches to add __must_check for the final > add_disk() error handling changes. True, I don't think I can get it nuked in time, so you can add my Reviewed-by for this one.
On 11/2/21 6:49 PM, Dan Williams wrote: > On Tue, Nov 2, 2021 at 5:10 PM Luis Chamberlain <mcgrof@kernel.org> wrote: >> >> On Fri, Oct 15, 2021 at 05:13:48PM -0700, Dan Williams wrote: >>> On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote: >>>> >>>> If nd_integrity_init() fails we'd get del_gendisk() called, >>>> but that's not correct as we should only call that if we're >>>> done with device_add_disk(). Fix this by providing unwinding >>>> prior to the devm call being registered and moving the devm >>>> registration to the very end. >>>> >>>> This should fix calling del_gendisk() if nd_integrity_init() >>>> fails. I only spotted this issue through code inspection. It >>>> does not fix any real world bug. >>>> >>> >>> Just fyi, I'm preparing patches to delete this driver completely as it >>> is unused by any shipping platform. I hope to get that removal into >>> v5.16. >> >> Curious if are you going to nuking it on v5.16? Otherwise it would stand >> in the way of the last few patches to add __must_check for the final >> add_disk() error handling changes. > > True, I don't think I can get it nuked in time, so you can add my > Reviewed-by for this one. Luis, I lost track of the nv* patches from this discussion. If you want them in 5.16 and they are reviewed, please do resend and I'll pick them up for the middle-of-merge-window push.
On Tue, Nov 02, 2021 at 05:49:12PM -0700, Dan Williams wrote: > On Tue, Nov 2, 2021 at 5:10 PM Luis Chamberlain <mcgrof@kernel.org> wrote: > > > > On Fri, Oct 15, 2021 at 05:13:48PM -0700, Dan Williams wrote: > > > On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote: > > > > > > > > If nd_integrity_init() fails we'd get del_gendisk() called, > > > > but that's not correct as we should only call that if we're > > > > done with device_add_disk(). Fix this by providing unwinding > > > > prior to the devm call being registered and moving the devm > > > > registration to the very end. > > > > > > > > This should fix calling del_gendisk() if nd_integrity_init() > > > > fails. I only spotted this issue through code inspection. It > > > > does not fix any real world bug. > > > > > > > > > > Just fyi, I'm preparing patches to delete this driver completely as it > > > is unused by any shipping platform. I hope to get that removal into > > > v5.16. > > > > Curious if are you going to nuking it on v5.16? Otherwise it would stand > > in the way of the last few patches to add __must_check for the final > > add_disk() error handling changes. > > True, I don't think I can get it nuked in time, so you can add my > Reviewed-by for this one. This patch required the previous patch in this series to also be applied. Can I apply your Reviewed-by there too? Luis
On Tue, Nov 02, 2021 at 07:28:02PM -0600, Jens Axboe wrote: > On 11/2/21 6:49 PM, Dan Williams wrote: > > On Tue, Nov 2, 2021 at 5:10 PM Luis Chamberlain <mcgrof@kernel.org> wrote: > >> > >> On Fri, Oct 15, 2021 at 05:13:48PM -0700, Dan Williams wrote: > >>> On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote: > >>>> > >>>> If nd_integrity_init() fails we'd get del_gendisk() called, > >>>> but that's not correct as we should only call that if we're > >>>> done with device_add_disk(). Fix this by providing unwinding > >>>> prior to the devm call being registered and moving the devm > >>>> registration to the very end. > >>>> > >>>> This should fix calling del_gendisk() if nd_integrity_init() > >>>> fails. I only spotted this issue through code inspection. It > >>>> does not fix any real world bug. > >>>> > >>> > >>> Just fyi, I'm preparing patches to delete this driver completely as it > >>> is unused by any shipping platform. I hope to get that removal into > >>> v5.16. > >> > >> Curious if are you going to nuking it on v5.16? Otherwise it would stand > >> in the way of the last few patches to add __must_check for the final > >> add_disk() error handling changes. > > > > True, I don't think I can get it nuked in time, so you can add my > > Reviewed-by for this one. > > Luis, I lost track of the nv* patches from this discussion. If you want > them in 5.16 and they are reviewed, please do resend and I'll pick them > up for the middle-of-merge-window push. Sure thing, I'll resend whatever is left. I also noticed for some reason I forgot to convert nvdimm/pmem and so I'll roll those new patches in, but I suspect that those might be too late unless we get them reviewed in time. Luis
diff --git a/drivers/nvdimm/blk.c b/drivers/nvdimm/blk.c index 088d3dd6f6fa..591fa1f86f1e 100644 --- a/drivers/nvdimm/blk.c +++ b/drivers/nvdimm/blk.c @@ -240,6 +240,7 @@ static int nsblk_attach_disk(struct nd_namespace_blk *nsblk) resource_size_t available_disk_size; struct gendisk *disk; u64 internal_nlba; + int rc; internal_nlba = div_u64(nsblk->size, nsblk_internal_lbasize(nsblk)); available_disk_size = internal_nlba * nsblk_sector_size(nsblk); @@ -256,20 +257,26 @@ static int nsblk_attach_disk(struct nd_namespace_blk *nsblk) blk_queue_logical_block_size(disk->queue, nsblk_sector_size(nsblk)); blk_queue_flag_set(QUEUE_FLAG_NONROT, disk->queue); - if (devm_add_action_or_reset(dev, nd_blk_release_disk, disk)) - return -ENOMEM; - if (nsblk_meta_size(nsblk)) { - int rc = nd_integrity_init(disk, nsblk_meta_size(nsblk)); + rc = nd_integrity_init(disk, nsblk_meta_size(nsblk)); if (rc) - return rc; + goto out_before_devm_err; } set_capacity(disk, available_disk_size >> SECTOR_SHIFT); device_add_disk(dev, disk, NULL); + + /* nd_blk_release_disk() is called if this fails */ + if (devm_add_action_or_reset(dev, nd_blk_release_disk, disk)) + return -ENOMEM; + nvdimm_check_and_set_ro(disk); return 0; + +out_before_devm_err: + blk_cleanup_disk(disk); + return rc; } static int nd_blk_probe(struct device *dev)
If nd_integrity_init() fails we'd get del_gendisk() called, but that's not correct as we should only call that if we're done with device_add_disk(). Fix this by providing unwinding prior to the devm call being registered and moving the devm registration to the very end. This should fix calling del_gendisk() if nd_integrity_init() fails. I only spotted this issue through code inspection. It does not fix any real world bug. Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> --- drivers/nvdimm/blk.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)