- 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(&hip->extents_lock);
> if (hip->alloc_blocks == hip->first_blocks)
> --
> 2.28.0
>
ke 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 --
&g
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
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:
> > >
/bfind.c | 2 ++
> 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)
> {
&
en read and 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
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 W=1
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.
>
>
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.
>
>
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 de
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 extrane
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
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.
Reviewed-b
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 th
> 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 in
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 Cocc
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
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
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 &
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 ex
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_
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) into
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 mo
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
> ca
te past the
> end of the destination struct.
>
> 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.
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 &rd->key. This goes back to before the start of git...
>
> Signed-off-by: Dan Carpenter
> ---
> Not tested. Please review carefully.
>
> diff --git
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 comple
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
criti
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
criti
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 inco
30 matches
Mail list logo