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 X-Spam-Level: X-Spam-Status: No, score=-14.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A84C6C43461 for ; Mon, 14 Sep 2020 17:05:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 66660205F4 for ; Mon, 14 Sep 2020 17:05:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600103147; bh=UlDZOmMEl82BvN+q3X8IemklTtPmKk+JfenhcMngvX4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=SVqn2XTsXxsSnL+ihQM2oBGy8dUz+3fTdSQfPDcwC9Rqh/ExPxCbSOJlqeR8+zbgp oV3m5QedoEJWYHreAJh3UOBffP8rEKLKmrjVK4YUBfGUQZxjbnWKfFHJ3MjiGQduPI 2vnR85WGrIg5JP78dDQObCC68dpQKpx3f6tHeB2M= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726296AbgINRFo (ORCPT ); Mon, 14 Sep 2020 13:05:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:60272 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726056AbgINNFZ (ORCPT ); Mon, 14 Sep 2020 09:05:25 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F2D4422224; Mon, 14 Sep 2020 13:04:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600088667; bh=UlDZOmMEl82BvN+q3X8IemklTtPmKk+JfenhcMngvX4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=F1IWvkgimFUR0ligA4bzBswGaQ2PmdvgMaRTAlMynnyTMMzWiVLBMFacmdSKZ2s3B wKcBpBA2Nl5yYRk1F+3wacicFKPg9zD4i/CNfL3IQ2gFvpt8gTS3zTYuUwW+wu9QRz v2JokThZ2X0taqPFBg4XJ6A6sTSNZzQlgSxhUEIU= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gabriel Krisman Bertazi , Chao Yu , Jaegeuk Kim , Sasha Levin , linux-f2fs-devel@lists.sourceforge.net Subject: [PATCH AUTOSEL 5.8 24/29] f2fs: Return EOF on unaligned end of file DIO read Date: Mon, 14 Sep 2020 09:03:53 -0400 Message-Id: <20200914130358.1804194-24-sashal@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200914130358.1804194-1-sashal@kernel.org> References: <20200914130358.1804194-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Gabriel Krisman Bertazi [ Upstream commit 20d0a107fb35f37578b919f62bd474d6d358d579 ] Reading past end of file returns EOF for aligned reads but -EINVAL for unaligned reads on f2fs. While documentation is not strict about this corner case, most filesystem returns EOF on this case, like iomap filesystems. This patch consolidates the behavior for f2fs, by making it return EOF(0). it can be verified by a read loop on a file that does a partial read before EOF (A file that doesn't end at an aligned address). The following code fails on an unaligned file on f2fs, but not on btrfs, ext4, and xfs. while (done < total) { ssize_t delta = pread(fd, buf + done, total - done, off + done); if (!delta) break; ... } It is arguable whether filesystems should actually return EOF or -EINVAL, but since iomap filesystems support it, and so does the original DIO code, it seems reasonable to consolidate on that. Signed-off-by: Gabriel Krisman Bertazi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin --- fs/f2fs/data.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 6e9017e6a8197..403e8033c974b 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -3463,6 +3463,9 @@ static int check_direct_IO(struct inode *inode, struct iov_iter *iter, unsigned long align = offset | iov_iter_alignment(iter); struct block_device *bdev = inode->i_sb->s_bdev; + if (iov_iter_rw(iter) == READ && offset >= i_size_read(inode)) + return 1; + if (align & blocksize_mask) { if (bdev) blkbits = blksize_bits(bdev_logical_block_size(bdev)); -- 2.25.1 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 X-Spam-Level: X-Spam-Status: No, score=-12.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1BBD2C433E2 for ; Mon, 14 Sep 2020 13:04:51 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9D69E21D1A; Mon, 14 Sep 2020 13:04:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="TwxEaDgu"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="drXTFlNb"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="F1IWvkgi" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D69E21D1A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kHoA2-0000yb-4L; Mon, 14 Sep 2020 13:04:46 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kHoA1-0000yM-GO for linux-f2fs-devel@lists.sourceforge.net; Mon, 14 Sep 2020 13:04:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:MIME-Version:References: In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=S8sVGHxKj0qCeiRJKzmuvxLj/6219GdjvkgIW4bLW6U=; b=TwxEaDguFyEDpZ6+lHKCpW8pEw D9KyYYX7YCkeCkgZqzVrSGOikH5kkQxZBQdr6FT+PCSPQk9Eo9Ei/ZoFTPY71bIZPWOzSkp8FW7wc dLSHHwe9nQ0kTftZHGn0ceTmbPAfOMAhg/A95nQ0zgZYIPVRb6rXDID0sJnv7pLU2MAs=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id: Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=S8sVGHxKj0qCeiRJKzmuvxLj/6219GdjvkgIW4bLW6U=; b=drXTFlNbZj2p/obzAHujdqEPRn jLEhOzuZnelEBxw5q8UU7CnaTH1BqgNBPS6B7x8cVOWwMj1742j7dYMuPoJ8/Qubc6/YQjbBOZJ7S Rc1WjLUe+lwokW0lY6pvkdSpGOR/Cjg67ti7maoHDEYyXEWG5UJmghHz4tjp/WWiJQu4=; Received: from mail.kernel.org ([198.145.29.99]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1kHo9p-009A29-US for linux-f2fs-devel@lists.sourceforge.net; Mon, 14 Sep 2020 13:04:45 +0000 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F2D4422224; Mon, 14 Sep 2020 13:04:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600088667; bh=UlDZOmMEl82BvN+q3X8IemklTtPmKk+JfenhcMngvX4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=F1IWvkgimFUR0ligA4bzBswGaQ2PmdvgMaRTAlMynnyTMMzWiVLBMFacmdSKZ2s3B wKcBpBA2Nl5yYRk1F+3wacicFKPg9zD4i/CNfL3IQ2gFvpt8gTS3zTYuUwW+wu9QRz v2JokThZ2X0taqPFBg4XJ6A6sTSNZzQlgSxhUEIU= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Date: Mon, 14 Sep 2020 09:03:53 -0400 Message-Id: <20200914130358.1804194-24-sashal@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200914130358.1804194-1-sashal@kernel.org> References: <20200914130358.1804194-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-Headers-End: 1kHo9p-009A29-US Subject: [f2fs-dev] [PATCH AUTOSEL 5.8 24/29] f2fs: Return EOF on unaligned end of file DIO read X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sasha Levin , Jaegeuk Kim , Gabriel Krisman Bertazi , linux-f2fs-devel@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net From: Gabriel Krisman Bertazi [ Upstream commit 20d0a107fb35f37578b919f62bd474d6d358d579 ] Reading past end of file returns EOF for aligned reads but -EINVAL for unaligned reads on f2fs. While documentation is not strict about this corner case, most filesystem returns EOF on this case, like iomap filesystems. This patch consolidates the behavior for f2fs, by making it return EOF(0). it can be verified by a read loop on a file that does a partial read before EOF (A file that doesn't end at an aligned address). The following code fails on an unaligned file on f2fs, but not on btrfs, ext4, and xfs. while (done < total) { ssize_t delta = pread(fd, buf + done, total - done, off + done); if (!delta) break; ... } It is arguable whether filesystems should actually return EOF or -EINVAL, but since iomap filesystems support it, and so does the original DIO code, it seems reasonable to consolidate on that. Signed-off-by: Gabriel Krisman Bertazi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin --- fs/f2fs/data.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 6e9017e6a8197..403e8033c974b 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -3463,6 +3463,9 @@ static int check_direct_IO(struct inode *inode, struct iov_iter *iter, unsigned long align = offset | iov_iter_alignment(iter); struct block_device *bdev = inode->i_sb->s_bdev; + if (iov_iter_rw(iter) == READ && offset >= i_size_read(inode)) + return 1; + if (align & blocksize_mask) { if (bdev) blkbits = blksize_bits(bdev_logical_block_size(bdev)); -- 2.25.1 _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel