[PATCH v5 00/14] last set for add_disk() error handling

[Luis Chamberlain]

On Thu, Nov 04, 2021 at 11:10:48AM -0600, Jens Axboe wrote:
> On 11/4/21 11:07 AM, Luis Chamberlain wrote:
> > On Thu, Nov 04, 2021 at 06:53:34AM -0600, Jens Axboe wrote:
> >> On 11/4/21 5:49 AM, Jens Axboe wrote:
> >>> On Wed, 3 Nov 2021 16:04:23 -0700, Luis Chamberlain wrote:
> >>>> Jens,
> >>>>
> >>>> as requested, I've folded all pending changes into this series. This
> >>>> v5 pegs on Christoph's reviewed-by tags and since I was respinning I
> >>>> modified the ataprobe and floppy driver changes as he suggested.
> >>>>
> >>>> I think this is it. The world of floppy has been exciting for v5.16.
> >>>>
> >>>> [...]
> >>>
> >>> Applied, thanks!
> >>>
> >>> [01/14] nvdimm/btt: use goto error labels on btt_blk_init()
> >>>         commit: 2762ff06aa49e3a13fb4b779120f4f8c12c39fd1
> >>> [02/14] nvdimm/btt: add error handling support for add_disk()
> >>>         commit: 16be7974ff5d0a5cd9f345571c3eac1c3f6ba6de
> >>> [03/14] nvdimm/blk: avoid calling del_gendisk() on early failures
> >>>         commit: b7421afcec0c77ab58633587ddc29d53e6eb95af
> >>> [04/14] nvdimm/blk: add error handling support for add_disk()
> >>>         commit: dc104f4bb2d0a652dee010e47bc89c1ad2ab37c9
> >>> [05/14] nvdimm/pmem: cleanup the disk if pmem_release_disk() is yet assigned
> >>>         commit: accf58afb689f81daadde24080ea1164ad2db75f
> >>> [06/14] nvdimm/pmem: use add_disk() error handling
> >>>         commit: 5a192ccc32e2981f721343c750b8cfb4c3f41007
> >>> [07/14] z2ram: add error handling support for add_disk()
> >>>         commit: 15733754ccf35c49d2f36a7ac51adc8b975c1c78
> >>> [08/14] block/sunvdc: add error handling support for add_disk()
> >>>         commit: f583eaef0af39b792d74e39721b5ba4b6948a270
> >>> [09/14] mtd/ubi/block: add error handling support for add_disk()
> >>>         commit: ed73919124b2e48490adbbe48ffe885a2a4c6fee
> >>> [10/14] ataflop: remove ataflop_probe_lock mutex
> >>>         commit: 4ddb85d36613c45bde00d368bf9f357bd0708a0c
> >>> [11/14] block: update __register_blkdev() probe documentation
> >>>         commit: 26e06f5b13671d194d67ae8e2b66f524ab174153
> >>> [12/14] ataflop: address add_disk() error handling on probe
> >>>         commit: 46a7db492e7a27408bc164cbe6424683e79529b0
> >>> [13/14] floppy: address add_disk() error handling on probe
> >>>         commit: ec28fcc6cfcd418d20038ad2c492e87bf3a9f026
> >>> [14/14] block: add __must_check for *add_disk*() callers
> >>>         commit: 1698712d85ec2f128fc7e7c5dc2018b5ed2b7cf6
> >>
> >> rivers/scsi/sd.c: In function ‘sd_probe’:
> >> drivers/scsi/sd.c:3573:9: warning: ignoring return value of ‘device_add_disk’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
> >>  3573 |         device_add_disk(dev, gd, NULL);
> >>       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> drivers/scsi/sr.c: In function ‘sr_probe’:
> >> drivers/scsi/sr.c:731:9: warning: ignoring return value of ‘device_add_disk’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
> >>   731 |         device_add_disk(&sdev->sdev_gendev, disk, NULL);
> >>       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>
> >>
> >> Dropping the last two patches...
> > 
> > Martin K Peterson has the respective patches needed queued up on his tree
> > for v5.16:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?h=5.16/scsi-staging&id=e9d658c2175b95a8f091b12ddefb271683aeacd9
> > https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?h=5.16/scsi-staging&id=2a7a891f4c406822801ecd676b076c64de072c9e
> > 
> > Would the last patch be sent once that gets to Linus?
> 
> But that dependency wasn't clear in the patches posted,

Sorry my mistake.

> and it leaves me
> wondering if there are others?

There should not be, becauase at least my patches on top of linux-next
compiles fine as per 0-day builds on tons of configs.

> I obviously can't queue up a patch that
> adds a must_check to a function, when we still have callers that don't
> properly check it.

Absolutely.

> That should have been made clear, and that last patch never should've
> been part of the series. Please send it once Linus's tree has all
> callers checking the result.

Indeed. Will track and will do.

> > Also curious why drop the last two patches instead just the last one for
> > now?
> 
> Sorry, meant just the last one.

Ah ok!

  Luis