linux-kernel - Re: [RFC] Better page cache error handling

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] [day] [month] [year] [list]

Message-ID: <20210224235454.GV2858050@casper.infradead.org>
Date:   Wed, 24 Feb 2021 23:54:54 +0000
From:   Matthew Wilcox <willy@...radead.org>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     Jan Kara <jack@...e.cz>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>, linux-kernel@...r.kernel.org,
        Christoph Hellwig <hch@....de>,
        Kent Overstreet <kent.overstreet@...il.com>
Subject: Re: [RFC] Better page cache error handling

On Wed, Feb 24, 2021 at 04:41:26PM -0700, Andreas Dilger wrote:
> Since you would know that the page is bad at this point (not uptodate,
> does not contain valid data) you could potentially re-use some other

Oh, we don't know that.  We know _a_ read has failed.  There could be
up to 128 blocks that comprise this (64kB) page, and we don't want to
prevent reads to those other blocks in the page to fail unnecessarily.

> fields in struct page, or potentially store something in the page itself?
> That would avoid bloating struct page with fields that are only rarely
> needed.  Userspace shouldn't be able to read the page at that point if
> it is not marked uptodate, but they could overwrite it, so you wouldn't
> want to store any kind of complex data structure there, but you _could_
> store a magic, an error value, and a timeout, that are only valid if
> !uptodate (cleared if the page were totally overwritten by userspace).
> 
> Yes, it's nasty, but better than growing struct page, and better than
> blocking userspace threads for tens of minutes when a block is bad.

The current state blocks threads for tens of minutes.  I'm proposing
reducing it down to 30 seconds.  I'd want to see a more concrete
proposal than this ...

(also, a per-page data structure might blow up nastily if the entire
drive is inaccessible, rather than just a single bad block)