On 5/26/23 00:21, Matthew Wilcox wrote: > On Thu, May 25, 2023 at 09:38:57AM +0100, David Howells wrote: >> >> Call zonefs_io_error() after getting any error from filemap_splice_read() >> in zonefs_file_splice_read(), including non-fatal errors such as ENOMEM, >> EINTR and EAGAIN. >> >> Suggested-by: Damien Le Moal <dlemoal@xxxxxxxxxx> >> Link: https://lore.kernel.org/r/5d327bed-b532-ad3b-a211-52ad0a3e276a@xxxxxxxxxx/ > > This seems like a bizarre thing to do. Let's suppose you got an > -ENOMEM. blkdev_report_zones() is also likely to report -ENOMEM in > that case, which will cause a zonefs_err() to be called. Surely > that can't be the desired outcome from getting -ENOMEM! Right... What I want to make sure here is that the error we get is not the result of a failed IO. Beside EIO, are there any other cases ? I can think of at least: 1) -ETIMEDOUT -> the drive is not responding. In this case, calling zonefs_io_error() may not be useful either. 2) -ETIME: The IO was done with a duration limit (e.g. active time limit) and was aborted by the drive because it took too long. Calling zonefs_io_error() for this case is also not useful. But I am thinking block layer (blk_status_t to errno conversion) here. Does the folio code *always* return EIO if it could not get a page/folio, regardless of the actual bio status ? -- Damien Le Moal Western Digital Research
