Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 20 Apr 2020 20:42:02 -0700
From:   Andrew Morton <akpm@linux-foundation.org>
To:     Xianting Tian <tian.xianting@h3c.com>
Cc:     <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/filemap.c: clear page error before actual read
Message-Id: <20200420204202.96450f776ee42bdc39b191b8@linux-foundation.org>
In-Reply-To: <20200303082541.33354-1-tian.xianting@h3c.com>
References: <20200303082541.33354-1-tian.xianting@h3c.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 3 Mar 2020 16:25:41 +0800 Xianting Tian <tian.xianting@h3c.com> wrote:

> Mount failure issue happens under the scenario:
> Application totally forked dozens of threads to mount the same
> number of cramfs images separately in docker, but several mounts
> failed with high probability.
> Mount failed due to the checking result of the page
> (read from the superblock of loop dev) is not uptodate after
> wait_on_page_locked(page) returned in function cramfs_read:
>    wait_on_page_locked(page);
>    if (!PageUptodate(page)) {
>       ...
>    }
> 
> The reason of the checking result of the page not uptodate:
> systemd-udevd read the loopX dev before mount, because the status
> of loopX is Lo_unbound at this time, so loop_make_request directly
> trigger the calling of io_end handler end_buffer_async_read, which
> called SetPageError(page). So It caused the page can't be set to
> uptodate in function end_buffer_async_read:
>    if(page_uptodate && !PageError(page)) {
>       SetPageUptodate(page);
>    }

I'm wondering whether we should instead be invalidating the blockdev's
pagecache around the time of the loop binding.

But it's hard to say because loop_make_request() hasn't existed for a
long time.  What kernel version are you working against?

Are you able to test a (much) more recent kernel?  If so, and if the
problem persists, please update your problem description based on the
current kernel code so that others can more easily go in and take a
look, thanks.