linux-kernel - Re: [PATCH] iomap: Handle I/O errors gracefully in page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200604225726.GU2040@dread.disaster.area>
Date:   Fri, 5 Jun 2020 08:57:26 +1000
From:   Dave Chinner <david@...morbit.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Christoph Hellwig <hch@...radead.org>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iomap: Handle I/O errors gracefully in page_mkwrite

On Thu, Jun 04, 2020 at 01:23:40PM -0700, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@...radead.org>
> 
> Test generic/019 often results in:
> 
> WARNING: at fs/iomap/buffered-io.c:1069 iomap_page_mkwrite_actor+0x57/0x70
> 
> Since this can happen due to a storage error, we should not WARN for it.
> Just return -EIO, which will be converted to a SIGBUS for the hapless
> task attempting to write to the page that we can't read.

Why didn't the "read" part of the fault which had the EIO error fail
the page fault? i.e. why are we waiting until deep inside the write
fault path to error out on a failed page read?

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com