From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751050AbdAXOa2 (ORCPT ); Tue, 24 Jan 2017 09:30:28 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:50180 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750857AbdAXOa1 (ORCPT ); Tue, 24 Jan 2017 09:30:27 -0500 Subject: Re: [PATCH 1/1 linux-next] jfs: atomically read inode size To: Fabian Frederick References: <20170123175023.1076-1-fabf@skynet.be> <1530699262.895610.1485201121820.open-xchange@webmail.nmp.proximus.be> Cc: linux-kernel@vger.kernel.org, jfs-discussion@lists.sourceforge.net From: Dave Kleikamp Message-ID: <65889b39-44d0-e501-0bd6-8b8243bac85c@oracle.com> Date: Tue, 24 Jan 2017 08:30:11 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1530699262.895610.1485201121820.open-xchange@webmail.nmp.proximus.be> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/23/2017 01:52 PM, Fabian Frederick wrote: > > >> On 23 January 2017 at 19:43 Dave Kleikamp wrote: >> >> >> On 01/23/2017 11:50 AM, Fabian Frederick wrote: >>> See i_size_read() comments in include/linux/fs.h >> >> Is this fixing a real problem? Can the bd_inode size change while we're >> mounting or resizing the filesystem? >> > > Behind good locking, there should be no problem. > I made some patches like this to use read operation to remove any > ambiguity. There are a lot of places where i_size_read/write is used for bd_inode, so I'll go ahead and take this patch for consistency of the code. Thanks, Shaggy > > Regards, > Fabian > >>> >>> Signed-off-by: Fabian Frederick >>> --- >>> fs/jfs/resize.c | 4 ++-- >>> fs/jfs/super.c | 4 ++-- >>> 2 files changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/fs/jfs/resize.c b/fs/jfs/resize.c >>> index bd9b641..7ddcb44 100644 >>> --- a/fs/jfs/resize.c >>> +++ b/fs/jfs/resize.c >>> @@ -98,7 +98,7 @@ int jfs_extendfs(struct super_block *sb, s64 newLVSize, >>> int newLogSize) >>> goto out; >>> } >>> >>> - VolumeSize = sb->s_bdev->bd_inode->i_size >> sb->s_blocksize_bits; >>> + VolumeSize = i_size_read(sb->s_bdev->bd_inode) >> sb->s_blocksize_bits; >>> >>> if (VolumeSize) { >>> if (newLVSize > VolumeSize) { >>> @@ -211,7 +211,7 @@ int jfs_extendfs(struct super_block *sb, s64 newLVSize, >>> int newLogSize) >>> txQuiesce(sb); >>> >>> /* Reset size of direct inode */ >>> - sbi->direct_inode->i_size = sb->s_bdev->bd_inode->i_size; >>> + sbi->direct_inode->i_size = i_size_read(sb->s_bdev->bd_inode); >>> >>> if (sbi->mntflag & JFS_INLINELOG) { >>> /* >>> diff --git a/fs/jfs/super.c b/fs/jfs/super.c >>> index c64c257..ad02f00 100644 >>> --- a/fs/jfs/super.c >>> +++ b/fs/jfs/super.c >>> @@ -283,7 +283,7 @@ static int parse_options(char *options, struct >>> super_block *sb, s64 *newLVSize, >>> } >>> case Opt_resize_nosize: >>> { >>> - *newLVSize = sb->s_bdev->bd_inode->i_size >> >>> + *newLVSize = i_size_read(sb->s_bdev->bd_inode) >> >>> sb->s_blocksize_bits; >>> if (*newLVSize == 0) >>> pr_err("JFS: Cannot determine volume size\n"); >>> @@ -549,7 +549,7 @@ static int jfs_fill_super(struct super_block *sb, void >>> *data, int silent) >>> goto out_unload; >>> } >>> inode->i_ino = 0; >>> - inode->i_size = sb->s_bdev->bd_inode->i_size; >>> + inode->i_size = i_size_read(sb->s_bdev->bd_inode); >>> inode->i_mapping->a_ops = &jfs_metapage_aops; >>> hlist_add_fake(&inode->i_hash); >>> mapping_set_gfp_mask(inode->i_mapping, GFP_NOFS); >>>