linux-kernel - Re: [PATCH] mm/filemap.c: clear page error before actual read

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]

Date:   Tue, 3 Mar 2020 08:43:17 -0800
From:   Matthew Wilcox <willy@...radead.org>
To:     Xianting Tian <xianting_tian@....com>
Cc:     akpm@...ux-foundation.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/filemap.c: clear page error before actual read

On Tue, Mar 03, 2020 at 10:09:50AM -0500, Xianting Tian wrote:
> This patch is to add the calling of ClearPageError just before the
> actual read of read path of cramfs mount.

Thank you for your patch and your analysis.  I concur; an error set
on a page will not be cleared by doing a subsequent read.  This is
probably an oversight; in generic_file_buffered_read(), we do:

                ClearPageError(page);
                /* Start the actual read. The read will unlock the page. */
                error = mapping->a_ops->readpage(filp, page);

and also in filemap_fault:

        ClearPageError(page);
        fpin = maybe_unlock_mmap_for_io(vmf, fpin);
        error = mapping->a_ops->readpage(file, page);

That said, a freshly allocated page will not have PageError set on
it, so I would prefer to see this:

        /* Someone else locked and filled the page in a very small window */
        if (PageUptodate(page)) {
                unlock_page(page);
                goto out;
        }
+	ClearPageError(page);
        goto filler;