On Fri, Jan 4, 2019 at 2:01 PM Dmitry Vyukov <[email protected]> wrote: > > On Wed, May 16, 2018 at 6:50 PM Tetsuo Handa > <[email protected]> wrote: > > > > Dmitry Vyukov wrote: > > > On Tue, May 15, 2018 at 10:59 PM, Tetsuo Handa > > > <[email protected]> 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/[email protected] > > > > 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.
