Re: Column for keywords?

Re: Column for keywords?

[Dmitry Vyukov]

On Wed, May 16, 2018 at 6:50 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> Dmitry Vyukov wrote:
> > On Tue, May 15, 2018 at 10:59 PM, Tetsuo Handa
> > <penguin-kernel@i-love.sakura.ne.jp> 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@I-love.SAKURA.ne.jp
> > > 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.

Re: Column for keywords?

[Dmitry Vyukov]

On Fri, Jan 4, 2019 at 2:01 PM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Wed, May 16, 2018 at 6:50 PM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >
> > Dmitry Vyukov wrote:
> > > On Tue, May 15, 2018 at 10:59 PM, Tetsuo Handa
> > > <penguin-kernel@i-love.sakura.ne.jp> 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@I-love.SAKURA.ne.jp
> > > > 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.