Re: [Announce] LPC 2018: Testing and Fuzzing Microconference

[Dmitry Vyukov]

On Wed, Oct 10, 2018 at 5:47 PM, Dhaval Giani <dhaval.giani@xxxxxxxxx> wrote:
> On Mon, Oct 8, 2018 at 11:23 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>>
>> On Mon, 8 Oct 2018 19:02:51 +0200
>> Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
>>
>> > On Wed, Sep 19, 2018 at 7:13 PM, Dhaval Giani <dhaval.giani@xxxxxxxxx> wrote:
>> > > Hi folks,
>> > >
>> > > Sasha and I are pleased to announce the Testing and Fuzzing track at
>> > > LPC [ 1 ]. We are planning to continue the discussions from last
>> > > year's microconference [2]. Many discussions from the Automated
>> > > Testing Summit [3] will also continue, and a final agenda will come up
>> > > only soon after that.
>> > >
>> > > Suggested Topics
>> > >
>> > > - Syzbot/syzkaller
>> > > - ATS
>> > > - Distro/stable testing
>> > > - kernelci
>> > > - kernelci auto bisection
>> > > - Unit testing framework
>> > >
>> > > We look forward to other interesting topics for this microconference
>> > > as a reply to this email.
>> >
>> > Hi Dhaval and Sasha,
>> >
>> > My syzbot talk wasn't accepted to main track, so I would like to do
>> > more or less full-fledged talk on the microconf. Is it possible?
>>
>> Hi Dmitry,
>>
>> Note, microconfs are not for full-fledged talks. They are to be
>> discussion focused. You can have a 5-10 minute presentation that leads
>> up to discussion of future work, but we like to refrain from any talks
>> about what was done if there's nothing to go forward with.
>
> Dmitiry,
>
> Can you clarify the scope of what you want to discuss during the
> microconference? Further to what Steven said, we don't want
> presentations (So 3, maybe 4 slides). We want discussions about future
> work.
>
> Thanks!
> Dhaval


Hi Steven, Dhaval,

Acknowledged.

Then smaller topic that would benefit from discussion are:

the main one being:

1. syzbot: developer process; unfixed bugs; bug triage; what's
working? what's not? why? how can we make more parts work? collecting
feedback

2. how to increase test coverage/find more bugs, in particular:
 - adding manual spot KASAN/KMSAN checks into kernel codebase
 - stubbing hardware/external inputs to kernel for testing
 - description of kernel interfaces (again)

3. dealing with kernel console output mess
 - intermixed/split lines
 - understand when/how kernel crashed
 - and where is that message
 - crash identity