On Thu, Jan 16, 2025 at 05:37:24PM +0800, Kun Hu wrote: > > > > > Makes sense. Sorry if I came off a bit strong, there's been a couple > > syzbot copycats and I find I keep repeating myself :) > > > > So, it sounds like you're getting nudged to work upstream, i.e. people > > funding you want you to be a bit better engineers so the work you're > > doing is taken up (academics tend to be lousy engineers, and vice > > versa, heh). > > > > But if you're working on fuzzing, upstream is syzbot, not the kernel - > > if there's a community you should be working with, that's the one. > > > > An individual bug report like this is pretty low value to me. I see a > > ton of dups, and dups coming from yet another system is downright > > painful. > > > > The real value is all the infrastructure /around/ running tests and > > finding bugs: ingesting all that data into dashboards so I can look for > > patterns, and additional tooling (like the ktest/syzbot integration, as > > well as other things) for getting the most out of every bug report > > possible. > > > > If you're working on fuzzing, you don't want to be taking all that on > > solo. That's the power of working with a community :) And more than > > that, we do _very_ much need more community minded people getting > > involved with testing in general, not just fuzzing. > > > > > Hi Kent, > > Thank you for your insights. > > I have a couple of questions I would like to ask for your advice on: > > From a testing perspective, we have modified syzkaller and discovered > some issues. It’s true that researchers working on fuzzing often lack > a deep understanding of the kernel, making it difficult to precisely > determine the scope of reported problems. Meanwhile, syzbot provides a > description of the reporting process (please refer to the link below) > and encourages researchers to report bugs to maintainers. However, > there seems to be a significant gap here—researchers may end up > reporting bugs to the wrong maintainers or submitting reports that > lack value. This seems like a serious issue. Could the kernel > community consider establishing a standardized process to reduce > wasted time on all sides and prevent researchers from inflating bug > counts just to validate their papers? Again: the standard mantra is "work wth upstream". If you forked syzbot and you're working on fuzzing, syzbot is your upstream, not the kernel. If you work with the syzbot people on getting your fuzz testing improvements merged, the process of reporting the bugs fuzzing finds to us kernel folks won't be on your plate anymore, and you get to focus on the stuff you actually want to be doing. :) > Link: https://github.com/google/syzkaller/blob/master/docs/linux/reporting_kernel_bugs.md > > It is often suggested that researchers collaborate with syzbot. What > should such collaboration look like in terms of form and content? From > a maintainer's perspective, how would you prefer to see researchers > who report bugs work with syzbot? Since I’m new to this field, I’m not > very familiar with the process and would greatly appreciate your > guidance. Talk to the syzbot folks, they're a friendly bunch :) The main thing to keep in mind is that it's never _just_ about getting your code merged, you need to spend some time learning the lay of the land so you can understand where your work fits in, and what people need and are interested in - you want to make sure that you're not duplicating work, and you want your code to be as maintainable and broadly useful to everone else as it can be. Have you shared with them what your research interests are?
