Re: [GIT PULL] ext4 changes for 4.2-rc1

[Theodore Ts'o]

On Fri, Jun 26, 2015 at 08:05:48PM -0700, Linus Torvalds wrote:
> On Wed, Jun 24, 2015 at 8:46 PM, Theodore Ts'o <tytso@xxxxxxx> wrote:
> >
> > A very large number of cleanups and bug fixes --- in particular for
> > the ext4 encryption patches, which is a new feature added in the last
> > merge window.  Also fix a number of long-standing xfstest failures.
> > (Quota writes failing due to ENOSPC, a race between truncate and
> > writepage in data=journalled mode that was causing generic/068 to
> > fail, and other corner cases.)
> >
> > Also add support for FALLOC_FL_INSERT_RANGE, and improve jbd2
> > performance eliminating locking when a buffer is modified more than
> > once during a transaction (which is very common for allocation
> > bitmaps, for example), in which case the state of the journalled
> > buffer head doesn't need to change.
> 
> I think this is very broken.
> 
> I just got this while compiling:
> 
>    ------------[ cut here ]------------
>    kernel BUG at fs/jbd2/transaction.c:1325!
> ...
>
> The most obvious candidate for a culprit would seem to be
> 
>    2143c1965a76 "jbd2: speedup jbd2_journal_dirty_metadata()"
> 
> which is the commit that introduced the assert that triggers. Ted? Jan?

I would tend to agree.  The weird thing though is that I haven't seen
this problem myself, despite running multiple regression tests before
I sent the pull request, as well as running it on my laptop and doing
kernel compiles with make -j16 and reading e-mail (I'm typing this
e-mail on a 4.1 kernel merged with the ext4 patches for this merge
window, so I have this commit running in my development laptop, and it
hasn't triggered for me).

All of this being said, my suggestion would be to revert it for now
and we'll investigate more closely for the next merge window.  This is
just a performance improvement, and so better safe than sorry.  Jan,
do you agree?

							- Ted
							

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