lkml.org 
[lkml]   [2019]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ext4 regression (was Re: [PATCH 4.19 000/105] 4.19.45-stable review)
On Tue, May 21, 2019 at 03:58:15PM +0530, Naresh Kamboju wrote:
> > Ted, any ideas here? Should I drop this from the stable trees, and you
> > revert it from Linus's? Or something else?

It's safe to drop this from the stable trees while we investigate. It
was always borderline for stable anyway. (See below).

> >
> > Note, I do also have 170417c8c7bb ("ext4: fix block validity checks for
> > journal inodes using indirect blocks") in the trees, which was supposed
> > to fix the problem with this patch, am I missing another one as well?
>
> FYI,
> I have applied fix patch 170417c8c7bb ("ext4: fix block validity checks for
> journal inodes using indirect blocks") but did not fix this problem.

Hmm... are you _sure_? This bug was reported to me versus the
mainline, and the person who reported it confirmed that it did fix the
problem, he was seeing, and the symptoms are identical to yours. Can
you double check, please? I can't reproduce it either with that patch applied.

> > (side note, it was mean not to mark 170417c8c7bb for stable, when the
> > patch it was fixing was marked for stable, I'm lucky I caught it...)

Sorry, I had forgotten that I had marked 345c0dbf3a30 for stable;
that's why I didn't mark 170417c8c7bb for stable. 345c0dbf3a30 fixes
a crash triggered by a specially crafted (corrupted) file system, and
I had thought I had decided it wasn't important enough for stable; I
think what happened is I shrugged and said, "oh well, Sasha's
automated ML system is going to pick it for stable anyway, so I might
just mark it for stable anyway" --- and I forgot I had landed that
way.

- Ted

\
 
 \ /
  Last update: 2019-05-21 18:23    [W:0.113 / U:6.736 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site