From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752079AbcKGVjB (ORCPT ); Mon, 7 Nov 2016 16:39:01 -0500 Received: from mail-pf0-f176.google.com ([209.85.192.176]:33993 "EHLO mail-pf0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751332AbcKGVi7 (ORCPT ); Mon, 7 Nov 2016 16:38:59 -0500 Date: Mon, 7 Nov 2016 12:35:42 -0800 From: Alexei Starovoitov To: Steven Rostedt Cc: Martin KaFai Lau , linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: ftrace module init race/bug Message-ID: <20161107203540.GA29563@ast-mbp.thefacebook.com> References: <20161107194621.GA28484@ast-mbp.thefacebook.com> <20161107150841.04577223@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161107150841.04577223@gandalf.local.home> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 07, 2016 at 03:08:41PM -0500, Steven Rostedt wrote: > On Mon, 7 Nov 2016 11:46:24 -0800 > Alexei Starovoitov wrote: > > > Hi Steven, > > > > I'm debugging the following spew: > > > > [ 7139.111213] WARNING: CPU: 8 PID: 856649 at kernel/trace/ftrace.c:2747 ftrace_shutdown+0x263/0x270 > > What kernel version is this, as that line number doesn't line up to > nay warning on 4.9 on 4.9-rc1. it's our 4.6 with backports. It's line 2766 in 4.9 and as far as I can tell the ftrace logic is the same, so pretty sure it's applicable, but... no reproducer available. Only this spew. > > do you think the following diff is enough to silence the warning > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > > index b1870fbd2b67..edb00bf70d84 100644 > > --- a/kernel/trace/ftrace.c > > +++ b/kernel/trace/ftrace.c > > @@ -2744,7 +2744,7 @@ static int ftrace_shutdown(struct ftrace_ops *ops, int command) > > struct dyn_ftrace *rec; > > > > do_for_each_ftrace_rec(pg, rec) { > > - if (FTRACE_WARN_ON_ONCE(rec->flags)) > > + if (FTRACE_WARN_ON_ONCE(rec->flags & ~FTRACE_FL_DISABLED)) > > pr_warn(" %pS flags:%lx\n", > > (void *)rec->ip, rec->flags); > > } while_for_each_ftrace_rec(); > > > > or it's a tip of an iceberg and less hacky fix is needed? > > Actually, this may be correct. I need to audit the other > do_for_each_ftrace_rec() loops. yep, the __ftrace_hash_rec_update() has !FTRACE_FL_DISABLED check, so I thought ftrace_shutdown() may need it too. Should I send the above patch with proper sob?