On 2/21/24 00:54, Ming Lei wrote: > 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, > that is why I asked for returning -EINTR initially, but it seems like it will not have any effect ? given that process is about to exit ? note that that it may also get called from other places e.g. NVMeOF target or any future callers :- nvmet_bdev_execute_write_zeroes() __blkdev_issue_zeroout() __blkdev_issue_zero_pages() -ck
