From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 959E7C54FCC for ; Tue, 21 Apr 2020 03:42:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5465E2084D for ; Tue, 21 Apr 2020 03:42:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="h2+sTaQ9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5465E2084D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0004C8E0005; Mon, 20 Apr 2020 23:42:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EF1788E0003; Mon, 20 Apr 2020 23:42:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE1738E0005; Mon, 20 Apr 2020 23:42:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0238.hostedemail.com [216.40.44.238]) by kanga.kvack.org (Postfix) with ESMTP id C37148E0003 for ; Mon, 20 Apr 2020 23:42:04 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8547745D8 for ; Tue, 21 Apr 2020 03:42:04 +0000 (UTC) X-FDA: 76730463768.10.run52_4c495e828dc10 X-HE-Tag: run52_4c495e828dc10 X-Filterd-Recvd-Size: 3016 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Tue, 21 Apr 2020 03:42:04 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3978D2071E; Tue, 21 Apr 2020 03:42:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587440523; bh=pEWs0YVxnwM137MWzOatekWnY7m66tGMYW/Tb3G2/Sg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=h2+sTaQ9C92+mNvG74s1lGlASAYFvm1PXnLkL9zCt8kUznsvq6OZI1vH4SpkUM+lh S5E2Vt4nzpvwGQWz5oDtE34stx98odqJca40dB3JNp3NlcioZ+7bc5VxXZYTt8K2tp 2ea4JhE3hUb9NX4Puf8Xqcmcz3P58ZNdCsGWjUGk= Date: Mon, 20 Apr 2020 20:42:02 -0700 From: Andrew Morton To: Xianting Tian Cc: , 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> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 3 Mar 2020 16:25:41 +0800 Xianting Tian 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.