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 1F5C7C27C53 for ; Wed, 12 Jun 2024 20:40:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 59CE96B008C; Wed, 12 Jun 2024 16:40:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 54C6C6B0092; Wed, 12 Jun 2024 16:40:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 414356B0093; Wed, 12 Jun 2024 16:40:30 -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 255A66B008C for ; Wed, 12 Jun 2024 16:40:30 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C64801A0449 for ; Wed, 12 Jun 2024 20:40:29 +0000 (UTC) X-FDA: 82223404578.12.BAD07C0 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id 187D74000A for ; Wed, 12 Jun 2024 20:40:27 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=oWWFMwJk; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718224828; a=rsa-sha256; cv=none; b=BClr+Mc3suLrCG06bHmDlTWkYdbzz6UwTvCY58pHL64SZGgeCsqb757qJ/mnOgoMsoRPPu zOQO09WmI4XFTsda2sUhXE3Scg4Va2NDuDd+icMTMGkL5tibgn5sEH0DoVsF8VoMBNTSrW WWRLoaI4u5VridkyWi/G9WK7TB+FqxU= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=oWWFMwJk; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718224828; 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=DZE6xddVU8XcLM3zwZVAbsPDLenBgPtBjNPVYhd+674=; b=hcnZb65i0s4tao+QEEen6MCgRHLegDVgjC+EvtUR79KttruTZVZZkLWllMYEY+6p6bCRzc yI8j1w3xi4EYWMAXgpvMmJbcg/6nit3bhydS5qB60lHnDHosNs4PY3EOmyhyCwWlhBBd5l dz95cYU2gSFF3s5tQjwpGiHkh9nyV/o= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id E885460AE6; Wed, 12 Jun 2024 20:40:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 924EAC116B1; Wed, 12 Jun 2024 20:40:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718224826; bh=SZUB4FY1/4Uc5DKQFanz8Q8mDAcnM64BMP2Z067yeq0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oWWFMwJk0F9C3vPy/4z2yYg/eBLF+FDqdqcufPDLGeU8cFFPlTKiAs2n6JlGmxRD2 6oTW1oVv0iBpWPUT6/LJhqVwVwqtG3i9Vqa43TQ5Rj7n4LD9HHG0DYwUwJM471gczc gnhRVFJ/gGVIrjBH8mzkO02ZGbaendNNx8ww597L6QIKrXVEjchj4S3icJ74AIHUSy YaIkyj2jvGICtBcPxklwL4AVOJ+3aBNCwgqSFdv2mKNyfMxEQyIqLeNbZeB0riMtA8 zcj1Fm9Tc4/uBw2kZbker/r8V1tydETAnhQOKiLYmXyVOTpeFFUWiwEIRoq/8ObKCb cK5S5yPFwZEwQ== Date: Wed, 12 Jun 2024 13:40:25 -0700 From: "Darrick J. Wong" To: "Pankaj Raghav (Samsung)" Cc: david@fromorbit.com, 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, john.g.garry@oracle.com Subject: Re: [PATCH v7 07/11] iomap: fix iomap_dio_zero() for fs bs > system page size Message-ID: <20240612204025.GI2764752@frogsfrogsfrogs> References: <20240607145902.1137853-1-kernel@pankajraghav.com> <20240607145902.1137853-8-kernel@pankajraghav.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240607145902.1137853-8-kernel@pankajraghav.com> X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 187D74000A X-Stat-Signature: ftusmtupugp5ijusy491fs675jikk6kf X-HE-Tag: 1718224827-879039 X-HE-Meta: U2FsdGVkX18RttuxJuGjRY8BrODoliwzohpDeNdijWHtdNlXWV7UazfC0GKDQGGzRhuOEPHkSP2mRluUnj0VR691hicGTs4hQvRexRGT6uCxoixJ/Iq8ZkUAgDPedUTZLgcZLdepQDf/EmYfLlPbUb69oovhnNPfOsvreU8/xPMdkUMo53gLhdVwGbn4pk3lQUUpEOwu6TjWs7tVF/c3xdWPDiW6/g6fdw4e4y189LqTuhvkjQp3jhhp41KA0FIwLvWKBUt3Ssn0eRwf3VBVdv54FG6/UOWTgMG6CRFwOkFEljihxouP+XSCEhamLQk0kNTwfw3hLjC+yFi0Rul4YR0t77D9w+F9rvc+hAb5kyvrGYRDZIgQgXO+5CD4gYaIqjz6sqcaR0qXGAXaZP8Q/Z9TxizoQ7un3QocVJR9YKnhzZ+2tYW8Ibmgymg/f3sIzn1N6dLicesBhsYK1W3hA8oi3Ea0z99IKQQHPCRjrFSVug3EY6xl3ZV9RSVd62HrP21ylJITASFQ89IaXJ2hnDomKuZflpDYwxDhVczoCfk33XGpciyyMpzCRbsJBJq5ul0kqr5jyd8I3HqLJ03FFp/TPM35/GsP595hVKooDDUKBB7D1SLL8LBHVOK0wa45a5x0qyj4i0CthdatZbmPDpzRADyM8l7kjUbkiNQlwCquK0lSMUrUC5SI+p5sPC6LG1kEMfWRoZuY5B8aMClVJYJfWKkrvJcogQaP/GFUwUZ1rAY6HD555RmPT1mVoMvcwU6f09GX/nwd0XK8mGNh4fSWc06RjdpDKxAM4pWQ0PObvoGtX1hGfxJEubKMROXc4xfCk7ySStpB6ZT8XJTEJIljKmNdL2Lb5VDsgSJX9Rgv9CJZlzu7U9BWp6hRjkAHlqiHcFyQRen6UIJUcq3I8UDvLuNRGUM7lY4z3A816W0oiGq+W34ahlsS7WHq8uMNJBiAOHPX2xFfB7IDgEN Vk/TKhIy ADTL/i7TTA3DR7zDfIYOJaOfSzGv1sY/hDCwI7B9BNAvrm5pdPeQ1UTiQxo4QzZiwROOgXLC2/35iLGPi08og2q7dcjr308cY8CAb5EIyF8FSu2QZ/3ZMr6YybDMxDvR49gMNpEMYR6V3Ya6NskKp2NYTVNW8dVJMeHP0fE4fqKqX50IjgiAsvVmocGBFOiSpEbh05fKpgm19dgrNOSNrCfixr4iSTCGkOjKBMm5fjZu1F5UBqGf4QD2L4rkoYah3TNUL41r+edBrUbR5+8iln6V4pS9JgR6u5o7Hf3YaaRR/nVU= 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 Fri, Jun 07, 2024 at 02:58:58PM +0000, Pankaj Raghav (Samsung) wrote: > From: Pankaj Raghav > > iomap_dio_zero() will pad a fs block with zeroes if the direct IO size > < fs block size. iomap_dio_zero() has an implicit assumption that fs block > size < page_size. This is true for most filesystems at the moment. > > If the block size > page size, this will send the contents of the page > next to zero page(as len > PAGE_SIZE) to the underlying block device, > causing FS corruption. > > iomap is a generic infrastructure and it should not make any assumptions > about the fs block size and the page size of the system. > > Signed-off-by: Pankaj Raghav > Reviewed-by: Hannes Reinecke > --- > fs/internal.h | 5 +++++ > fs/iomap/buffered-io.c | 6 ++++++ > fs/iomap/direct-io.c | 26 ++++++++++++++++++++++++-- > 3 files changed, 35 insertions(+), 2 deletions(-) > > diff --git a/fs/internal.h b/fs/internal.h > index 84f371193f74..30217f0ff4c6 100644 > --- a/fs/internal.h > +++ b/fs/internal.h > @@ -35,6 +35,11 @@ static inline void bdev_cache_init(void) > int __block_write_begin_int(struct folio *folio, loff_t pos, unsigned len, > get_block_t *get_block, const struct iomap *iomap); > > +/* > + * iomap/direct-io.c > + */ > +int iomap_dio_init(void); > + > /* > * char_dev.c > */ > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > 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); > diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c > index f3b43d223a46..b95600b254a3 100644 > --- a/fs/iomap/direct-io.c > +++ b/fs/iomap/direct-io.c > @@ -27,6 +27,13 @@ > #define IOMAP_DIO_WRITE (1U << 30) > #define IOMAP_DIO_DIRTY (1U << 31) > > +/* > + * Used for sub block zeroing in iomap_dio_zero() > + */ > +#define ZERO_FSB_SIZE (65536) > +#define ZERO_FSB_ORDER (get_order(ZERO_FSB_SIZE)) > +static struct page *zero_fs_block; Er... zero_page_64k ? Since it's a permanent allocation, can we also mark the memory ro? > + > struct iomap_dio { > struct kiocb *iocb; > const struct iomap_dio_ops *dops; > @@ -52,6 +59,16 @@ struct iomap_dio { > }; > }; > > +int iomap_dio_init(void) > +{ > + zero_fs_block = alloc_pages(GFP_KERNEL | __GFP_ZERO, ZERO_FSB_ORDER); > + > + if (!zero_fs_block) > + return -ENOMEM; > + > + return 0; > +} Can't we just turn this into another fs_initcall() instead of exporting it just so we can call it from iomap_init? And maybe rename the existing iomap_init to iomap_pagecache_init or something, for clarity's sake? --D > + > 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); > + > bio = iomap_dio_alloc_bio(iter, dio, 1, REQ_OP_WRITE | REQ_SYNC | REQ_IDLE); > fscrypt_set_bio_crypt_ctx(bio, inode, pos >> inode->i_blkbits, > GFP_KERNEL); > + > bio->bi_iter.bi_sector = iomap_sector(&iter->iomap, pos); > bio->bi_private = dio; > bio->bi_end_io = iomap_dio_bio_end_io; > > - __bio_add_page(bio, page, len, 0); > + __bio_add_page(bio, zero_fs_block, len, 0); > iomap_dio_submit_bio(iter, dio, bio, pos); > } > > -- > 2.44.1 > >