Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 23 May 2019 07:03:56 -0700
From:   "Paul E. McKenney" <paulmck@linux.ibm.com>
To:     Dmitry Vyukov <dvyukov@google.com>
Cc:     Andrea Parri <andrea.parri@amarulasolutions.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Dhaval Giani <dhaval.giani@gmail.com>,
        Sasha Levin <alexander.levin@microsoft.com>,
        shuah <shuah@kernel.org>, Kevin Hilman <khilman@baylibre.com>,
        Tim Bird <tbird20d@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        "Carpenter,Dan" <dan.carpenter@oracle.com>,
        Matthew Wilcox <willy@infradead.org>,
        gustavo padovan <gustavo.padovan@collabora.co.uk>,
        knut omang <knut.omang@oracle.com>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Alan Stern <stern@rowland.harvard.edu>
Subject: Re: Linux Testing Microconference at LPC
Reply-To: paulmck@linux.ibm.com
References: <CAPhKKr_uVTFAzne0QkZFUGfb8RxQdVFx41G9kXRY7sFN-=pZ6w@mail.gmail.com>
 <20190423102250.GA56999@lakrids.cambridge.arm.com>
 <20190512004008.GA6062@andrea>
 <CACT4Y+aj8i0VNad91F-QkHNsXYXUFrYF+j=wnG-USzfQfoD55A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACT4Y+aj8i0VNad91F-QkHNsXYXUFrYF+j=wnG-USzfQfoD55A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-Id: <20190523140356.GN28207@linux.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, May 22, 2019 at 05:52:17PM +0200, Dmitry Vyukov wrote:
> On Sun, May 12, 2019 at 2:40 AM Andrea Parri
> <andrea.parri@amarulasolutions.com> wrote:
> >
> > On Tue, Apr 23, 2019 at 11:22:50AM +0100, Mark Rutland wrote:
> > > On Thu, Apr 11, 2019 at 10:37:51AM -0700, Dhaval Giani wrote:
> > > > Hi Folks,
> > > >
> > > > This is a call for participation for the Linux Testing microconference
> > > > at LPC this year.
> > > >
> > > > For those who were at LPC last year, as the closing panel mentioned,
> > > > testing is probably the next big push needed to improve quality. From
> > > > getting more selftests in, to regression testing to ensure we don't
> > > > break realtime as more of PREEMPT_RT comes in, to more stable distros,
> > > > we need more testing around the kernel.
> > > >
> > > > We have talked about different efforts around testing, such as fuzzing
> > > > (using syzkaller and trinity), automating fuzzing with syzbot, 0day
> > > > testing, test frameworks such as ktests, smatch to find bugs in the
> > > > past. We want to push this discussion further this year and are
> > > > interested in hearing from you what you want to talk about, and where
> > > > kernel testing needs to go next.
> > >
> > > I'd be interested to discuss what we could do with annotations and
> > > compiler instrumentation to make the kernel more amenable to static and
> > > dynamic analysis (and to some extent, documenting implicit
> > > requirements).
> > >
> > > One idea that I'd like to explore in the context of RT is to annotate
> > > function signatures with their required IRQ/preempt context, such that
> > > we could dynamically check whether those requirements were violated
> > > (even if it didn't happen to cause a problem at that point in time), and
> > > static analysis would be able to find some obviously broken usage. I had
> > > some rough ideas of how to do the dynamic part atop/within ftrace. Maybe
> > > there are similar problems elsewhere.
> > >
> > > I know that some clang folk were interested in similar stuff. IIRC Nick
> > > Desaulniers was interested in whether clang's thread safety analysis
> > > tooling could be applied to the kernel (e.g. based on lockdep
> > > annotations).
> >
> > FWIW, I'd also be interested in discussing these developments.
> >
> > There have been several activities/projects related to such "tooling"
> > (thread safety analysis) recently:  I could point out the (brand new)
> > Google Summer of Code "Applying Clang Thread Safety Analyser to Linux
> > Kernel" project [1] and (for the "dynamic analysis" side) the efforts
> > to revive the Kernel Thread sanitizer [2].  I should also mention the
> > efforts to add (support for) "unmarked" accesses and to formalize the
> > notion of "data race" in the memory consistency model [3].
> >
> > So, again, I'd welcome a discussion on these works/ideas.
> >
> > Thanks,
> >   Andrea
> 
> I would be interested in discussing all of this too: thread safety
> annotations, ktsan, unmarked accesses.

Sounds like a great discussion!  Might this fit into Sasha Levin's
and Dhaval Giani's proposed Testing & Fuzzing MC?

							Thanx, Paul