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 657C1C3064D for ; Tue, 2 Jul 2024 07:42:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E32286B009F; Tue, 2 Jul 2024 03:42:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DBAFD6B00A0; Tue, 2 Jul 2024 03:42:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C83196B00A1; Tue, 2 Jul 2024 03:42:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A8EAE6B009F for ; Tue, 2 Jul 2024 03:42:11 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5308B4204F for ; Tue, 2 Jul 2024 07:42:11 +0000 (UTC) X-FDA: 82294019262.15.7E89127 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf12.hostedemail.com (Postfix) with ESMTP id 6321340009 for ; Tue, 2 Jul 2024 07:42:09 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719906119; 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; bh=likc1OoFF4sJ/8dL2ldsTbUqEty9rFXNxiK3bWibi4o=; b=ZUApkavlJdu8lmbH4a4zVT09SGD4Z4RY7CybKTzVwF5bFN7T6x2ZacuVlump1Lp1sj/JOy nULFufkJPA7RJa0LTz3JlNSRAYeVuRo35z4fmmNAmOGpABUWzH/hMTFvkja6rsnjvDUa+I IoEzxbhXrI7nPIx99devePyejskBzlk= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719906119; a=rsa-sha256; cv=none; b=MRTfzzAwCOlItt1/0FV4sx4NmjkYnuPHacTSq3ckKnEk9Q7LInIupsdQxkAG8pyU9YX4q1 ORTvZbaa1itfNFTxttZ3sPVDkKEC2g/RPhnr8SRAx9izPC/4klIuBPRoLjUS1zHfZOrfWp 2sl/ZtNjesCCvgcPUsnJDBAjMHKYsfg= Received: by verein.lst.de (Postfix, from userid 2407) id 2D1EE68AFE; Tue, 2 Jul 2024 09:42:04 +0200 (CEST) Date: Tue, 2 Jul 2024 09:42:03 +0200 From: Christoph Hellwig To: "Pankaj Raghav (Samsung)" Cc: 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, mcgrof@kernel.org, gost.dev@samsung.com, cl@os.amperecomputing.com, linux-xfs@vger.kernel.org, hch@lst.de, Zi Yan Subject: Re: [PATCH v8 06/10] iomap: fix iomap_dio_zero() for fs bs > system page size Message-ID: <20240702074203.GA29410@lst.de> References: <20240625114420.719014-1-kernel@pankajraghav.com> <20240625114420.719014-7-kernel@pankajraghav.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240625114420.719014-7-kernel@pankajraghav.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 6321340009 X-Stat-Signature: 4tpibnst9jrud4w1zix17wq1dgcu55kh X-HE-Tag: 1719906129-568527 X-HE-Meta: U2FsdGVkX19vs6V5ZMrpbQDlOTGGhHeeQx6yDNY8c7kkM1vc9frxfsGQhINlZ4A9W0mZrVUkzvSDsC9gYLsRT4jUafAgs9J6zaEp5JHq42PSXF02O0Z9VSuRNv3EhHWN8nWFq3wAGSAIW0U+HJ6G8bmQt/p9fKcmHZQQ6Yb4NqQqT+P6XxrtAwaR6IzCP447nQYiRk1I2gfsZAyXoIS6rm7wOBsNKJeacm45qoJfYP79T6sQWWBBOF+XWWbYUBQY8a1XM7m0lTZC2Mn4SWAdTXMXQtRDeIZiHMD7w2tzpxaBg3GPqhYRHRBOTGzRp7I//vipTNqlw/jS303HigVPMp8Py2yLsdtTJ1hkyyCLzQx1peT8gnPImj+ZtWTX5/bw/Gb5QBhbYxQ9cph2Z/DItJn+WBzqOJLh2++Mqpg7uPRs62KlQP4+fDNYgaweejshuxi8h3sFXqfjVP/X8wk0IZy++4INpOB1AcCNEigNXbkY10PWrhRf2UXMtk6gsAivzKFlxK5eou20z+vhhWVCMyqFkrN5fmY/P2vl/Mw/Es2MZejeXD5xjzxYVi9Bm8QLUXc1w4RTXu0Q+KJjIuG2DFSARDLLcH8eutEVx5WQT5Y8FpqcHD5CN8OJWQMtNXCQhRbm1dDb1bybk3BIkcwCAIaNQT35SYcms0noIUdTjedxn5oS5SGE+/nNVcq9QFJFOnIPa3JUXhSPSp+MVVUIzlOYK5Uye0z9mMb0mmn7bgcMGG87OxZQuQnWZUcOKAeV7w57GzRAT3rXenJXN3cRPS02iWLJC2wU5xSzJBA1ut6qjioftg/JhQ+QgoU2XMdYOHRaScMEk9EtaFgE2GNvZ6vNU54PSimTFzEdA6UiGJuhqpqxOmLuzVzxn7tpAhanVPdz5qBFMLIkGK5+aZMfJ0kBJHFS4hva3QYuBHGjORYYEtI88/I+P2/l6bGO3/L4Ozc4I3Sl9SYkdGjRJtj nn9m1L4T 2SwF9SkoroeKXebmgAxLzOyqVpdAk5gVpiVBsIvAI1IhnVmdSCSR2D4J+iqgoZ/L/hs6AjURzPMK2x7ClO7h08ukXg3Trp7tbB6ST7cAcr4dU3vAmdEpNyUBnPA== 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, Jun 25, 2024 at 11:44:16AM +0000, Pankaj Raghav (Samsung) wrote: > -static int __init iomap_init(void) > +static int __init iomap_pagecache_init(void) > { > return bioset_init(&iomap_ioend_bioset, 4 * (PAGE_SIZE / SECTOR_SIZE), > offsetof(struct iomap_ioend, io_bio), > BIOSET_NEED_BVECS); > } > -fs_initcall(iomap_init); > +fs_initcall(iomap_pagecache_init); s/iomap_pagecache_init/iomap_buffered_init/ We don't use pagecache naming anywhere else in the file. > +/* > + * Used for sub block zeroing in iomap_dio_zero() > + */ > +#define ZERO_PAGE_64K_SIZE (65536) just use SZ_64K > +#define ZERO_PAGE_64K_ORDER (get_order(ZERO_PAGE_64K_SIZE)) No really point in having this. > +static struct page *zero_page_64k; This should be a folio. Encoding the size in the name is also really weird and just creates churn when we have to increase it. > + /* > + * Max block size supported is 64k > + */ > + WARN_ON_ONCE(len > ZERO_PAGE_64K_SIZE); A WARN_ON without actually erroring out here is highly dangerous. > + > bio = iomap_dio_alloc_bio(iter, dio, 1, REQ_OP_WRITE | REQ_SYNC | REQ_IDLE); Overly long line here. > + > +static int __init iomap_dio_init(void) > +{ > + zero_page_64k = alloc_pages(GFP_KERNEL | __GFP_ZERO, > + ZERO_PAGE_64K_ORDER); > + > + if (!zero_page_64k) > + return -ENOMEM; > + > + 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.