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 593C9C25B76 for ; Tue, 11 Jun 2024 09:41:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D9AAF6B0099; Tue, 11 Jun 2024 05:41:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D23DB6B009A; Tue, 11 Jun 2024 05:41:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B9DF06B009B; Tue, 11 Jun 2024 05:41:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 993426B0099 for ; Tue, 11 Jun 2024 05:41:50 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id DFDD81412B2 for ; Tue, 11 Jun 2024 09:41:49 +0000 (UTC) X-FDA: 82218115938.03.80903B5 Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) by imf30.hostedemail.com (Postfix) with ESMTP id 6AD6F80003 for ; Tue, 11 Jun 2024 09:41:47 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=d95O85Gn; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf30.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.161 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718098908; 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=zbkiOeCEyPQu0nf19vXRe22PR52sb7jygcpNN/dtAno=; b=Z5/bVlDMs0BUmyeCDE9ntI2kCbCwfT3TQzO0Yr0r0l6g7Akykr4mTHM0Acow2RKvKja0eS Nd6Uig2n8SEp7kkQjaqdT64/14gSfMelmrrv+9Vp1VADd0DjEZmRxPrq6NQ1fAn6045wSL ALIQ7Qm78xcIxU9jYJoun8nkVr/EeIo= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=d95O85Gn; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf30.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.161 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718098908; a=rsa-sha256; cv=none; b=tshpxj72SL+32+nB/djR3LUFUKvGg523KFucYoPYlgAoZ+2m2krIfFBGbNC7nsBaU0tzHm eTnpTbwgz+4ltFdDPvUi3sTt/x79SFNCgZSw7PlVfDMO0F/2knFLAjucWoYnsTvCj84nXW tKu/RmF4lMwLcJISRal7ZTKOoqjwaXw= Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4Vz3bV1zx3z9sGf; Tue, 11 Jun 2024 11:41:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1718098902; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zbkiOeCEyPQu0nf19vXRe22PR52sb7jygcpNN/dtAno=; b=d95O85GnokMrBOReY4l/P1SXMB5K0c089lZGv3kW963gYYVhEPxc4qUr4cnBcUibeImrTy 4dmvTMoKr96fPVR6lU6b6nEdupU/yE88lTZfIzJzUl0kK60oWw5MT0S6p/oUUeLAMLHnZx eXOvUop11JoBAKgsWMEX+mqJoneMBs5tQZFWYOtaSQyntZUr51DFhjmdXkAsXENbkjtl3Z ZbZQqEWx1tI9pKSLYFEYpmVhuLq1/+WqqPQeMkK/kM/1VhDgQKspLucK1INMEIl3i2cnE7 5GIouw9U+4n5+sxPh6Iv1SvVFrSCMmyZWL04TVpYPrcp3d3ieFeoS2vNHcYgPg== Date: Tue, 11 Jun 2024 09:41:37 +0000 From: "Pankaj Raghav (Samsung)" To: John Garry Cc: david@fromorbit.com, djwong@kernel.org, chandan.babu@oracle.com, brauner@kernel.org, akpm@linux-foundation.org, willy@infradead.org, mcgrof@kernel.org, linux-mm@kvack.org, hare@suse.de, linux-kernel@vger.kernel.org, yang@os.amperecomputing.com, Zi Yan , linux-xfs@vger.kernel.org, p.raghav@samsung.com, linux-fsdevel@vger.kernel.org, hch@lst.de, gost.dev@samsung.com, cl@os.amperecomputing.com Subject: Re: [PATCH v7 07/11] iomap: fix iomap_dio_zero() for fs bs > system page size Message-ID: <20240611094137.vxuhldj4b3qslsdj@quentin> References: <20240607145902.1137853-1-kernel@pankajraghav.com> <20240607145902.1137853-8-kernel@pankajraghav.com> <4c6e092d-5580-42c8-9932-b42995e914be@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4c6e092d-5580-42c8-9932-b42995e914be@oracle.com> X-Rspamd-Queue-Id: 6AD6F80003 X-Stat-Signature: r1xshfdy3egdrp7fnzcp74h5zh56j5ar X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1718098907-843425 X-HE-Meta: U2FsdGVkX18muvtBqDBwkYvu9NAIPfUfyANiB4ktz/o99bJDAS3NaEay8V9tk9T5txYH4y67QVPNNQTeHE0asCW5tehMIbxaQzG5weC4l58N61GHWiIijQQ11PHtt6+QojnR6kCDBBpUyZNLG73IZf08etKb38tc5r54rNBrEqUiObd7dOrITLqT9BOhOInftTBeLRjnWXgj9hZGE4JyvnDF9mPbn8DoS6kykurbFwGco/9rbvDIkErLMmiNUCy7tjMFQiMRz43jg7vAeqdCr6HCjD1oqL5lKHUSWy4ooKdLh9d042r7jElrRay5A2l3NY1RZ4o2sA1LmSvMpeoAXxAWPACEDjG1VR4YqeKf5JztRrRIgXduhGAuwn015t0pLPNEvPXGcH8uhsHiAdWF23rB8a74e4HjOa9ANmpHxLXswhSxYTBrdLgoAfPDP2t5XGMuczO1Y+bsYH9g50sqqNxBpV+H2hR6laFy+vtE9laZ4X1mebsJAoiTMbfWQ0h0aSxiwGZ4bKjjMS/tKBsIopBRIiMMM6nos+umkB3Vt8SCObOSIvHfXndjOSMKjF25lgKwIV+7UyCX8rrPslpnLHRkR0I6YjrV7fL5w8uWpH5aX2VCJ0FIx+La2rLtyJSUWU0fsuIrFAlgArGES+KCGU8ZFX/vZ37dxLUnjtVAL/jauyCg/wD7+qpFkBpdNTIbVi0TCAbfiMU579JvyhKzB9dwspKP1XuVr72ZdNPW1GaWUwyTR/hVD7EEjIan7bxo4I70TdjBQjyzlgsOzqGP+w8Ma3fxJLcYhrntNl2vv642wbbC6k5WSXsLUs0L86IAFro4HnMPmaE3NKfU+0wBaAntG6iOy7xImUPA1wD0D05oxEn2pvb8jkbxjYGOC/YIUpPtY2WJHnRWxHP1298KcdabM7vODgpoToROR4a//ohuQwHiWKCUSl9uJU7oWBPhzaPrjccEZXfxi//jozY 4FoG9MqT trWIdS4Vs0Sxe5NqpY34Su/fN77xD3FqhnjAaUUnySiamJZ1qCpmzKmUOwJ5Md/3yLmcUwGxqS4lPj0NqBN/swycaO7GoK9jWQ4nXa5wycJpGhrKelPZlmXxFbeFEPq3PcMpX3F9tQ/TN+Qj5EUoYFCjynwfCA5Gvncf9Pb0f2bhKszJ34ASYFcEnKxriIpkz5wuiJ1YAJaQ0kg45ZAedeqIlZXH2QPEdx6e/siWKR3a7IAgOR/ucmLcWtow/gMvTV1Ud0ZVC1WY/Ev7COMKh27FRf4JNvzMA5muR/jrzb6XfyIMCUytHby0IUipG7ictFIpFBfttd6tn3oc1LEeNdAW9RJKoJ2RquqDOaePrLsB8wHsynIb+T7Adxa/A09w18hgE 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: > > index 49938419fcc7..9f791db473e4 100644 > > --- a/fs/iomap/buffered-io.c > > +++ b/fs/iomap/buffered-io.c > > @@ -1990,6 +1990,12 @@ EXPORT_SYMBOL_GPL(iomap_writepages); > > static int __init iomap_init(void) > > { > > + int ret; > > + > > + ret = iomap_dio_init(); > > + if (ret) > > + return ret; > > + > > return bioset_init(&iomap_ioend_bioset, 4 * (PAGE_SIZE / SECTOR_SIZE), > > offsetof(struct iomap_ioend, io_bio), > > BIOSET_NEED_BVECS); > > I suppose that it does not matter that zero_fs_block is leaked if this fails > (or is it even leaked?), as I don't think that failing that bioset_init() > call is handled at all. If bioset_init fails, then we have even more problems than just a leaked 64k memory? ;) Do you have something like this in mind? diff --git a/fs/internal.h b/fs/internal.h index 30217f0ff4c6..def96c7ed9ea 100644 --- a/fs/internal.h +++ b/fs/internal.h @@ -39,6 +39,7 @@ int __block_write_begin_int(struct folio *folio, loff_t pos, unsigned len, * iomap/direct-io.c */ int iomap_dio_init(void); +void iomap_dio_exit(void); /* * char_dev.c diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index 9f791db473e4..8d8b9e62201f 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -1994,10 +1994,16 @@ static int __init iomap_init(void) ret = iomap_dio_init(); if (ret) - return ret; + goto out; - return bioset_init(&iomap_ioend_bioset, 4 * (PAGE_SIZE / SECTOR_SIZE), + ret = bioset_init(&iomap_ioend_bioset, 4 * (PAGE_SIZE / SECTOR_SIZE), offsetof(struct iomap_ioend, io_bio), BIOSET_NEED_BVECS); + if (!ret) + goto out; + + iomap_dio_exit(); +out: + return ret; } fs_initcall(iomap_init); diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index b95600b254a3..f4c9445ca50d 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -69,6 +69,12 @@ int iomap_dio_init(void) return 0; } +void iomap_dio_exit(void) +{ + __free_pages(zero_fs_block, ZERO_FSB_ORDER); + +} + static struct bio *iomap_dio_alloc_bio(const struct iomap_iter *iter, struct iomap_dio *dio, unsigned short nr_vecs, blk_opf_t opf) { > > > + > > static struct bio *iomap_dio_alloc_bio(const struct iomap_iter *iter, > > struct iomap_dio *dio, unsigned short nr_vecs, blk_opf_t opf) > > { > > @@ -236,17 +253,22 @@ static void iomap_dio_zero(const struct iomap_iter *iter, struct iomap_dio *dio, > > loff_t pos, unsigned len) > > { > > struct inode *inode = file_inode(dio->iocb->ki_filp); > > - struct page *page = ZERO_PAGE(0); > > struct bio *bio; > > + /* > > + * Max block size supported is 64k > > + */ > > + WARN_ON_ONCE(len > ZERO_FSB_SIZE); > > JFYI, As mentioned in https://lore.kernel.org/linux-xfs/20240429174746.2132161-1-john.g.garry@oracle.com/T/#m5354e2b2531a5552a8b8acd4a95342ed4d7500f2, > we would like to support an arbitrary size. Maybe I will need to loop for > zeroing sizes > 64K. The initial patches were looping with a ZERO_PAGE(0), but the initial feedback was to use a huge zero page. But when I discussed that at LSF, the people thought we will be using a lot of memory for sub-block memory, especially on architectures with 64k base page size. So for now a good tradeoff between memory usage and efficiency was to use a 64k buffer as that is the maximum FSB we support.[1] IIUC, you will be using this function also to zero out the extent and not just a FSB? I think we could resort to looping until we have a way to request arbitrary zero folios without having to allocate at it in iomap_dio_alloc_bio() for every IO. [1] https://lore.kernel.org/linux-xfs/20240529134509.120826-8-kernel@pankajraghav.com/ -- Pankaj