On Wed, Feb 21, 2024 at 11:16 AM Keith Busch <kbusch@xxxxxxxxxx> 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. The zeroout API could be called from FS code in user context, and this way may confuse FS code, given it returns successfully, but actually it does not. Thanks,
