[PATCH 2/2] Ext3: return ENOMEM rather than EIO if sb_getblk fails

[PATCH 2/2] Ext3: return ENOMEM rather than EIO if sb_getblk fails

[Wang shilong]

From: Wang Shilong <wangsl-fnst@cn.fujitsu.com>

It will be better to have ENOMEM return rather than EIO,because
the only reason that sb_getblk fails is allocation fails.

Signed-off-by: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
---
 fs/ext3/inode.c  | 6 +++---
 fs/ext3/resize.c | 6 +++---
 fs/ext3/xattr.c  | 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c
index c91f8bf..d5315d5 100644
--- a/fs/ext3/inode.c
+++ b/fs/ext3/inode.c
@@ -1084,7 +1084,7 @@ struct buffer_head *ext3_getblk(handle_t *handle, struct inode *inode,
 		struct buffer_head *bh;
 		bh = sb_getblk(inode->i_sb, dummy.b_blocknr);
 		if (unlikely(!bh)) {
-			*errp = -EIO;
+			*errp = -ENOMEM;
 			goto err;
 		}
 		if (buffer_new(&dummy)) {
@@ -2739,7 +2739,7 @@ static int __ext3_get_inode_loc(struct inode *inode,
 				"unable to read inode block - "
 				"inode=%lu, block="E3FSBLK,
 				 inode->i_ino, block);
-		return -EIO;
+		return -ENOMEM;
 	}
 	if (!buffer_uptodate(bh)) {
 		lock_buffer(bh);
@@ -2833,7 +2833,7 @@ make_io:
 					"inode=%lu, block="E3FSBLK,
 					inode->i_ino, block);
 			brelse(bh);
-			return -EIO;
+			return -ENOMEM;
 		}
 	}
 has_buffer:
