Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp1135858ybl; Fri, 16 Aug 2019 09:26:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqzRpZWBg7w8cOLxkfF9GqC+yVGtt1LrdavArytC6W4MbuhVu0ye+QM1HX0cE4xyIdMUTWUM X-Received: by 2002:a17:90a:5884:: with SMTP id j4mr8393638pji.142.1565972801019; Fri, 16 Aug 2019 09:26:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565972801; cv=none; d=google.com; s=arc-20160816; b=Tb9YcF6D466HQH8nfTdtfCEbI8/znYwPIcTcHdkjoVw5aBeD2VXbxFNMFST3SNwy/b C4pf99cvm4/ibvBeU8qnkRHrJG12eCxy21XcCJSBAYlESXshrQ+g9ntqBwGcc0Mk3rfl QKbgX7zUZuF5+DkF4FWvZBVJPb2mlXScO25CCq04wfPGQtpgPs2WvJguiRjVxVno4xPE x3SxIasr5r+ZZg9KHxTGtQ2cPdblaPXRksbsoRPn5bmIuz7QaAvCQ4UQFCaFysmS/9CV KKn4OhHcH+1Or/ktrQ4fnU29CGFUlKhxRQWejg8uyRHifnns7AmLMO+EHRRi4vN70kFQ ulEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=Ccc+Mq+3J4L27922Su+pGr9oaSkHrJjLg7Onk+M3Q+o=; b=AxV37kkReE1FnkcWIUE2w3+p5zsDx9v0j1gG4s5dJbgVFxlA9e/fhJtWNlY2H9vu19 vmAl0nZKij7JVaqIdY5ZhjhyGtCSdO/fJa9EYhw7qKoc7xcb4/3iF64rrhKIHYkwpWep NJZ241+sGO4aCoZd2xrx0TzQtQuZOzrEARLea1cmkx9leBrPx7/yIBzTLilbkb6RvLE8 UnVr0/E08zQh1kdKWEvT+D67Ay6G5yomMObFTYOgszYtf4n5cJ+mbmrAzYz3PeEUdMv3 cSNGMCAosNayeduMpenTM/k9VGcKyk84zQYJesh+Jh7J8z4i6rqPcRauqGxK5drgfZrr 3fWw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o4si4350981pls.36.2019.08.16.09.26.25; Fri, 16 Aug 2019 09:26:41 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726550AbfHPQZq (ORCPT + 99 others); Fri, 16 Aug 2019 12:25:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:48474 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726097AbfHPQZq (ORCPT ); Fri, 16 Aug 2019 12:25:46 -0400 Received: from oasis.local.home (rrcs-76-79-140-27.west.biz.rr.com [76.79.140.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 04F3320665; Fri, 16 Aug 2019 16:25:44 +0000 (UTC) Date: Fri, 16 Aug 2019 12:25:39 -0400 From: Steven Rostedt To: Mathieu Desnoyers Cc: linux-kernel@vger.kernel.org, Joel Fernandes , Peter Zijlstra , Thomas Gleixner , "Paul E . McKenney" Subject: Re: [PATCH 1/1] Fix: trace sched switch start/stop racy updates Message-ID: <20190816122539.34fada7b@oasis.local.home> In-Reply-To: <20190816142643.13758-1-mathieu.desnoyers@efficios.com> References: <00000000000076ecf3059030d3f1@google.com> <20190816142643.13758-1-mathieu.desnoyers@efficios.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 16 Aug 2019 10:26:43 -0400 Mathieu Desnoyers wrote: > Reading the sched_cmdline_ref and sched_tgid_ref initial state within > tracing_start_sched_switch without holding the sched_register_mutex is > racy against concurrent updates, which can lead to tracepoint probes > being registered more than once (and thus trigger warnings within > tracepoint.c). > > Also, write and read to/from those variables should be done with > WRITE_ONCE() and READ_ONCE(), given that those are read within tracing > probes without holding the sched_register_mutex. > I understand the READ_ONCE() but is the WRITE_ONCE() truly necessary? It's done while holding the mutex. It's not that critical of a path, and makes the code look ugly. -- Steve > [ Compile-tested only. I suspect it might fix the following syzbot > report: > > syzbot+774fddf07b7ab29a1e55@syzkaller.appspotmail.com ] > > Signed-off-by: Mathieu Desnoyers > CC: Joel Fernandes (Google) > CC: Peter Zijlstra > CC: Steven Rostedt (VMware) > CC: Thomas Gleixner > CC: Paul E. McKenney > --- > kernel/trace/trace_sched_switch.c | 32 ++++++++++++++++++++++---------- > 1 file changed, 22 insertions(+), 10 deletions(-) > > diff --git a/kernel/trace/trace_sched_switch.c b/kernel/trace/trace_sched_switch.c > index e288168661e1..902e8bf59aeb 100644 > --- a/kernel/trace/trace_sched_switch.c > +++ b/kernel/trace/trace_sched_switch.c > @@ -26,8 +26,8 @@ probe_sched_switch(void *ignore, bool preempt, > { > int flags; > > - flags = (RECORD_TGID * !!sched_tgid_ref) + > - (RECORD_CMDLINE * !!sched_cmdline_ref); > + flags = (RECORD_TGID * !!READ_ONCE(sched_tgid_ref)) + > + (RECORD_CMDLINE * !!READ_ONCE(sched_cmdline_ref)); > > if (!flags) > return; > @@ -39,8 +39,8 @@ probe_sched_wakeup(void *ignore, struct task_struct *wakee) > { > int flags; > > - flags = (RECORD_TGID * !!sched_tgid_ref) + > - (RECORD_CMDLINE * !!sched_cmdline_ref); > + flags = (RECORD_TGID * !!READ_ONCE(sched_tgid_ref)) + > + (RECORD_CMDLINE * !!READ_ONCE(sched_cmdline_ref)); > > if (!flags) > return; > @@ -89,21 +89,28 @@ static void tracing_sched_unregister(void) > > static void tracing_start_sched_switch(int ops) > { > - bool sched_register = (!sched_cmdline_ref && !sched_tgid_ref); > + bool sched_register; > + > mutex_lock(&sched_register_mutex); > + sched_register = (!sched_cmdline_ref && !sched_tgid_ref); > > switch (ops) { > case RECORD_CMDLINE: > - sched_cmdline_ref++; > + WRITE_ONCE(sched_cmdline_ref, sched_cmdline_ref + 1); > break; > > case RECORD_TGID: > - sched_tgid_ref++; > + WRITE_ONCE(sched_tgid_ref, sched_tgid_ref + 1); > break; > + > + default: > + WARN_ONCE(1, "Unsupported tracing op: %d", ops); > + goto end; > } > > - if (sched_register && (sched_cmdline_ref || sched_tgid_ref)) > + if (sched_register) > tracing_sched_register(); > +end: > mutex_unlock(&sched_register_mutex); > } > > @@ -113,16 +120,21 @@ static void tracing_stop_sched_switch(int ops) > > switch (ops) { > case RECORD_CMDLINE: > - sched_cmdline_ref--; > + WRITE_ONCE(sched_cmdline_ref, sched_cmdline_ref - 1); > break; > > case RECORD_TGID: > - sched_tgid_ref--; > + WRITE_ONCE(sched_tgid_ref, sched_tgid_ref - 1); > break; > + > + default: > + WARN_ONCE(1, "Unsupported tracing op: %d", ops); > + goto end; > } > > if (!sched_cmdline_ref && !sched_tgid_ref) > tracing_sched_unregister(); > +end: > mutex_unlock(&sched_register_mutex); > } >