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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2A38C43217 for ; Fri, 11 Feb 2022 06:13:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345149AbiBKGNu (ORCPT ); Fri, 11 Feb 2022 01:13:50 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:54976 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344576AbiBKGN3 (ORCPT ); Fri, 11 Feb 2022 01:13:29 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F4F055BB; Thu, 10 Feb 2022 22:13:29 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BFC5A61888; Fri, 11 Feb 2022 06:13:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F763C340E9; Fri, 11 Feb 2022 06:13:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644560008; bh=jpGDy6Iy7Lo9fogGzTmc2GQJ7sIvAivYezF205RJ4lY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C5oljZ81biLnBS5BIZSFLCaQNbO8BT9flCghj93ZNPYevL2x97V9cL70f+0OTjZB7 YaDQg0DWg6jqiDXl1xm3/0SccUH/08SSwJPra1x34o4LMY4jbEoJWsemamfzGtJJtc tIOWVjkWq7tfX9djN2zl686fTjTGvfsiq62KC6AxEpmFTskaZ4Zap5qAvBLHmvB8YU n1aSA8NrdBc0Dc8jWEpVtlOnkFJlCDiyZdxoPp9bzsAWIZ2JKGokceWj72XsMImzTd bmoEMCO52S7A8djx05UFxNFaKLHEEt/Q4KUITmwr97YiVaIW3ibM+rANlmQqXfWiU4 xpVwFf2mNlHdg== From: Eric Biggers To: linux-fsdevel@vger.kernel.org Cc: linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, linux-api@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH 5/7] f2fs: don't allow DIO reads but not DIO writes Date: Thu, 10 Feb 2022 22:11:56 -0800 Message-Id: <20220211061158.227688-6-ebiggers@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220211061158.227688-1-ebiggers@kernel.org> References: <20220211061158.227688-1-ebiggers@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org From: Eric Biggers Currently, if an f2fs filesystem is mounted with the mode=lfs and io_bits mount options, DIO reads are allowed but DIO writes are not. Allowing DIO reads but not DIO writes is an unusual restriction, which is likely to be surprising to applications, namely any application that both reads and writes from a file (using O_DIRECT). Given this, let's drop the support for DIO reads in this configuration. Signed-off-by: Eric Biggers --- fs/f2fs/file.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 26c51517c2a30..61ff0fc16e160 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -822,7 +822,6 @@ static inline bool f2fs_force_buffered_io(struct inode *inode, struct kiocb *iocb, struct iov_iter *iter) { struct f2fs_sb_info *sbi = F2FS_I_SB(inode); - int rw = iov_iter_rw(iter); if (!fscrypt_dio_supported(inode)) return true; @@ -840,7 +839,7 @@ static inline bool f2fs_force_buffered_io(struct inode *inode, */ if (f2fs_sb_has_blkzoned(sbi)) return true; - if (f2fs_lfs_mode(sbi) && (rw == WRITE)) { + if (f2fs_lfs_mode(sbi)) { if (block_unaligned_IO(inode, iocb, iter)) return true; if (F2FS_IO_ALIGNED(sbi)) -- 2.35.1