Re: BUG: unable to handle kernel paging request in do_mount

From: Al Viro
Date: Sat May 18 2019 - 17:44:14 EST


On Sat, May 18, 2019 at 04:18:43PM -0400, Theodore Ts'o wrote:

> > What would you prefer to happen in such situations? Commit summaries
> > modified enough to confuse CI tools into *NOT* noticing that those
> > are versions of the same patch? Some kind of metadata telling the
> > same tools that such-and-such commits got folded in (and they might
> > have been split in process, with parts folded into different spots
> > in the series, at that)?
> >
> > Because "never fold in, never reorder, just accumulate patches in
> > the end of the series" is not going to fly. For a lot of reasons.
>
> As far as I'm concerned, this is the tools problem; I don't think it's
> worth it for developers to feel they need to twist themselves into
> knots just to try to make the CI tools' life easier.

FWIW, what _is_ the underlying problem? It looks like the basic issue
is with rebase/cherry-pick of a commit; it seems to be trying to
handle two things:
1) report X' in commit C' is similar to report X in commit C,
with C' apparently being a rebase/cherry-pick/whatnot of C; don't
want to lose that information
2) reports X, Y and Z in commit C don't seem to be reoccuring
on the current tree, without any claimed fix in it. Want to keep
an eye on those.

... and getting screwed by a mix of those two: reports X, Y and Z in
commit C don't seem to be reoccuring on the current tree, even though
it does contain a commit C' that seems to be a rebase of C. A fix for
C is *not* present as an identifiable commit in the current tree.
Was it lost or was it renamed/merged with other commits/replaced by
another fix?

What I don't quite understand is why does the tool care. Suppose
we have a buggy commit + clearly marked fix. And see a report
very similar to the original ones, on the tree with alleged fix
clearly present. IME the earlier reports are often quite relevant -
the fix might have been incomplete/racy/etc., and in that case
the old reports (*AND* pointer to the commit that was supposed to
have fixed those) are very useful.

What's the problem these reminders are trying to solve? Computational
resources eaten by comparisons?