Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp3540221ybf; Tue, 3 Mar 2020 07:47:36 -0800 (PST) X-Google-Smtp-Source: ADFU+vvdzqZSg9dJKgi7/UhbmZNxy4RYb2tpCjnTyZyamaSNxrsXu1eZOp5YQy2hCISlunJjeRcv X-Received: by 2002:a05:6830:1ca:: with SMTP id r10mr3728599ota.319.1583250456332; Tue, 03 Mar 2020 07:47:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583250456; cv=none; d=google.com; s=arc-20160816; b=UNnb8bsGPKaup7rIei2i/Y9cP5mJIzG3gy4ioLXhrs2wLcLHnMZ3AUrmlzqVY7Kxfl 1e6D6977QmJXz2N03Vvy7mCi5nQpK/a/gorC4WskgUU8c1WUfkT87o3PcANYx3DLeqvq Es3v72P58fZ6PXZuSbGP5wnxKAoD9zV4HRGbZfXqeqpcJsCTF0jtZkDlp4UW17XXbLIV 5zKD5kwHSYrW5w4LfU62wPom4GXiNpy0qolzrA70huxcRp0pFxmtuQ/wkEIhdYp2kDUS YGSlamr8fZPWc4zQYTzerj0TFW200u5LILbCSwqBaYD3DuW8GOAuZuAV9Q2XRmLXwZe+ BEjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature; bh=tucUIJDzJdQGxz9VTjFcydNy10+WnttpeLoZcEBMltQ=; b=MV6avwjiPMBfwVaVm3UjiS3xMsanDre1665N/JtNhWqXAvbUf/dL0c0hh5EssnXTE8 un2q+J0/u/K641fr0bCr2r6h9KVsq+8S5PFD8W6c8qR6owa749UVajtmT1xooPGJpk2S 8Xa5FqrGmUq30nhfEvW3bnhw1RhUPAyvoZ1iaULvOpsTK30dsdFkhoWg0cEMtrmqw7VW oBKvB2RZXfH5E1kKwrLCpGQD+RAC10+VMoflc1ruG3gthy5m9hsj7+A+EIpkXcIAIewk MVLColPjStrHcOYZSXYxsLcV5TdeAAQohrvoX9x82lXJIxwXEoi0Pb+YP+qd3q2tdvIC Stew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@126.com header.s=s110527 header.b=MdUVlzkH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=126.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f6si5689579otq.50.2020.03.03.07.47.23; Tue, 03 Mar 2020 07:47:36 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@126.com header.s=s110527 header.b=MdUVlzkH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=126.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728955AbgCCPKc (ORCPT + 99 others); Tue, 3 Mar 2020 10:10:32 -0500 Received: from m15-111.126.com ([220.181.15.111]:48767 "EHLO m15-111.126.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726988AbgCCPKc (ORCPT ); Tue, 3 Mar 2020 10:10:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=From:Subject:Date:Message-Id; bh=tucUIJDzJdQGxz9VTj FcydNy10+WnttpeLoZcEBMltQ=; b=MdUVlzkHdC8380MTa2fYYAkFJsXF+auvL2 eKSbs8lwCvuTyS4bbkBxbv7oVTrKj664IikyAExAECfT+AwVekXwaWTp4OQmnJON 2sKVW0+Mj49WdHqMP0SONHd00OgUEVlBdly2gScfHZ3sINP4ClHwkowKj64jgQmb kIN75OuQU= Received: from 192.168.137.250 (unknown [112.10.84.98]) by smtp1 (Coremail) with SMTP id C8mowACnO+E_c15e55mzBw--.46087S3; Tue, 03 Mar 2020 23:09:51 +0800 (CST) From: Xianting Tian To: akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH] mm/filemap.c: clear page error before actual read Date: Tue, 3 Mar 2020 10:09:50 -0500 Message-Id: <1583248190-18123-1-git-send-email-xianting_tian@126.com> X-Mailer: git-send-email 1.8.3.1 X-CM-TRANSID: C8mowACnO+E_c15e55mzBw--.46087S3 X-Coremail-Antispam: 1Uf129KBjvJXoWxZF1rGr4DAw1UAryrCrW7Jwb_yoWrAFWDpr ZxK3WDKr4DGrnrCan2q3Z7Ar1rJrsrAay5ZayrW343Zwn8JF1fW34xCFyjg345Gr1FyFWx XF45tas8CrnYqaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07j9yCXUUUUU= X-Originating-IP: [112.10.84.98] X-CM-SenderInfo: h0ld03plqjs3xldqqiyswou0bp/1tbi7QTbpFpD+F-zFQAAsO Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- mm/filemap.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/mm/filemap.c b/mm/filemap.c index 1784478..d65428f 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2755,6 +2755,13 @@ static struct page *do_read_cache_page(struct address_space *mapping, } filler: + /* + * 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); if (filler) err = filler(data, page); else -- 1.8.3.1