[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130728182721.GB16560@kroah.com>
Date: Sun, 28 Jul 2013 11:27:21 -0700
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Theodore Ts'o <tytso@....edu>, Ben Hutchings <ben@...adent.org.uk>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [ 71/79] ext4: fix error handling in ext4_ext_truncate()
On Sun, Jul 28, 2013 at 07:40:53AM -0400, Theodore Ts'o wrote:
> On Sat, Jul 27, 2013 at 10:33:31PM +0100, Ben Hutchings wrote:
> > > --- a/fs/ext4/extents.c
> > > +++ b/fs/ext4/extents.c
> > > @@ -4386,9 +4386,20 @@ void ext4_ext_truncate(handle_t *handle,
> > >
> > > last_block = (inode->i_size + sb->s_blocksize - 1)
> > > >> EXT4_BLOCK_SIZE_BITS(sb);
> > > +retry:
> > > err = ext4_es_remove_extent(inode, last_block,
> > > EXT_MAX_BLOCKS - last_block);
> > > + if (err == ENOMEM) {
> >
> > Positive ENOMEM?! It looks like this value is bubbled up from
> > __es_insert_extent() which returns the usual negative error codes.
>
> Nice catch. Yup, that's a problem. I'll fix this upstream and mark
> it cc:stable.
>
> Until this goes upstream stable kernel maintainers can either: (a) fix
> up this patch by making the line read "err == -ENOMEM", (b) hold back
> this patch until the companion patch to fix this goes upstream, or (c)
> apply this now, since it's otherwise harmless and it does add error
> checking to the ext4_ext_remove_space() call.
I'll take it as-is and expect to see the fix come through Linus's tree
soon.
thanks,
greg k-h
--
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