lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1365400526.2673.3.camel@slavad-ubuntu>
Date:	Mon, 08 Apr 2013 09:55:26 +0400
From:	Vyacheslav Dubeyko <slava@...eyko.com>
To:	Alexey Khoroshilov <khoroshilov@...ras.ru>
Cc:	Hin-Tak Leung <htl10@...rs.sourceforge.net>,
	Al Viro <viro@...iv.linux.org.uk>,
	Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>,
	Christoph Hellwig <hch@....de>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, ldv-project@...uxtesting.org
Subject: Re: [PATCH 1/2] hfsplus: add error propagation to 
 __hfsplus_ext_write_extent()

Hi Alexey,

On Mon, 2013-04-08 at 01:21 +0400, Alexey Khoroshilov wrote:
> __hfsplus_ext_write_extent() suppresses errors coming from hfs_brec_find().
> The patch implements error code propagation.
> 

Please, prepare a single patch set for all your changes in HFS and HFS+. These changes are related to each other, so, it makes sense in one patch set.

Thanks,
Vyacheslav Dubeyko.

> Signed-off-by: Alexey Khoroshilov <khoroshilov@...ras.ru>
> ---
>  fs/hfsplus/extents.c |   21 +++++++++++++--------
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/hfsplus/extents.c b/fs/hfsplus/extents.c
> index a94f0f7..fed73f7 100644
> --- a/fs/hfsplus/extents.c
> +++ b/fs/hfsplus/extents.c
> @@ -83,7 +83,7 @@ static u32 hfsplus_ext_lastblock(struct hfsplus_extent *ext)
>  	return be32_to_cpu(ext->start_block) + be32_to_cpu(ext->block_count);
>  }
>  
> -static void __hfsplus_ext_write_extent(struct inode *inode,
> +static int __hfsplus_ext_write_extent(struct inode *inode,
>  		struct hfs_find_data *fd)
>  {
>  	struct hfsplus_inode_info *hip = HFSPLUS_I(inode);
> @@ -98,13 +98,13 @@ static void __hfsplus_ext_write_extent(struct inode *inode,
>  	res = hfs_brec_find(fd, hfs_find_rec_by_key);
>  	if (hip->extent_state & HFSPLUS_EXT_NEW) {
>  		if (res != -ENOENT)
> -			return;
> +			return res;
>  		hfs_brec_insert(fd, hip->cached_extents,
>  				sizeof(hfsplus_extent_rec));
>  		hip->extent_state &= ~(HFSPLUS_EXT_DIRTY | HFSPLUS_EXT_NEW);
>  	} else {
>  		if (res)
> -			return;
> +			return res;
>  		hfs_bnode_write(fd->bnode, hip->cached_extents,
>  				fd->entryoffset, fd->entrylength);
>  		hip->extent_state &= ~HFSPLUS_EXT_DIRTY;
> @@ -117,11 +117,13 @@ static void __hfsplus_ext_write_extent(struct inode *inode,
>  	 * to explicily mark the inode dirty, too.
>  	 */
>  	set_bit(HFSPLUS_I_EXT_DIRTY, &hip->flags);
> +
> +	return 0;
>  }
>  
>  static int hfsplus_ext_write_extent_locked(struct inode *inode)
>  {
> -	int res;
> +	int res = 0;
>  
>  	if (HFSPLUS_I(inode)->extent_state & HFSPLUS_EXT_DIRTY) {
>  		struct hfs_find_data fd;
> @@ -129,10 +131,10 @@ static int hfsplus_ext_write_extent_locked(struct inode *inode)
>  		res = hfs_find_init(HFSPLUS_SB(inode->i_sb)->ext_tree, &fd);
>  		if (res)
>  			return res;
> -		__hfsplus_ext_write_extent(inode, &fd);
> +		res = __hfsplus_ext_write_extent(inode, &fd);
>  		hfs_find_exit(&fd);
>  	}
> -	return 0;
> +	return res;
>  }
>  
>  int hfsplus_ext_write_extent(struct inode *inode)
> @@ -175,8 +177,11 @@ static inline int __hfsplus_ext_cache_extent(struct hfs_find_data *fd,
>  
>  	WARN_ON(!mutex_is_locked(&hip->extents_lock));
>  
> -	if (hip->extent_state & HFSPLUS_EXT_DIRTY)
> -		__hfsplus_ext_write_extent(inode, fd);
> +	if (hip->extent_state & HFSPLUS_EXT_DIRTY) {
> +		res = __hfsplus_ext_write_extent(inode, fd);
> +		if (res)
> +			return res;
> +	}
>  
>  	res = __hfsplus_ext_read_extent(fd, hip->cached_extents, inode->i_ino,
>  					block, HFSPLUS_IS_RSRC(inode) ?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