Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp167309rdg; Thu, 12 Oct 2023 01:59:55 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHuYoPUBwWo49+Qp8fdmnW7z0CRVmZvinifb2hbyTcSNWP6bLrmV4W1l8kE1TrasoAnWdGG X-Received: by 2002:a25:b1a0:0:b0:d9a:44dd:fe45 with SMTP id h32-20020a25b1a0000000b00d9a44ddfe45mr8041542ybj.49.1697101195517; Thu, 12 Oct 2023 01:59:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697101195; cv=none; d=google.com; s=arc-20160816; b=TkHKbjqsfcI+7zPVe8UqeHknozEzjAjG1eWCWHrVdnk7d0XpeG3MSam5lov3r2AKlP 1DVrg9qUeexMRywuD68b7RtSlOvgCMjI94ETuibYHcwmzcGepf3vu9z0yNuOb94lqkGz m3Gk99fq6UVfDQhUQVKW2eov0T2uhRBMfzMVNSSC11eRL4htJokChxTKgTNYbmyPpFQK xtfpEQWDcvOgehMnqMRmgn58NxRhfF82RVxwIroaFGxmbFKvMPHSRpWNVi+L5Qzq0tUm az1gGLOK/xGxAdTZhBOm5q0g+3+5OLI1IbetOt2U2mxObqSueQwb1jfMCHT7epqiddSH Hftg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=LyhFvv+qdLUo0ERrheeJqM4zIwaG8Gs3HwAf3WBBz00=; fh=xIyBEtf5c9l2fLbmVgffDXWkgf2Fk9ne5qKQ4RK8NBQ=; b=e1HUZLX8/dEUnj6oXEy2mDMMTH2P+TsqrMrwf/4VNptVoJfCc5xo+le5Qy6iFnWPFl 2Ln/NWsQOvuorEjKO2i5eVbNe61hnprV0V5wAWVNLGREmpHpeCbQrLYS75gGnUgQdeUL v+q7RYlLV83IH5pPjPfuPbtQ94fSjkHnbFddzEGyjujm5vqfoFML4H8wDoXKeEeu5bUg o0hg1Bcw0m/Ynz6A7LENmAvP6+bLfudzzqOT5VIIsneMak0A5g69qbNZuFmOh+9TPrr8 OZde6VMh93kRqaZNrXnfvW39UM5HvslPFMG9eXhe+cSZc5h6W7nDoTKWB3IkhHdTvg7h 2IQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=HOIzkyRt; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id q8-20020a056a00084800b0069338b22bfdsi14606058pfk.205.2023.10.12.01.59.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Oct 2023 01:59:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=HOIzkyRt; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 0FDB080B5A0F; Thu, 12 Oct 2023 01:59:54 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234147AbjJLI7m (ORCPT + 99 others); Thu, 12 Oct 2023 04:59:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234141AbjJLI7l (ORCPT ); Thu, 12 Oct 2023 04:59:41 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23CC590 for ; Thu, 12 Oct 2023 01:59:40 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 71A3921846; Thu, 12 Oct 2023 08:59:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1697101178; h=from:from:reply-to: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=LyhFvv+qdLUo0ERrheeJqM4zIwaG8Gs3HwAf3WBBz00=; b=HOIzkyRtj0xbVUMiRO2nW/gq07Oz1PjO5chP9RTofzr+6nPu2XJc8kgjk0MRGL9wfnNUPs j3exQC2+jrXWAsa801L/mZrIGVWXWOp42rvDPZr8iB3hFx09Bq02ZJEKNculf3BgZIgLEN swecHQ1ydnu03Gx4OXkdtoqJw7oZV18= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1697101178; h=from:from:reply-to: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=LyhFvv+qdLUo0ERrheeJqM4zIwaG8Gs3HwAf3WBBz00=; b=MdGoz8F+MPVQ+H/A9n8jZs5MtBBX2QJ72Nlz+7yZzIFEeHZkxwsPv2kUONTcI4777NKVhy y9EAe1nRo29XwvCw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 5D660139ED; Thu, 12 Oct 2023 08:59:38 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id kXrDFnq1J2VpXgAAMHmgww (envelope-from ); Thu, 12 Oct 2023 08:59:38 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id C582DA06B0; Thu, 12 Oct 2023 10:59:37 +0200 (CEST) Date: Thu, 12 Oct 2023 10:59:37 +0200 From: Jan Kara To: Dave Chinner Cc: Jan Kara , Ted Tso , linux-ext4@vger.kernel.org, "Ritesh Harjani (IBM)" , Gao Xiang Subject: Re: [PATCH] ext4: Properly sync file size update after O_SYNC direct IO Message-ID: <20231012085937.pzfsttumi6q4g3tm@quack3> References: <20231011142155.19328-1-jack@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: smtp-out1.suse.de; none X-Spam-Level: X-Spam-Score: -2.30 X-Spamd-Result: default: False [-2.30 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; BAYES_HAM(-0.20)[71.38%]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-3.00)[-1.000]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_SIGNED(0.00)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SUSPICIOUS_RECIPS(1.50)[]; FREEMAIL_CC(0.00)[suse.cz,mit.edu,vger.kernel.org,gmail.com,linux.alibaba.com] X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 12 Oct 2023 01:59:54 -0700 (PDT) On Thu 12-10-23 11:26:15, Dave Chinner wrote: > On Wed, Oct 11, 2023 at 04:21:55PM +0200, Jan Kara wrote: > > Gao Xiang has reported that on ext4 O_SYNC direct IO does not properly > > sync file size update and thus if we crash at unfortunate moment, the > > file can have smaller size although O_SYNC IO has reported successful > > completion. The problem happens because update of on-disk inode size is > > handled in ext4_dio_write_iter() *after* iomap_dio_rw() (and thus > > dio_complete() in particular) has returned and generic_file_sync() gets > > called by dio_complete(). Fix the problem by handling on-disk inode size > > update directly in our ->end_io completion handler. > > > > References: https://lore.kernel.org/all/02d18236-26ef-09b0-90ad-030c4fe3ee20@linux.alibaba.com > > Reported-by: Gao Xiang > > Signed-off-by: Jan Kara > > --- > > fs/ext4/file.c | 139 ++++++++++++++++++------------------------------- > > 1 file changed, 52 insertions(+), 87 deletions(-) > ..... > > @@ -388,9 +342,28 @@ static ssize_t ext4_handle_inode_extension(struct inode *inode, loff_t offset, > > */ > > if (inode->i_nlink) > > ext4_orphan_del(NULL, inode); > > + return; > > } > > + /* > > + * If i_disksize got extended due to writeback of delalloc blocks while > > + * the DIO was running we could fail to cleanup the orphan list in > > + * ext4_handle_inode_extension(). Do it now. > > + */ > > + if (!list_empty(&EXT4_I(inode)->i_orphan) && inode->i_nlink) { > > + handle_t *handle = ext4_journal_start(inode, EXT4_HT_INODE, 2); > > So this has to be called after the DIO write completes and calls > ext4_handle_inode_extension()? Yes, if the write was setup as extending one ('extend' is set to true in ext4_dio_write_iter()). > > @@ -606,9 +570,8 @@ static ssize_t ext4_dio_write_iter(struct kiocb *iocb, struct iov_iter *from) > > dio_flags, NULL, 0); > > if (ret == -ENOTBLK) > > ret = 0; > > - > > if (extend) > > - ret = ext4_handle_inode_extension(inode, offset, ret, count); > > + ext4_inode_extension_cleanup(inode, ret); > > Because this doesn't wait for AIO DIO to complete and actually > extend the file before running the cleanup code... As Gao wrote, ext4 sets IOMAP_DIO_FORCE_WAIT if 'extend' is set (see ext4_dio_write_checks()) so if we get to calling ext4_inode_extension_cleanup() we are guaranteed the IO has already completed. Honza -- Jan Kara SUSE Labs, CR