On 2/21/24 00:54, Ming Lei wrote:

On Wed, Feb 21, 2024 at 11:16 AM Keith Busch [off-list ref] wrote:

quoted

On Wed, Feb 21, 2024 at 03:05:30AM +0000, Chaitanya Kulkarni wrote:

quoted

On 2/20/24 12:41, Keith Busch wrote:

quoted

From: Keith Busch <kbusch@kernel.org>

@@ -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