Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965792AbeAKT5a (ORCPT + 1 other); Thu, 11 Jan 2018 14:57:30 -0500 Received: from mail-it0-f50.google.com ([209.85.214.50]:45511 "EHLO mail-it0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932431AbeAKT52 (ORCPT ); Thu, 11 Jan 2018 14:57:28 -0500 X-Google-Smtp-Source: ACJfBosq/zNMxWyTypFd/RLZYnj+50DTO7nc1xjnwcb9vE35diXEs9eU5BmAN+PqNZECtr9IUPcGag== From: Vince Weaver X-Google-Original-From: Vince Weaver Date: Thu, 11 Jan 2018 14:57:25 -0500 (EST) X-X-Sender: vince@macbook-air To: Peter Zijlstra cc: Josh Poimboeuf , Vince Weaver , Ingo Molnar , linux-kernel@vger.kernel.org, Ingo Molnar , Arnaldo Carvalho de Melo , Thomas Gleixner , Andy Lutomirski Subject: Re: perf: perf_fuzzer quickly locks up on 4.15-rc7 In-Reply-To: <20180111195018.GB3397@worktop> Message-ID: References: <20180109151253.GK6176@hirez.programming.kicks-ass.net> <20180109153341.GL6176@hirez.programming.kicks-ass.net> <20180109160551.GK3040@hirez.programming.kicks-ass.net> <20180109170716.bqmexpmywwr4bwuv@treble> <20180111052538.2qhj6oxnc24xumhk@treble> <20180111192112.d35nkotzklicd27c@treble> <20180111195018.GB3397@worktop> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, 11 Jan 2018, Peter Zijlstra wrote: > On Thu, Jan 11, 2018 at 01:21:12PM -0600, Josh Poimboeuf wrote: > > Yuck. This time it was stack recursion on the entry stack. In the > > previous error, recursion was detected on the IRQ stack. Otherwise they > > look quite similar. > > > > Was that also with nopti? > > Both with pti enabled, nopti makes things work again. I think I have hit those errors even with pti disabled but now I'll have to double check. > > I haven't had a chance to try it yet, any idea if these would be > > recreatable in a VM? > > Good question; typically we run the perf fuzzer on read hardware because > the PMU doesn't virtualize much. But if software perf is enough to > trigger this, that would certainly help. I can only trigger them with perf_event_paranoid=0 (not with perf_event_paranoid=2) so it might depend on how much of the PMU is virtualized. Vince