Re: Column for keywords?

[Dmitry Vyukov]

On Fri, Jan 4, 2019 at 2:01 PM Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
>
> On Wed, May 16, 2018 at 6:50 PM Tetsuo Handa
> <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > Dmitry Vyukov wrote:
> > > On Tue, May 15, 2018 at 10:59 PM, Tetsuo Handa
> > > <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
> > > > Dmitry Vyukov wrote:
> > > >> I've filed https://github.com/google/syzkaller/issues/608 to not lose
> > > >> track of this.
> > > >
> > > > Thanks. Since the time lag between a patch was proposed and that patch is
> > > > applied to a git tree tends to become long, duplicated works like
> > > > https://www.spinics.net/lists/linux-fsdevel/msg125240.html and
> > > > http://lkml.kernel.org/r/964a8b27-cd69-357c-fe78-76b066056201@xxxxxxxxxxxxxxxxxxx
> > > > are already occurring.
> > >
> > > This is bad.
> > >
> > > > Therefore, it is important that the state of the bug (e.g.
> > > > bisected, cause identified, patch proposed) is visible from the table.
> > >
> > > What do you think about the last section of:
> > > https://groups.google.com/d/msg/syzkaller-bugs/nw7BIW9V2wk/NE0P_Au4AQAJ
> > > there is already a way to say "there is a pending fix for this".
> >
> > That lacks a way to annotate "there is a pending fix for this, but the fix
> > is not yet applied to any git tree". I mean not only "git trees which syzbot
> > is checking" but also "git trees which are publicly visible".
> >
> > (Also, if we can later correct the patch using "#syz fix:" in case the patch
> > title was renamed, it is not clear how to specify multiple patches using
> > "#syz fix:" when a patch which meant to fix the reported problem contained
> > a regression or was incomplete and thus fixup patch followed shortly. An
> > example is commit 5f3e3b85cc0a5eae and commit ef95a90ae6f4f219 in
> > "WARNING: kmalloc bug in memdup_user (2)". I've tried
> >
> >   #syz fix: RDMA/ucma: Correct option size check using optlen
> >   #syz fix: RDMA/ucma: ucma_context reference leak in error path
> >
> > but only the former patch was recorded.)
> >
> > >
> > > But one problem with manual tagging is how to make everybody update
> > > these tags. If only few people do it, it can still lead to duplicate
> > > work. And it's not syzbot-specific. Can happen with just any bug
> > > report on kernel mailing lists. Traditionally it's solved with bug
> > > tracking systems and assigning bugs when a developer starts working on
> > > it. But kernel does not have a working bug tracker.
> > >
> > > One simple thing we can do is make syzbot poll more trees to discover
> > > Reported-by tags faster. This will automatically update status on
> > > dashboard to "fix pending". I've filed
> > > https://github.com/google/syzkaller/issues/610 for this. Ideally, we
> > > would intercept all mailed patches, but it's hard with kernel
> > > development process because there is no system that tracks all pending
> > > patches.
> > >
> >
> > The problem is that the pending fix won't be applied to any git tree.
> > It depends on when reviewers and maintainers can find time for
> > reviewing/committing the fix. Scanning all git trees unlikely helps.
> >
> >   the criteria is that you are "reasonably sure that the commit will
> >   reach upstream under this title", for whatever reason
> >
> > won't apply to not yet reviewed patches. What I want is a way to specify
> > "a patch was proposed but the patch is not yet reviewed/tested/applied".
> >
> > Generally, progresses are not recorded frequently enough to avoid duplicated
> > works. I want to check not only "fix pending" stage but also e.g. "problem
> > guessed", "bisected", "cause identified", "patch proposed", "patch reviewed"
> > stages from the top page's table.
>
> 1. This sounds very much like general bug tracking system. We
> specifically didn't want to go down the slippery slope of implementing
> yet another bug tracking system.
> 2. This problem is not specific to syzbot in any way (just like lost
> bug reports). Kernel developers waste time on duplicate work for other
> bug reports too.
> So I think (1) we need a bug tracking system, (2) use that system for
> syzbot to solve this local problem.


+Ted who also says that it is not possible to make sense out of
current state of kernel bug reports (e.g. what are open bugs for ext4
sorted by priority).
+Doug who says the same re rdma_cm subsystem.

Both said this in the context of syzbot, but I fail to see how this is
any syzbot-specific. This highlights the more broad problem with
kernel development process.