Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp876031pxk; Thu, 17 Sep 2020 20:02:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwyYo9cS7g865BYWNHlBXK52ZeXxnRPK7P3fZyUPkrqdCmdcGkbW3fP8l0yDl0HPzXw6t6f X-Received: by 2002:a17:906:552:: with SMTP id k18mr21445094eja.482.1600398141790; Thu, 17 Sep 2020 20:02:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600398141; cv=none; d=google.com; s=arc-20160816; b=UdmuNp4j/TS5FEdLnOxUv3IVl6cPMcsHoCstBiYHDRJl+nsWyprRO9YHUq2emDrnXH KDOY05hWnD3UFvQ4MKoidviV4RxmbyDxhXL9xGVhmk8EN59Ja1ULBhzoyg9pn8DbwjRG tVEbBUtUJTUCFV77KM8Cj+1Q99U8EddcoRYgSqLu/Vl40gBOxRNIU1MSHgyTxMulM95v l+gMtx2PNzdy4UhtRf0mArwzMt8ZnS/2QKwxBNSRTsqNMebfQkf1CFPBNxX4HaaBgMd0 +EgqgH6n08IDq+w+O4ccsIHcFrCo8U0FiBBoODsyWGiI50NRS5651Cg1I0Av5sd8aYV6 j5/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=dBu4pAqHDasFuiuU+AdnL3YSJMwSrwfSO+DbYClh1tc=; b=QtYm2G7hqQFGzBvRGFN5C4Z2gRlwfDsdw0Ts09RxAicrJOmLMT6HVcrvEm3ndiT3On qSIjg3GCeIEj5QtESnpJdzDaErUopf7PUKP6/w36sCQC0seKrQJGLQI/kmBI3WlCw5ki 98En5mb+0yXqpv/hw/93kF6DljJVOkVUT11IFpLZysdhaZ54SQiBNR7xVSMsGOPbJiz2 6jjfZKD2Xjv45MWxJ2e8nJlnJlHy4NRm1y5NHy+t6TcuGW1r8JCLzX7WDf6VUJ35OhNV xI9jKo7xzbYIqVlHVt2Ism2e1XYMcFSkl7VWUPSfK+E017TXtiOyE9UNo8SZ5qg8nH+7 miaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=o1cjuKj4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p21si1110985edq.151.2020.09.17.20.01.58; Thu, 17 Sep 2020 20:02:21 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=o1cjuKj4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730440AbgIRC7w (ORCPT + 99 others); Thu, 17 Sep 2020 22:59:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:54396 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727639AbgIRCFs (ORCPT ); Thu, 17 Sep 2020 22:05:48 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4732E238D7; Fri, 18 Sep 2020 02:05:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600394747; bh=hQzgCEQXCPPfm/nUC4Z/h/yFQmbA9POxouv97PfeJ7o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=o1cjuKj4umbTWEkQk5GV8YCrE/QCmW7tE8b/0ybpzIdF9vcSsnx8286YiGmRdHNee emkz3yFKEhUCFCZ5OlIxc4b/52mFObaEjlj4GBoKvdlQFWP7QmO20eCKi2nM9cBw+G btjdxHGNpgFNah0a6Y85PZYT7WWZmYaR8bGqKtlk= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Xianting Tian , Andrew Morton , Matthew Wilcox , Jan Kara , yubin@h3c.com, Linus Torvalds , Sasha Levin , linux-mm@kvack.org Subject: [PATCH AUTOSEL 5.4 226/330] mm/filemap.c: clear page error before actual read Date: Thu, 17 Sep 2020 21:59:26 -0400 Message-Id: <20200918020110.2063155-226-sashal@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200918020110.2063155-1-sashal@kernel.org> References: <20200918020110.2063155-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Xianting Tian [ Upstream commit faffdfa04fa11ccf048cebdde73db41ede0679e0 ] Mount failure issue happens under the scenario: Application 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); } Then mount operation is performed, it used the same page which is just accessed by systemd-udevd above, Because this page is not uptodate, it will launch a actual read via submit_bh, then wait on this page by calling wait_on_page_locked(page). When the I/O of the page done, io_end handler end_buffer_async_read is called, because no one cleared the page error(during the whole read path of mount), which is caused by systemd-udevd reading, so this page is still in "PageError" status, which can't be set to uptodate in function end_buffer_async_read, then caused mount failure. But sometimes mount succeed even through systemd-udeved read loopX dev just before, The reason is systemd-udevd launched other loopX read just between step 3.1 and 3.2, the steps as below: 1, loopX dev default status is Lo_unbound; 2, systemd-udved read loopX dev (page is set to PageError); 3, mount operation 1) set loopX status to Lo_bound; ==>systemd-udevd read loopX dev<== 2) read loopX dev(page has no error) 3) mount succeed As the loopX dev status is set to Lo_bound after step 3.1, so the other loopX dev read by systemd-udevd will go through the whole I/O stack, part of the call trace as below: SYS_read vfs_read do_sync_read blkdev_aio_read generic_file_aio_read do_generic_file_read: ClearPageError(page); mapping->a_ops->readpage(filp, page); here, mapping->a_ops->readpage() is blkdev_readpage. In latest kernel, some function name changed, the call trace as below: blkdev_read_iter generic_file_read_iter generic_file_buffered_read: /* * A previous I/O error may have been due to temporary * failures, eg. mutipath errors. * Pg_error will be set again if readpage fails. */ ClearPageError(page); /* Start the actual read. The read will unlock the page*/ error=mapping->a_ops->readpage(flip, page); We can see ClearPageError(page) is called before the actual read, then the read in step 3.2 succeed. This patch is to add the calling of ClearPageError just before the actual read of read path of cramfs mount. Without the patch, the call trace as below when performing cramfs mount: do_mount cramfs_read cramfs_blkdev_read read_cache_page do_read_cache_page: filler(data, page); or mapping->a_ops->readpage(data, page); With the patch, the call trace as below when performing mount: do_mount cramfs_read cramfs_blkdev_read read_cache_page: do_read_cache_page: ClearPageError(page); <== new add filler(data, page); or mapping->a_ops->readpage(data, page); With the patch, mount operation trigger the calling of ClearPageError(page) before the actual read, the page has no error if no additional page error happen when I/O done. Signed-off-by: Xianting Tian Signed-off-by: Andrew Morton Reviewed-by: Matthew Wilcox (Oracle) Cc: Jan Kara Cc: Link: http://lkml.kernel.org/r/1583318844-22971-1-git-send-email-xianting_tian@126.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- mm/filemap.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/mm/filemap.c b/mm/filemap.c index 18c1f58300742..51b2cb5aa5030 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2845,6 +2845,14 @@ filler: unlock_page(page); goto out; } + + /* + * A previous I/O error may have been due to temporary + * failures. + * Clear page error before actual read, PG_error will be + * set again if read page fails. + */ + ClearPageError(page); goto filler; out: -- 2.25.1