Re: [PATCH] hfsplus: remove pr_err message on ENOSPC file extend error

- pr_err("extend alloc file! (%llu,%u,%u)\n", > -sbi->alloc_file->i_size * 8, > - sbi->total_blocks, sbi->free_blocks); > return -ENOSPC; > - } Looks good and sounds reasonable. Reviewed-by: Viacheslav Dubeyko Thanks, Viacheslav Dubeyko. > > mutex_lock(>extents_lock); > if (hip->alloc_blocks == hip->first_blocks) > -- > 2.28.0 >

Re: [PATCH] fs/hfs: remove unused macro to tame gcc

sense to follow to the compiler’s complains in this case. I believe that it needs to keep these declarations. Thanks, Viacheslav Dubeyko. > Signed-off-by: Alex Shi > Cc: linux-fsde...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- > fs/hfs/hfs.h | 2 -- > fs

Re: [PATCH] hfsplus: Avoid truncating the logical block size

return max_t(unsigned int, bdev_logical_block_size(sb->s_bdev), > HFSPLUS_SECTOR_SIZE); > } > Looks good. Thanks. Reviewed-by: Viacheslav Dubeyko > -- > 1.8.3.1

Re: [PATCH] hfs: fix null-ptr-deref in hfs_find_init()

Hi Yang, On Wed, 2020-06-10 at 20:54 +0800, Yang Yingliang wrote: > Hi, > On 2020/6/9 16:06, Viacheslav Dubeyko wrote: > > Hi Yang, > > > > > On Jun 5, 2020, at 6:01 AM, Yang Yingliang < > > > yangyingli...@huawei.com> wrote: > > >

Re: [PATCH] hfs: fix null-ptr-deref in hfs_find_init()

