linux-kernel - Re: Kernel regression tracking/reporting initiatives and KCIDB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87jztohemn.fsf@collabora.com>
Date:   Mon, 21 Aug 2023 12:30:08 +0200
From:   Ricardo Cañuelo <ricardo.canuelo@...labora.com>
To:     Guillaume Tucker <guillaume.tucker@...labora.com>,
        kernelci@...ts.linux.dev, gregkh@...uxfoundation.org,
        thorsten@...mhuis.info, regressions@...ts.linux.dev
Cc:     kernel@...labora.com, linux-kernel@...r.kernel.org,
        Gustavo Padovan <gustavo.padovan@...labora.com>,
        Shreeya Patel <shreeya.patel@...labora.com>
Subject: Re: Kernel regression tracking/reporting initiatives and KCIDB

On vie, ago 18 2023 at 22:11:52, Guillaume Tucker <guillaume.tucker@...labora.com> wrote:
> KernelCI is not any CI, it's designed to be the main system for
> the upstream kernel.  So it already took the high-level approach
> to look at all this after becoming an LF project and we came up
> with KCIDB and now the new API as the community still needs
> an "active" system and not just a database for collecting data
> from other systems.

That sounds good and I think that's the way to go, but does that mean
that, in theory, most or all current CI systems (0-day, CKI, etc) will
"push" their results to the new KernelCI in the future?

> Right, except you might hit another deprecation hurdle if we
> start changing how things are designed around KCIDB and the new
> API.  There's no doubt KCIDB will be supported for a long time,
> but taking into considerations all the new developments can save
> you a lot of trouble.

So, if using KCIDB as a data source is not a good idea right now, do you
have any suggestions on how to keep contributing to the improvement of
regression analysis?

If the new KernelCI API is already working with a large enough
regression database maybe this analysis work can be plugged into the
pipeline and we can start working on that.

> My point here is that KernelCI started tackling this issue of
> reporting kernel bugs several years ago at a very high level and
> we've come up with some carefully engineered solutions for it, so
> it looks like you're walking in our footsteps now.  The new web
> dashboard, new API & Pipeline and KCIDB which pioneered working
> outside the native realm of KernelCI provide some answers to the
> challenges you're currently investigating.  So maybe it is
> actually the best strategy for you to carry on doing things
> independently, but it would seem to me like due diligence for
> each of us to know what others are doing.

I surely must have missed most of those discussions but I couldn't find
any traces of the functionalities I listed either in a design document
or implemented anywhere. We certainly wouldn't have started this stream
of work if we knew this was already a work in progress. If there are
already concrete plans and some kind of design for this, let me know so
we can contribute to it.

If the solutions that have been engineered so far are still unplanned,
then I agree it'll be better to keep improving on this
independently. But in order to do that we'd need to be able to use other
data sources (KCIDB). Then, once the new KernelCI is ready to implement
these functionalities we can try to move them there after they've been
tested independently.

Cheers,
Ricardo