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 097EAC3064D for ; Tue, 2 Jul 2024 13:49:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 86F7C6B00A4; Tue, 2 Jul 2024 09:49:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F8CB6B00A5; Tue, 2 Jul 2024 09:49:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 698CD6B00A6; Tue, 2 Jul 2024 09:49:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4A4276B00A4 for ; Tue, 2 Jul 2024 09:49:29 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EAE6D160110 for ; Tue, 2 Jul 2024 13:49:28 +0000 (UTC) X-FDA: 82294944816.29.3F9080F Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf09.hostedemail.com (Postfix) with ESMTP id 8A50B140011 for ; Tue, 2 Jul 2024 13:49:25 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=FtzzuTBe; spf=none (imf09.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719928149; h=from:from:sender: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=dX5/1nrCmtj/7vSG0Hm+XX1H/8yMNBHnIxLwZ0Lk3Vk=; b=rI3BT3gFvt8E/nfYTgGV3+0AGKQ/zUWap1h7QTCFPg//AK+CBYIgZEforjvy5lt3L2HpJE LzuWUJMUXm2JQmt+AvOPzjbTcyDRlMua6LXm7B2rgIGJrfzaYIPtBLfjIXJWLB2nRc9bWM EWxzlL16ECmPr9uJBiIwsmWW87/BnxI= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=FtzzuTBe; spf=none (imf09.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719928149; a=rsa-sha256; cv=none; b=oj9qwY0ByL6HxZvnzn2PQqngMruvcSPtM0QGufJ/dSF+aUYoXhBuKDv/GRmsNvuxwFyu6g yphUK2Gu6dvJPCGOEOMJ//BZJWgpwTYv+aVCzQ2FwE+ZqEZiV70Kx95VR6m8Y+QZhzLu/u MDoMzWWov+Raw5RPs2EzZOwuTZkA0Cs= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=dX5/1nrCmtj/7vSG0Hm+XX1H/8yMNBHnIxLwZ0Lk3Vk=; b=FtzzuTBeQAWpHYFr42EsfwUQ6P ldVx5PM//U6UVq1UhOktpZ7jFKvEqRb7NsIyp7nJUSlC/H0AE1tc8N7qtnjImnbocNEp1quehLjBn 7cEfx2ONxGxq96CwxlhSRxtPRT/UFRCLnzhS3V4fzGsGjphULm8DG3U4ufJ8hofj58Yx7t24TLqQu hTVqbCiew+N4Pck4VZFgy1vpXqnph8m6kO0/QmXAHKv0wFZrtrCX+647gPPmzEw1MrfV9RVA0lufi 9JmkYog0SekBwIwRSm+vx8QlVSMkRwMH7mi4MR/pf0B05aSg+pn10ATSgNYOzrtYGSJiWjObUkl6Z 3LhJXOSw==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sOdsk-00000006v4b-171E; Tue, 02 Jul 2024 13:49:18 +0000 Date: Tue, 2 Jul 2024 06:49:18 -0700 From: Luis Chamberlain To: "Pankaj Raghav (Samsung)" , Mike Rapoport Cc: Christoph Hellwig , david@fromorbit.com, willy@infradead.org, chandan.babu@oracle.com, djwong@kernel.org, brauner@kernel.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, yang@os.amperecomputing.com, linux-mm@kvack.org, john.g.garry@oracle.com, linux-fsdevel@vger.kernel.org, hare@suse.de, p.raghav@samsung.com, gost.dev@samsung.com, cl@os.amperecomputing.com, linux-xfs@vger.kernel.org, Zi Yan Subject: Re: [PATCH v8 06/10] iomap: fix iomap_dio_zero() for fs bs > system page size Message-ID: References: <20240625114420.719014-1-kernel@pankajraghav.com> <20240625114420.719014-7-kernel@pankajraghav.com> <20240702074203.GA29410@lst.de> <20240702101556.jdi5anyr3v5zngnv@quentin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240702101556.jdi5anyr3v5zngnv@quentin> X-Stat-Signature: krmsitbsu34ei9y33srynf1ur6had9e7 X-Rspam-User: X-Rspamd-Queue-Id: 8A50B140011 X-Rspamd-Server: rspam02 X-HE-Tag: 1719928165-400414 X-HE-Meta: U2FsdGVkX195TmhNGxBjOysbkGepGUrfr1mRpn8+qLf2T1rowZRNQDGAPjknnFUFxKQbzSFIWoLopMmuW/AMLlH6ITlkri5OGOCAVBb/z3HgrES4mbsLmNUSNVzeEaRLKQSotPb6s1CtlFHSXta8HNV1ye8zt/zsRYHH0AI9zBy+vFfy2haJI1D3uQQVHy3Vvl1g2frLv2pSpxqOa49t+OUuaExF5tmSk8Oh1htzACCRbBjdFoYbMPld5R28Lukkmsfq5fKZCc2EpHqbnPeYXxWkGHyPLlbXqUE6qvtlkOh+8wNF7UaooCzmf9NsmgmV2kiFhls5hBg5Gcrn4TgC07h4Y1bCezR1y7bqvyO1QR5+BJLgY2c8GXPhJI1b9ZZWcP/Zw5armfJ0AYIXH3GYSGf8M+umYNTBfU6y0nfhb3B7j95tkzXseVhHfRjEvASOvZIYBBbnQAF7oW/mDdPbQN1ASGzD2I25gBdqbPYseH/loMMUfVi2pUlenFd/yjqqLWoMVznYUTjaqFefgL6DxSk5IPfle4+YD3QHXTfdcAJGMIC0rYncmhqkss2oUZp7RYzXGOav2ZwAJN4irqdkt+gsLD2np0zoZy94iVYOndbaBbAPvf7MMnhvhS+YV3MhcmNuwthU5Z0p0SfPusDIckuEli3bz/dnkaWryNgML7iAFl0GEjYD50MjPTvG0GOzN9VzOPvVkVMBorUhoxuuHzo/GC3fLzH2dYi4kvM78G4HxoZjTDg13oqlYO8GP3GFrTwLeJqiJGr1SAygmJyqQ+qMgp4DqEoUx4u5TzaDRoMLxsTHiHSQ48IgtoRxJGOtB3ts8DW1t7C8XGDiYPxghJ5ClGDc1CCk3MqmUu6jYZOO+isMeKBUkO3UGmC+R9KAJn32yPNFpbWIb4VLl1VXfQow054XpDIq9OzIPCzHJ0XGft/GVi9hy/WCrrLYYEJU/etEf3JyQzDXtPrU6HN 6WpMBYWq 7WCoRCbyMaBN6OqpSyhv+/e1RjV1uoUikiq+gjmG17XNMlkdhi4Rblh5H+UqeLHarjC3TSCxy6RVa6E/pF6wECw2V74gKCXemTfrIDhICSrZEnzAorcDGx5iErWbNjklFYm+GLmest91SlZLTscqQN252hpzN6VMqU+ueSiY5gQgqo5DnhMY8XbSELVwupoEFfplwKZobzge8ZWGjeHW+B/sEBo7LvlaqE1jVsPtIYpkZEd44BUQh3pfTG2p1TPJFHKWRKoh0LipGyxPkaabF7k3t5O0Na2meEV6hgxXS87sZ2QYIuQ7xP8JtuS/2+HOCUCkhkZ1yllzoJvSLiUI4zRMPMKFXcbTphFX3aRO7+VlEgIlL5e4Bmo90YLJiO0CvtF2s7tN5t/8waquLnScQE1PuByOXliS085YBGoWf3/fpxqkjpoMfIdE/+KNP2RpXn8jANdNxMOQiO0PrTAl0ImCc+fQjdiXBbzou 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: List-Subscribe: List-Unsubscribe: On Tue, Jul 02, 2024 at 10:15:56AM +0000, Pankaj Raghav (Samsung) wrote: > > > + set_memory_ro((unsigned long)page_address(zero_page_64k), > > > + 1U << ZERO_PAGE_64K_ORDER); > > > > What's the point of the set_memory_ro here? Yes, we won't write to > > it, but it's hardly an attack vector and fragments the direct map. > > That is a good point. Darrick suggested why not add a ro tag as we don't > write to it but I did not know the consequence of direct map > fragmentation when this is added. So probably there is no value calling > set_memory_ro here. Mike Rapoport already did the thankless hard work to evaluate if direct map fragmentation is something which causes a performance issue and it is not [0]. Either way, this is a *one* time thing, not something that happens as often as other things which aggrevate direct map fragmentation like eBPF, and so from my perspective there is no issue to using, if we want set_memory_ro(). [0] https://lwn.net/Articles/931406/ Luis