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.
