On 5/26/23 08:04, Damien Le Moal wrote: > 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 ? Replying to myself :) iomap_read_folio() or iomap_finish_folio_read() -> folio_set_error(), which sets PG_error. Then filemap_read_folio() will see !folio_test_uptodate(folio) and end up returning -EIO. So if there was an IO and it failed, we always get EIO, regardless of the actual reason for the IO failure. Right ? -- Damien Le Moal Western Digital Research
