Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 3 Mar 2020 08:43:17 -0800
From:   Matthew Wilcox <willy@infradead.org>
To:     Xianting Tian <xianting_tian@126.com>
Cc:     akpm@linux-foundation.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/filemap.c: clear page error before actual read
Message-ID: <20200303164317.GS29971@bombadil.infradead.org>
References: <1583248190-18123-1-git-send-email-xianting_tian@126.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1583248190-18123-1-git-send-email-xianting_tian@126.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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;