From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754267AbdJaKJB (ORCPT ); Tue, 31 Oct 2017 06:09:01 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:37668 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753027AbdJaKI7 (ORCPT ); Tue, 31 Oct 2017 06:08:59 -0400 Date: Tue, 31 Oct 2017 11:08:52 +0100 From: Peter Zijlstra To: Dmitry Vyukov Cc: syzbot , dvhart@infradead.org, LKML , Ingo Molnar , syzkaller-bugs@googlegroups.com, Thomas Gleixner Subject: Re: WARNING in get_pi_state Message-ID: <20171031100852.pdifddw4lkc5fqfc@hirez.programming.kicks-ass.net> References: <001a113a67502e70f4055cc8dc92@google.com> <20171031091603.plulggamkcfh7k3u@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 31, 2017 at 12:29:50PM +0300, Dmitry Vyukov wrote: > I understand your sentiment, but it's definitely not _at all_. The > system compiled this exact code, run it and triggered the bug on it. > Do you have suggestions on how to make this code more portable? How > does this setup would look on your system? So I don't see the point of that tun stuff; what was is supposed to do? All it ever did after creation was flush_tun(), which reads until empty. But given nobody would ever write into it, that's an 'expensive' NO-OP. > We do try hard to get rid of unnecessary stuff in reproducers. I think > what happened in this case is the following. This is a hard to > reproduce race. The bot was able to reproduce the crash on initial > program that uses tun, then tried to get rid of tun code and > re-reproduce it, but it did not reproduce this time, so it concluded > that tun code is somehow necessary here. That's unfortunate > consequence of testing complex concurrent code. May become somewhat > better once we have KTSAN, the race detector. I ripped out the tun bits and it reproduced in ~100 seconds. I've now got it running for well over 30m on the fixed kernel while I'm trying to come up with a comprehensible Changelog ;-)