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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 368D1C0015E for ; Tue, 18 Jul 2023 16:16:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE7E48D000C; Tue, 18 Jul 2023 12:16:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B71558D0001; Tue, 18 Jul 2023 12:16:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A11FC8D000C; Tue, 18 Jul 2023 12:16:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8F6448D0001 for ; Tue, 18 Jul 2023 12:16:27 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 466ABA0105 for ; Tue, 18 Jul 2023 16:16:27 +0000 (UTC) X-FDA: 81025235214.04.EE66043 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf07.hostedemail.com (Postfix) with ESMTP id 40FD24000F for ; Tue, 18 Jul 2023 16:16:22 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=uQm6oxEI; dmarc=none; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689696984; a=rsa-sha256; cv=none; b=fWlXpMCsdasR80RXiNnZQd6Ewj2lM3o8Jegr14FuSQy/oiT09TdpHrTS5Pzd6ZzwRpfa3D 97/ErV5lK5FuYtGtHVawWPp5hNccXO2TzBQ5INNgpsi9mY56ikqNw9Phq+uAGkVRL9bu1j RYhIpR77KVPJOAekC6555FPboSHIme8= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=uQm6oxEI; dmarc=none; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689696984; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=u9BHQvttlzeTCBclAmv6cmgN9khV9hmdF8Tu8zmlFTU=; b=lTG7ftNdy0yqwAlizm2DR/6mXXSttNR6q+mzIipDalnKFQCqcS5PUeGBB+kjmuDptrE1+n pq0cCMBisikAlVnBcEAmrK8WXbHI/FG2CDPjgGkfiUTI2PHRWPnN8PK4y4zT2fUEHHRkQU goi0KMycMi89xmrguXQ01FL0L+s8BrQ= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=u9BHQvttlzeTCBclAmv6cmgN9khV9hmdF8Tu8zmlFTU=; b=uQm6oxEIquBuljibWe2eg/7ooK 3O2yX4DWQ0bQlHX0OzR9gmCw/hGWjVzy+xl9K7Q7YYAK5pOQgu1/aHxgoQZ49pl+ah8UV/OUBJxWU UmQxXrmSGQ8umVKYnzWopkASq20NyuCDsCdJ+7BxU85UyrXN3A9bS36QXUpy3DkhRqOsjPY4fyJya HxJyH+TFE9Gbw+AgNNoUdfIJaUvQQHGeCr6pJmS7hUsJEX1HmVVxrXs/3Vo5Dzz/BF79Y/QoTwmXu Eji9FUkyHXRW0+lMzX64YAi5/TkMdxjGcIiPXmPgHDqCIjBtl9zWKx0h+FItadl3zYJ2YBqMCEytm eWEBJjsg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qLnN1-0054rl-Ja; Tue, 18 Jul 2023 16:16:15 +0000 Date: Tue, 18 Jul 2023 17:16:15 +0100 From: Matthew Wilcox To: "zhangpeng (AS)" Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, sidhartha.kumar@oracle.com, akpm@linux-foundation.org, wangkefeng.wang@huawei.com, sunnanyong@huawei.com Subject: Re: [PATCH 1/6] mm/page_io: use a folio in __end_swap_bio_read() Message-ID: References: <20230717132602.2202147-1-zhangpeng362@huawei.com> <20230717132602.2202147-2-zhangpeng362@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 40FD24000F X-Stat-Signature: 1mejca14n6w1w8ynnfknextaoc7ym6sm X-HE-Tag: 1689696982-801169 X-HE-Meta: U2FsdGVkX1+q4exQCPVRF33PHzeY+Pbn6l0VECKzDkh09RK6zc12Ns8MUdwo+93IPOglMpMwIrc8gcqwvCwWPHMgG3bQg2xxawf0zT2+3jDO5SxooyfUNd2QdOD9VGBVm9cJk/OZJTESmfhbGvcjGpsqr/MzawbU4nM1JXUUohO1KND6UJi479nL5Y4iFzaldyRn1TE8Vze045qlCeWCRwZyDJ45VINQFfWsXHoqzhQUJLSwYRPnoBr2dXlha/lFs5kzjOmw7IMsBqZdEYZm9//Wev/kvZ4whUWR+rmPSI8R2E2O0fhA3cbrZ/yT45yVz5pYa2LdbGw+tbF78hoqDyqoSWZZx2OiejTEXxTFKBTXpclg90SjsqXCMa+aBcm9LUGUoeVz++cGO42FHa2SoItngP1JdwKXXvvaikgjFax6sdFPG7B/gIq3q2b1ldla0nzHAXbOWmFnngSbpLiF67nTp63YhtacMmQEzA2tu/8nArLir4rQhR4jFjHkryBzjjOxyK77gudR/gYqZbi8SFDJr08FYxdocim61zxC0JdqxmVqrEAGGqywemreobJCpBqepHb1ALGnjRR+yqQ+RORaJOG8ixIfuwxmXsPwWahAAuMDMdMJXh9xj6llTiZfIiziBbqMILuJ3Ng4TOk7VYIqCqJN0K4U/rR+tmMNxT+bDwHDoeW2xpXKVCxpu0H6dfmnLdOQUd5aKxrJxLP19a+BeLj8pENq6HtM+xPLltyJYJ8tFHftTZNq0D6S+6KSljf+STEo8YhY38yi87NokhjRLQeVzNuFh0syUxoiZfOdFiqRJkEaNFBVv+5L681BAoB1hKbu8HlJZ766x7hsEOYdfssxAhxMp7uVyXV6seU2xh6D34n0Ru9ejMV0DxDoiNXk7pxOMHNP5DRQS5Fuymrdrr+L0ThR1Mea1v4u390thhIsDkEQw0B4S8bgiOZvLzMgp7f4/Q4pksTC4QS UvfJcqhF uKMAhR0bM4wmD6P++nYd2LQdjAalS62PvsHrkRO245adL1RruxStZVMW+ZlJji0ErAG+ctHUM1wkL0oSPOaGgt3cjdXjg6zy+aYKbpU86jNgjbQUmS2apaNlmWToU5lQjR6WgcG7cDJoRXYOuujMliNnrCINjMDLoK/Cj9OpEuin3wdeAtqM+23Dfcw== 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, Jul 18, 2023 at 08:56:16PM +0800, zhangpeng (AS) wrote: > > > if (bio->bi_status) { > > > - SetPageError(page); > > > - ClearPageUptodate(page); > > > + folio_set_error(folio); > > I appreciate this is a 1:1 conversion, but maybe we could think about > > this a bit. Is there anybody who checks the > > PageError()/folio_test_error() for this page/folio? > > Maybe wait_dev_supers() checks the PageError() after write_dev_supers() > in fs/btrfs/disk-io.c? How does _this_ folio end up in btrfs's write_dev_supers()? This is a swap read. The only folios which are swapped are anonymous and tmpfs. btrfs takes care of doing its own I/O. wait_dev_supers() is looking for the error set in btrfs_end_super_write() which is the completion routine for write_dev_supers(). The pages involved there are attached to a btrfs address_space, not shmem or anon.