diff --git a/fs/ext3/resize.c b/fs/ext3/resize.c
index 704e8ce..2710565 100644
--- a/fs/ext3/resize.c
+++ b/fs/ext3/resize.c
@@ -117,7 +117,7 @@ static struct buffer_head *bclean(handle_t *handle, struct super_block *sb,
 
 	bh = sb_getblk(sb, blk);
 	if (unlikely(!bh))
-		return ERR_PTR(-EIO);
+		return ERR_PTR(-ENOMEM);
 	if ((err = ext3_journal_get_write_access(handle, bh))) {
 		brelse(bh);
 		bh = ERR_PTR(err);
@@ -235,7 +235,7 @@ static int setup_new_group_blocks(struct super_block *sb,
 
 		gdb = sb_getblk(sb, block);
 		if (unlikely(!gdb)) {
-			err = -EIO;
+			err = -ENOMEM;
 			goto exit_bh;
 		}
 		if ((err = ext3_journal_get_write_access(handle, gdb))) {
@@ -723,7 +723,7 @@ static void update_backups(struct super_block *sb,
 
 		bh = sb_getblk(sb, group * bpg + blk_off);
 		if (unlikely(!bh)) {
-			err = -EIO;
+			err = -ENOMEM;
 			break;
 		}
 		ext3_debug("update metadata backup %#04lx\n",
diff --git a/fs/ext3/xattr.c b/fs/ext3/xattr.c
index 9f57470..b1fc963 100644
--- a/fs/ext3/xattr.c
+++ b/fs/ext3/xattr.c
@@ -816,7 +816,7 @@ inserted:
 			if (unlikely(!new_bh)) {
 getblk_failed:
 				ext3_free_blocks(handle, inode, block, 1);
-				error = -EIO;
+				error = -ENOMEM;
 				goto cleanup;
 			}
 			lock_buffer(new_bh);
-- 
1.7.11.7

Re: [PATCH 2/2] Ext3: return ENOMEM rather than EIO if sb_getblk fails

[apple]

 Something wrong with my clock, so i send patch several times. 
 I feel very sorry about it.I have sent V1 patch after i fix my computer clock.
Sorry to bother every one…..
> From: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
> 
> It will be better to have ENOMEM return rather than EIO,because
> the only reason that sb_getblk fails is allocation fails.
> 
> Signed-off-by: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
> ---
> fs/ext3/inode.c  | 6 +++---
> fs/ext3/resize.c | 6 +++---
> fs/ext3/xattr.c  | 2 +-
> 3 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c
> index c91f8bf..d5315d5 100644
> --- a/fs/ext3/inode.c
> +++ b/fs/ext3/inode.c
> @@ -1084,7 +1084,7 @@ struct buffer_head *ext3_getblk(handle_t *handle, struct inode *inode,
> 		struct buffer_head *bh;
> 		bh = sb_getblk(inode->i_sb, dummy.b_blocknr);
> 		if (unlikely(!bh)) {
> -			*errp = -EIO;
> +			*errp = -ENOMEM;
> 			goto err;
> 		}
> 		if (buffer_new(&dummy)) {
> @@ -2739,7 +2739,7 @@ static int __ext3_get_inode_loc(struct inode *inode,
> 				"unable to read inode block - "
> 				"inode=%lu, block="E3FSBLK,
> 				 inode->i_ino, block);
> -		return -EIO;
> +		return -ENOMEM;
> 	}
> 	if (!buffer_uptodate(bh)) {
> 		lock_buffer(bh);
> @@ -2833,7 +2833,7 @@ make_io:
> 					"inode=%lu, block="E3FSBLK,
> 					inode->i_ino, block);
> 			brelse(bh);
> -			return -EIO;
> +			return -ENOMEM;
> 		}
> 	}
> has_buffer:
> diff --git a/fs/ext3/resize.c b/fs/ext3/resize.c
> index 704e8ce..2710565 100644
> --- a/fs/ext3/resize.c
> +++ b/fs/ext3/resize.c
> @@ -117,7 +117,7 @@ static struct buffer_head *bclean(handle_t *handle, struct super_block *sb,
> 
> 	bh = sb_getblk(sb, blk);
> 	if (unlikely(!bh))
> -		return ERR_PTR(-EIO);
> +		return ERR_PTR(-ENOMEM);
> 	if ((err = ext3_journal_get_write_access(handle, bh))) {
> 		brelse(bh);
> 		bh = ERR_PTR(err);
> @@ -235,7 +235,7 @@ static int setup_new_group_blocks(struct super_block *sb,
> 
> 		gdb = sb_getblk(sb, block);
> 		if (unlikely(!gdb)) {
> -			err = -EIO;
> +			err = -ENOMEM;
> 			goto exit_bh;
> 		}
> 		if ((err = ext3_journal_get_write_access(handle, gdb))) {
> @@ -723,7 +723,7 @@ static void update_backups(struct super_block *sb,
> 
> 		bh = sb_getblk(sb, group * bpg + blk_off);
> 		if (unlikely(!bh)) {
> -			err = -EIO;
> +			err = -ENOMEM;
> 			break;
> 		}
> 		ext3_debug("update metadata backup %#04lx\n",
> diff --git a/fs/ext3/xattr.c b/fs/ext3/xattr.c
> index 9f57470..b1fc963 100644
> --- a/fs/ext3/xattr.c
> +++ b/fs/ext3/xattr.c
> @@ -816,7 +816,7 @@ inserted:
> 			if (unlikely(!new_bh)) {
> getblk_failed:
> 				ext3_free_blocks(handle, inode, block, 1);
> -				error = -EIO;
> +				error = -ENOMEM;
> 				goto cleanup;
> 			}
> 			lock_buffer(new_bh);
> -- 
> 1.7.11.7
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] Ext3: return ENOMEM rather than EIO if sb_getblk fails

[Greg KH]

On Thu, Jan 13, 2011 at 06:47:14PM +0800, Wang shilong wrote:
> From: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
> 
> It will be better to have ENOMEM return rather than EIO,because
> the only reason that sb_getblk fails is allocation fails.
> 
> Signed-off-by: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
> ---
> fs/ext3/inode.c  | 6 +++---
> fs/ext3/resize.c | 6 +++---
> fs/ext3/xattr.c  | 2 +-
> 3 files changed, 7 insertions(+), 7 deletions(-)


<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

</formletter>

Re: [PATCH 2/2] Ext3: return ENOMEM rather than EIO if sb_getblk fails

[Theodore Ts'o]

On Sat, Jan 12, 2013 at 08:43:42PM -0800, Greg KH wrote:
> On Thu, Jan 13, 2011 at 06:47:14PM +0800, Wang shilong wrote:
> > From: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
> > 
> > It will be better to have ENOMEM return rather than EIO,because
> > the only reason that sb_getblk fails is allocation fails.
> > 
> 
> <formletter>
> 
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
> 
> </formletter>

Did Wang Shilong bcc stable@vger.kernel.org?  He didn't need to send
this to linux-fsdevel@vger.kernel.org (the linux-ext4 list is
sufficient), but I didn't see anything which indicated he was trying
to submit this for inclusion in the stable kernel tree.

My personal opinion is this isn't an important enough patch to warrant
going into stable@vger.kernel.org, although I don't think it would do
any harm or is really dangerous, so I wouldn't object strongly if it did.

I did mark a similar change for ext4 as going to stable, but not
because of the error code change; but rather because I also fixed a
problem where an out-of-memory failure might result in the file system
getting marked as containing errors (and thus might cause an unneeded
fsck).

Cheers,

						- Ted

Re: [PATCH 2/2] Ext3: return ENOMEM rather than EIO if sb_getblk fails

[Greg KH]

On Sun, Jan 13, 2013 at 10:45:38PM -0500, Theodore Ts'o wrote:
> On Sat, Jan 12, 2013 at 08:43:42PM -0800, Greg KH wrote:
> > On Thu, Jan 13, 2011 at 06:47:14PM +0800, Wang shilong wrote:
> > > From: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
> > > 
> > > It will be better to have ENOMEM return rather than EIO,because
> > > the only reason that sb_getblk fails is allocation fails.
> > > 
> > 
> > <formletter>
> > 
> > This is not the correct way to submit patches for inclusion in the
> > stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
> > for how to do this properly.
> > 
> > </formletter>
> 
> Did Wang Shilong bcc stable@vger.kernel.org?

Yes he did, which triggered my semi-automatic-bot response.

Re: [PATCH 2/2] Ext3: return ENOMEM rather than EIO if sb_getblk fails

[Wang]

I am sorry, i am a newbie....
I make it confused what it  means if
i bcc stable@vger.kernel.org......

Re: [PATCH 2/2] Ext3: return ENOMEM rather than EIO if sb_getblk fails

[Theodore Ts'o]

On Mon, Jan 14, 2013 at 12:10:51PM +0800, Wang wrote:
> I am sorry, i am a newbie....
> I make it confused what it  means if
> i bcc stable@vger.kernel.org......

Yeah, don't do that.  (1) Bcc's are bad since they're not visible, so
others can't comment on whether it's appropriate for a patch to be
marked as going into stable, and (2) what's important is that the
commit is tagged as going into the stable in the commit description,
so when the commit hits Linus's git tree, the scripts run by the
stable kernel maintainers will automatically take those commits and
start processing them for backporting into the stable git trees.

You can tag a patch with Cc: stable@vger.kernel.org, i.e:

    Signed-off-by: Eryu Guan <guaneryu@gmail.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Cc: stable@vger.kernel.org

Generally the maintainer (i.e., me for ext4, Jan Kara for ext3) will
take care of adding the stable@vger.kernel.org if we think it's
appropriate.  Feel free to add such an annotation as a suggestion to
us, but we may end up adding or removing such a tag, just as I often
will end up clarifying the commit description (either for English
grammar/readability, or to make it clearer for people deciding whether
they should backport the patch into distro kernels, etc.)

Cheers.

						- Ted

Re: [PATCH 2/2] Ext3: return ENOMEM rather than EIO if sb_getblk fails

[shilong wang]

Hi,

2013/1/14 Theodore Ts'o <tytso@mit.edu>:
> On Mon, Jan 14, 2013 at 12:10:51PM +0800, Wang wrote:
>> I am sorry, i am a newbie....
>> I make it confused what it  means if
>> i bcc stable@vger.kernel.org......
>
> Yeah, don't do that.  (1) Bcc's are bad since they're not visible, so
> others can't comment on whether it's appropriate for a patch to be
> marked as going into stable, and (2) what's important is that the
> commit is tagged as going into the stable in the commit description,
> so when the commit hits Linus's git tree, the scripts run by the
> stable kernel maintainers will automatically take those commits and
> start processing them for backporting into the stable git trees.
>
> You can tag a patch with Cc: stable@vger.kernel.org, i.e:
>
>     Signed-off-by: Eryu Guan <guaneryu@gmail.com>
>     Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
>     Cc: stable@vger.kernel.org
>
> Generally the maintainer (i.e., me for ext4, Jan Kara for ext3) will
> take care of adding the stable@vger.kernel.org if we think it's
> appropriate.  Feel free to add such an annotation as a suggestion to
> us, but we may end up adding or removing such a tag, just as I often
> will end up clarifying the commit description (either for English
> grammar/readability, or to make it clearer for people deciding whether
> they should backport the patch into distro kernels, etc.)
>
 I get it ,thanks very much for your help!

> Cheers.
>
>                                                 - Ted