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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux