| Message ID | 1443449479-5379-1-git-send-email-bywxiaobai@163.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi I suppose that you should remove the function new_valid_dev at all. Mikulas On Mon, 28 Sep 2015, Yaowei Bai wrote: > As new_valid_dev always returns 1, so !new_valid_dev check is not > needed, remove it. > > Signed-off-by: Yaowei Bai <bywxiaobai@163.com> > --- > fs/hpfs/namei.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/fs/hpfs/namei.c b/fs/hpfs/namei.c > index 9e92c9c..ae4d5a1 100644 > --- a/fs/hpfs/namei.c > +++ b/fs/hpfs/namei.c > @@ -227,8 +227,6 @@ static int hpfs_mknod(struct inode *dir, struct dentry *dentry, umode_t mode, de > int err; > if ((err = hpfs_chk_name(name, &len))) return err==-ENOENT ? -EINVAL : err; > if (hpfs_sb(dir->i_sb)->sb_eas < 2) return -EPERM; > - if (!new_valid_dev(rdev)) > - return -EINVAL; > hpfs_lock(dir->i_sb); > err = -ENOSPC; > fnode = hpfs_alloc_fnode(dir->i_sb, hpfs_i(dir)->i_dno, &fno, &bh); > -- > 1.9.1 > > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 29, 2015 at 05:03:24PM +0200, Mikulas Patocka wrote: > Hi > > I suppose that you should remove the function new_valid_dev at all. Yes, i thought about that, but actually there's still a user of new_valid_dev in fs/stat.c: #define valid_dev(x) choose_32_64(old_valid_dev,new_valid_dev)(x) so i just left new_valid_dev untouched and removed other users in fs first. > > Mikulas > > > On Mon, 28 Sep 2015, Yaowei Bai wrote: > > > As new_valid_dev always returns 1, so !new_valid_dev check is not > > needed, remove it. > > > > Signed-off-by: Yaowei Bai <bywxiaobai@163.com> > > --- > > fs/hpfs/namei.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/fs/hpfs/namei.c b/fs/hpfs/namei.c > > index 9e92c9c..ae4d5a1 100644 > > --- a/fs/hpfs/namei.c > > +++ b/fs/hpfs/namei.c > > @@ -227,8 +227,6 @@ static int hpfs_mknod(struct inode *dir, struct dentry *dentry, umode_t mode, de > > int err; > > if ((err = hpfs_chk_name(name, &len))) return err==-ENOENT ? -EINVAL : err; > > if (hpfs_sb(dir->i_sb)->sb_eas < 2) return -EPERM; > > - if (!new_valid_dev(rdev)) > > - return -EINVAL; > > hpfs_lock(dir->i_sb); > > err = -ENOSPC; > > fnode = hpfs_alloc_fnode(dir->i_sb, hpfs_i(dir)->i_dno, &fno, &bh); > > -- > > 1.9.1 > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 30 Sep 2015, Yaowei Bai wrote: > On Tue, Sep 29, 2015 at 05:03:24PM +0200, Mikulas Patocka wrote: > > Hi > > > > I suppose that you should remove the function new_valid_dev at all. > > Yes, i thought about that, but actually there's still a user of > new_valid_dev in fs/stat.c: > > #define valid_dev(x) choose_32_64(old_valid_dev,new_valid_dev)(x) > > so i just left new_valid_dev untouched and removed other users in fs first. So, remove that too - change it to choose_32_64(old_valid_dev(x),true) If you remove most calls for the function new_valid_dev, the function is meaningless and shouldn't be present in the source code. Mikulas -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 01, 2015 at 10:49:41PM +0200, Mikulas Patocka wrote: > > > On Wed, 30 Sep 2015, Yaowei Bai wrote: > > > On Tue, Sep 29, 2015 at 05:03:24PM +0200, Mikulas Patocka wrote: > > > Hi > > > > > > I suppose that you should remove the function new_valid_dev at all. > > > > Yes, i thought about that, but actually there's still a user of > > new_valid_dev in fs/stat.c: > > > > #define valid_dev(x) choose_32_64(old_valid_dev,new_valid_dev)(x) > > > > so i just left new_valid_dev untouched and removed other users in fs first. > > So, remove that too - change it to choose_32_64(old_valid_dev(x),true) > > If you remove most calls for the function new_valid_dev, the function is > meaningless and shouldn't be present in the source code. Sorry for delay reply. OK, i will follow your advice and send another patch to remove it once this patchset's taken by vfs or mm tree. Thanks for reviewing. Yaowei > > Mikulas -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/hpfs/namei.c b/fs/hpfs/namei.c index 9e92c9c..ae4d5a1 100644 --- a/fs/hpfs/namei.c +++ b/fs/hpfs/namei.c @@ -227,8 +227,6 @@ static int hpfs_mknod(struct inode *dir, struct dentry *dentry, umode_t mode, de int err; if ((err = hpfs_chk_name(name, &len))) return err==-ENOENT ? -EINVAL : err; if (hpfs_sb(dir->i_sb)->sb_eas < 2) return -EPERM; - if (!new_valid_dev(rdev)) - return -EINVAL; hpfs_lock(dir->i_sb); err = -ENOSPC; fnode = hpfs_alloc_fnode(dir->i_sb, hpfs_i(dir)->i_dno, &fno, &bh);
As new_valid_dev always returns 1, so !new_valid_dev check is not needed, remove it. Signed-off-by: Yaowei Bai <bywxiaobai@163.com> --- fs/hpfs/namei.c | 2 -- 1 file changed, 2 deletions(-)