++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/hfs/bfind.c b/fs/hfs/bfind.c > index 4af318f..aafa6bd 100644 > --- a/fs/hfs/bfind.c > +++ b/fs/hfs/bfind.c > @@ -16,6 +16,8 @@ int hfs_find_init(struct hfs_btree *tree, struct > hfs_find_data *fd) > { >

Re: [PATCH 2/2] hfsplus: add a check for hfs_bnode_find

d hashed before, haven't they? >>> >> >> I find that after hfs_bnode_findhash in hfs_bnode_find, there is a test for >> HFS_BNODE_ERROR and may return an error. I'm not sure whether it >> can happen here. > > That would require a race betw

Re: [PATCH] hfsplus: Replace strncpy with memcpy

On Wed, 2019-05-29 at 13:33 +0200, Mathieu Malaterre wrote: > Function strncpy was used to copy a fixed size buffer. Since > NUL-terminating string is not required here, prefer a memcpy > function. > The generated code (ppc32) remains the same. > > Silence the following warning triggered using

Re: [PATCH V2] hfs: do not free node before using

On Sat, 2018-11-24 at 10:10 +0800, Pan Bian wrote: > The function hfs_bmap_free frees node via hfs_bnode_put(node). > However, > it then reads node->this when dumping error message on an error path, > which may result in a use-after-free bug. This patch frees node only > when it is never used. >

Re: [PATCH V2] hfs: do not free node before using

On Sat, 2018-11-24 at 10:10 +0800, Pan Bian wrote: > The function hfs_bmap_free frees node via hfs_bnode_put(node). > However, > it then reads node->this when dumping error message on an error path, > which may result in a use-after-free bug. This patch frees node only > when it is never used. >

Re: [PATCH] hfs: do not free node before using

On Fri, 2018-11-23 at 17:04 +0800, Pan Bian wrote: > The function hfs_bmap_free frees node via hfs_bnode_put(node). > However, > it then reads node->this when dumping error message on an error path, > which may result in a use-after-free bug. This patch frees node only > when it is never used. >

Re: [PATCH] hfs: do not free node before using

On Fri, 2018-11-23 at 17:04 +0800, Pan Bian wrote: > The function hfs_bmap_free frees node via hfs_bnode_put(node). > However, > it then reads node->this when dumping error message on an error path, > which may result in a use-after-free bug. This patch frees node only > when it is never used. >

Re: [RFC][PATCH 03/10] hfsplus: use fs_umode_to_dtype() helper

On Tue, 2018-10-23 at 21:19 +0100, Phillip Potter wrote: > Replace if/else statements with common lookup table implementation. > > Original patch written by Amir Goldstein. > > Signed-off-by: Phillip Potter > --- > fs/hfsplus/dir.c | 16 ++-- > 1 file changed, 2 insertions(+), 14

Re: [RFC][PATCH 03/10] hfsplus: use fs_umode_to_dtype() helper

On Tue, 2018-10-23 at 21:19 +0100, Phillip Potter wrote: > Replace if/else statements with common lookup table implementation. > > Original patch written by Amir Goldstein. > > Signed-off-by: Phillip Potter > --- > fs/hfsplus/dir.c | 16 ++-- > 1 file changed, 2 insertions(+), 14

Re: [PATCH] hfs: fix array out of bounds read of array extent

On Wed, 2018-10-17 at 15:01 -0700, Andrew Morton wrote: > On Fri, 31 Aug 2018 15:05:38 +0100 Colin King > wrote: > > > From: Colin Ian King > > > > Currently extent and index i are both being incremented causing > > an array out of bounds read on extent[i]. Fix this by removing > > the

Re: [PATCH] hfs: fix array out of bounds read of array extent

On Wed, 2018-10-17 at 15:01 -0700, Andrew Morton wrote: > On Fri, 31 Aug 2018 15:05:38 +0100 Colin King > wrote: > > > From: Colin Ian King > > > > Currently extent and index i are both being incremented causing > > an array out of bounds read on extent[i]. Fix this by removing > > the

Re: [PATCH 1/2] hfs: fix potential refcnt problem of nls module

On Tue, 2018-04-17 at 15:05 +0800, Chengguang Xu wrote: > When specifying iocharset/codepage multiple times in a mount, > current option parsing will cause inaccurate refcount of nls > module. Hence, call unload_nls for previous one in this case. > > Signed-off-by: Chengguang Xu

Re: [PATCH 2/2] hfsplus: fix potential refcnt problem of nls module

On Tue, 2018-04-17 at 15:05 +0800, Chengguang Xu wrote: > When specifying nls option multiple times in a mount, > current option parsing will cause inaccurate refcount of nls > module. Hence, call unload_nls for previous one in this case. > > Signed-off-by: Chengguang Xu Looks

Re: [PATCH 1/2] hfs: fix potential refcnt problem of nls module

On Tue, 2018-04-17 at 15:05 +0800, Chengguang Xu wrote: > When specifying iocharset/codepage multiple times in a mount, > current option parsing will cause inaccurate refcount of nls > module. Hence, call unload_nls for previous one in this case. > > Signed-off-by: Chengguang Xu Looks good.

Re: [PATCH 2/2] hfsplus: fix potential refcnt problem of nls module

On Tue, 2018-04-17 at 15:05 +0800, Chengguang Xu wrote: > When specifying nls option multiple times in a mount, > current option parsing will cause inaccurate refcount of nls > module. Hence, call unload_nls for previous one in this case. > > Signed-off-by: Chengguang Xu Looks good.

Re: [PATCH] fs/hfsplus: use memcpy() instead of strncpy()

On Mon, 2018-01-08 at 20:17 +0800, Xiongfeng Wang wrote: > From: Xiongfeng Wang > > gcc-8 reports > > inlined from 'copy_name' at fs/hfsplus/xattr.c:416:3: > ./include/linux/string.h:245:9: warning: '__builtin_strncpy' output > truncated before terminating nul copying

Re: [PATCH] fs/hfsplus: use memcpy() instead of strncpy()

On Mon, 2018-01-08 at 20:17 +0800, Xiongfeng Wang wrote: > From: Xiongfeng Wang > > gcc-8 reports > > inlined from 'copy_name' at fs/hfsplus/xattr.c:416:3: > ./include/linux/string.h:245:9: warning: '__builtin_strncpy' output > truncated before terminating nul copying 4 bytes from a string of

Re: [patch] hfs: fix hfs_readdir()

; we > want the ->cat member of the union. > > On Tue, Jan 26, 2016 at 01:54:06PM -0800, Viacheslav Dubeyko wrote: > > > > On Tue, 2016-01-26 at 22:18 +0300, Dan Carpenter wrote: > > > > > > Hm, I completely didn't see that it was a union instead of a >

Re: [patch] hfs: fix hfs_readdir()

; we > want the ->cat member of the union. > > On Tue, Jan 26, 2016 at 01:54:06PM -0800, Viacheslav Dubeyko wrote: > > > > On Tue, 2016-01-26 at 22:18 +0300, Dan Carpenter wrote: > > > > > > Hm, I completely didn't see that it was a union instead of a >

Re: [PATCH] hfs: Change structure initialisation to C99 style

On Wed, 2016-06-22 at 11:04 +0530, Amitoj Kaur Chawla wrote: > To allow for structure randomisation, replace the in order > struct initialisation style with explicit field style. > Also, remove an unnecessary initialisation since NULL values do not > need to be explicitly initialised. > > The

Re: [PATCH] hfs: Change structure initialisation to C99 style

On Wed, 2016-06-22 at 11:04 +0530, Amitoj Kaur Chawla wrote: > To allow for structure randomisation, replace the in order > struct initialisation style with explicit field style. > Also, remove an unnecessary initialisation since NULL values do not > need to be explicitly initialised. > > The

Re: [PATCH] f2fs: introduce on-disk layout version checking functionality

On Wed, 2016-05-25 at 10:12 -0700, Jaegeuk Kim wrote: [snipped] > > > > So, my logic is simple. We are trying to modify the on-disk layout. As a > > result, we need to check the on-disk layout version, from my viewpoint. > > And this modification is not "feature" itself but simple bug fix. And I

Re: [PATCH] f2fs: introduce on-disk layout version checking functionality

On Wed, 2016-05-25 at 10:12 -0700, Jaegeuk Kim wrote: [snipped] > > > > So, my logic is simple. We are trying to modify the on-disk layout. As a > > result, we need to check the on-disk layout version, from my viewpoint. > > And this modification is not "feature" itself but simple bug fix. And I

Re: [PATCH] f2fs: introduce on-disk layout version checking functionality

Hi Jaegeuk, On Mon, 2016-05-23 at 14:13 -0700, Jaegeuk Kim wrote: > Hi Slava, > > On Thu, May 19, 2016 at 10:46:06AM -0700, Viacheslav Dubeyko wrote: > ... > > > > +#ifdef CONFIG_F2FS_16TB_VOLUME_SUPPORT > > +#define F2FS_MAX_SUPP_MAJOR_VERSION

Re: [PATCH] f2fs: introduce on-disk layout version checking functionality

Hi Jaegeuk, On Mon, 2016-05-23 at 14:13 -0700, Jaegeuk Kim wrote: > Hi Slava, > > On Thu, May 19, 2016 at 10:46:06AM -0700, Viacheslav Dubeyko wrote: > ... > > > > +#ifdef CONFIG_F2FS_16TB_VOLUME_SUPPORT > > +#define F2FS_MAX_SUPP_MAJOR_VERSION

Re: [PATCH] f2fs: introduce on-disk layout version checking functionality

On Tue, 2016-05-24 at 01:52 -0700, Christoph Hellwig wrote: > On Mon, May 23, 2016 at 01:08:05PM -0700, Viacheslav Dubeyko wrote: > > I think that it's some confusion. I didn't introduce any new fields in > > struct f2fs_super_block. The "major_ver" and "minor

Re: [PATCH] f2fs: introduce on-disk layout version checking functionality

On Tue, 2016-05-24 at 01:52 -0700, Christoph Hellwig wrote: > On Mon, May 23, 2016 at 01:08:05PM -0700, Viacheslav Dubeyko wrote: > > I think that it's some confusion. I didn't introduce any new fields in > > struct f2fs_super_block. The "major_ver" and "minor

Re: [PATCH] f2fs: introduce on-disk layout version checking functionality

On Tue, 2016-05-24 at 01:53 -0700, Christoph Hellwig wrote: [snipped] > > That goes on to the next question: why do we even need a config option > for 16TB+ volume support? > I believe that it makes sense to have config option during implementation phase. I mean that it needs to protect this

Re: [PATCH] f2fs: introduce on-disk layout version checking functionality

On Tue, 2016-05-24 at 01:53 -0700, Christoph Hellwig wrote: [snipped] > > That goes on to the next question: why do we even need a config option > for 16TB+ volume support? > I believe that it makes sense to have config option during implementation phase. I mean that it needs to protect this

Re: [PATCH] f2fs: introduce on-disk layout version checking functionality

On Mon, 2016-05-23 at 01:25 -0700, Christoph Hellwig wrote: > On Fri, May 20, 2016 at 11:30:43AM -0700, Viacheslav Dubeyko wrote: > > I am not sure that I follow to your point. The F2FS has "feature" field > > (__le32 feature) into on-disk superblock (struct f2fs_super_

Re: [PATCH] f2fs: introduce on-disk layout version checking functionality

On Mon, 2016-05-23 at 01:25 -0700, Christoph Hellwig wrote: > On Fri, May 20, 2016 at 11:30:43AM -0700, Viacheslav Dubeyko wrote: > > I am not sure that I follow to your point. The F2FS has "feature" field > > (__le32 feature) into on-disk superblock (struct f2fs_super_

Re: [PATCH] f2fs: introduce on-disk layout version checking functionality

On Fri, 2016-05-20 at 00:58 -0700, Christoph Hellwig wrote: > Please don't do the mistake of versioning the structure, but instead > use feature flags, similar to what extN and modern XFS file systems do. I am not sure that I follow to your point. The F2FS has "feature" field (__le32 feature)

Re: [PATCH] f2fs: introduce on-disk layout version checking functionality

On Fri, 2016-05-20 at 00:58 -0700, Christoph Hellwig wrote: > Please don't do the mistake of versioning the structure, but instead > use feature flags, similar to what extN and modern XFS file systems do. I am not sure that I follow to your point. The F2FS has "feature" field (__le32 feature)

[PATCH] f2fs: introduce on-disk layout version checking functionality

From: Vyacheslav Dubeyko Date: Wed, 18 May 2016 15:58:00 -0700 Subject: [PATCH] f2fs: introduce on-disk layout version checking functionality Currently, F2FS has 16TB limitation on volume size. But 16TB NAND-based SSDs are around the corner. Unfortunately, support of

[PATCH] f2fs: introduce on-disk layout version checking functionality

From: Vyacheslav Dubeyko Date: Wed, 18 May 2016 15:58:00 -0700 Subject: [PATCH] f2fs: introduce on-disk layout version checking functionality Currently, F2FS has 16TB limitation on volume size. But 16TB NAND-based SSDs are around the corner. Unfortunately, support of 16TB+ volume size needs in

Re: Where is nilfs2 fsck

Hi David, On Mon, 2016-02-08 at 13:53 -0500, David Niklas wrote: > Alas, my beautiful fs has become damaged and fsck does nothing, I think > it's a nop. > What is wrong, something in the btree, the original message was in > syslog but it seems to have rotated, I could tell you but I'd have to >

Re: Where is nilfs2 fsck

Hi David, On Mon, 2016-02-08 at 13:53 -0500, David Niklas wrote: > Alas, my beautiful fs has become damaged and fsck does nothing, I think > it's a nop. > What is wrong, something in the btree, the original message was in > syslog but it seems to have rotated, I could tell you but I'd have to >

Re: [patch] hfs: fix hfs_readdir()

t; > On Tue, Jan 26, 2016 at 10:18:56AM -0800, Viacheslav Dubeyko wrote: > > Another worry could be the "search_key" field of the struct > > hfs_find_data. > > I don't understand what you mean here. > I mean here that we could have another incorrect copy operations for "search_key" field. That's all. Thanks, Vyacheslav Dubeyko.

Re: [patch] hfs: fix hfs_readdir()

On Tue, 2016-01-26 at 12:26 +0300, Dan Carpenter wrote: > I was looking through static analysis warnings and we seem to be copying > garbage into >key. This goes back to before the start of git... > > Signed-off-by: Dan Carpenter > --- > Not tested. Please review carefully. > > diff --git

Re: [patch] hfs: fix hfs_readdir()

On Tue, 2016-01-26 at 12:26 +0300, Dan Carpenter wrote: > I was looking through static analysis warnings and we seem to be copying > garbage into >key. This goes back to before the start of git... > > Signed-off-by: Dan Carpenter > --- > Not tested. Please review

Re: [patch] hfs: fix hfs_readdir()

t; > On Tue, Jan 26, 2016 at 10:18:56AM -0800, Viacheslav Dubeyko wrote: > > Another worry could be the "search_key" field of the struct > > hfs_find_data. > > I don't understand what you mean here. > I mean here that we could have another incorrect copy operations for "search_key" field. That's all. Thanks, Vyacheslav Dubeyko.

Re: kmod-hfsplus

On Sun, 2015-11-29 at 20:12 +, Richard Thomas wrote: > Hi, > > I have version 0.0-2 of this installed on my CentOS machines. > What Linux kernel version do you have? > When I try to copy an entire hard drive that is formatted with the > hfs+ file system to another, it makes my system

Re: kmod-hfsplus

On Sun, 2015-11-29 at 20:12 +, Richard Thomas wrote: > Hi, > > I have version 0.0-2 of this installed on my CentOS machines. > What Linux kernel version do you have? > When I try to copy an entire hard drive that is formatted with the > hfs+ file system to another, it makes my system

Re: [PATCH 1/1] hfs: incorrect return values

On Tue, 2015-03-24 at 20:37 -0400, Chengyu Song wrote: > In case of memory allocation error, the return should be -ENOMEM, > instead of -ENOSPC. > To be honest, I am not fully sure that such fix makes sense. Of course, it is possible to exchange -ENOSPC on -ENOMEM. But principally it is not

Re: [PATCH 1/1] hfsplus: incorrect return value

On Tue, 2015-03-24 at 20:44 -0400, Chengyu Song wrote: > In case of memory allocation error, the return should be -ENOMEM, > instead of -ENOSPC. > To be honest, I am not fully sure that such fix makes sense. Of course, it is possible to exchange -ENOSPC on -ENOMEM. But principally it is not

Re: [PATCH 1/1] hfs: incorrect return values

On Tue, 2015-03-24 at 20:37 -0400, Chengyu Song wrote: In case of memory allocation error, the return should be -ENOMEM, instead of -ENOSPC. To be honest, I am not fully sure that such fix makes sense. Of course, it is possible to exchange -ENOSPC on -ENOMEM. But principally it is not

Re: [PATCH 1/1] hfsplus: incorrect return value

On Tue, 2015-03-24 at 20:44 -0400, Chengyu Song wrote: In case of memory allocation error, the return should be -ENOMEM, instead of -ENOSPC. To be honest, I am not fully sure that such fix makes sense. Of course, it is possible to exchange -ENOSPC on -ENOMEM. But principally it is not

Re: [PATCH] hfsplus: hfsplus_file_fsync() does not check for return value of sync_inode_metadata()

On Mon, 2015-03-23 at 11:33 -0400, Changwoo Min wrote: > hfsplus_file_fsync() siliently ignores the return value of > sync_inode_metadata(). > If an error occurs at sync_inode_metadata() and subsequent updates of other > file > system metadata (b-trees) succeed, file system metadata will be

Re: [PATCH] hfsplus: hfsplus_file_fsync() does not check for return value of sync_inode_metadata()

On Mon, 2015-03-23 at 11:33 -0400, Changwoo Min wrote: hfsplus_file_fsync() siliently ignores the return value of sync_inode_metadata(). If an error occurs at sync_inode_metadata() and subsequent updates of other file system metadata (b-trees) succeed, file system metadata will be