On 2/20/24 19:21, Keith Busch wrote: > On Tue, Feb 20, 2024 at 08:16:29PM -0700, Keith Busch wrote: >> On Wed, Feb 21, 2024 at 03:05:30AM +0000, Chaitanya Kulkarni wrote: >>> On 2/20/24 12:41, Keith Busch wrote: >>>> From: Keith Busch <kbusch@xxxxxxxxxx> >>>> @@ -190,6 +190,8 @@ static int __blkdev_issue_zero_pages(struct block_device *bdev, >>>> break; >>>> } >>>> cond_resched(); >>>> + if (fatal_signal_pending(current)) >>>> + break; >>>> } >>>> >>>> *biop = bio; >>> We are exiting before completion of the whole I/O request, does it makes >>> sense to return 0 == success if I/O is interrupted by the signal ? >>> that means I/O not completed, hence it is actually an error, can we return >>> the -EINTR when you are handling outstanding signal ? >> I initially thought so too, but it doesn't matter. Once the process >> returns to user space, the signal kills it and the exit status reflects >> accordingly. That's true even before this patch, but it would just take >> longer for the exit. > Also consider that we have bio's in flight here, and an error return > will skip waiting for them. The kill signal handling here doesn't abort > inflight requests (that's too hard); it just prevents creating and > waiting for the rest of them, which could be millions. comment would be nice but not necessary, irrespective of that, looks good :- Reviewed-by: Chaitanya Kulkarni <kch@xxxxxxxxxx> -ck
