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]

Message-Id: <20200420204202.96450f776ee42bdc39b191b8@linux-foundation.org>
Date:   Mon, 20 Apr 2020 20:42:02 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Xianting Tian <tian.xianting@....com>
Cc:     <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm/filemap.c: clear page error before actual read

On Tue, 3 Mar 2020 16:25:41 +0800 Xianting Tian <tian.xianting@....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.