Dmitry Vyukov
Dmitry Vyukov
> But for older ones we'd still have to invoke older syz-prog2c versions, right? Or, probably, just ignore the syz repro bugs in this export? There are not too many...
> What about private namespaces? More git repos? I would export into a single repo all reproducers that were obtained on kernels with public source code. > How to track...
@gkennedy12 also periodically [asks for updates](https://groups.google.com/g/syzkaller/c/Pc6PPk7uopM/m/suXQXnTvAAAJ) (which unfortunately slept through the cracks).
What's the use case for separating them by namespace? We can also export from non-public but open-source kernels (that's that I used to do). + store all tentative C repros...
> > and monitor these reproducers > > What is it about? Detect that they triggered a bug. Lots of kernel test suites just run tests and then ignore actual...
> Detect that they triggered a bug. Lots of kernel test suites just run tests and then ignore actual bugs they provoked in the kernel, so tests look like passing....
Seems reasonable. Thanks. Waiting for CI to pass.
CI complains about commit message and code formatting, these need to be fixed before we can merge: ``` Error: Wrong commit subject format: '[vm/bhyve]: added customizable bhyve arguments'. Please use...
We now keep more old programs in the manager. So I think this can be considered fixed.
Meanwhile you may add bug types you don't want to reproduce to the suppression section of the config.