From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_HIGH,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B6F7C468BD for ; Sat, 8 Jun 2019 11:45:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3454821530 for ; Sat, 8 Jun 2019 11:45:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559994340; bh=8LE2e3SGba5lnFpm50ovF2Oc9Dmum+PlA1c7BdyGrlE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=W30dLy+GJ4rGP1OuQhFB+X3An6bpwYyo5CO9MRI8xNSocb9AuXCbIZ3kyU5zyHf21 19OdMd95XtQNB8oClce61Zbw/qO3Zr0X4mU+HkClOhPTFZUAmGPHNIVKIaMhXEv6a3 5Djh/oTUQ12o5uXxBI/+ctfFTCH0a+yFC+7uJ4cg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727965AbfFHLnT (ORCPT ); Sat, 8 Jun 2019 07:43:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:60562 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728690AbfFHLnS (ORCPT ); Sat, 8 Jun 2019 07:43:18 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A29A8214D8; Sat, 8 Jun 2019 11:43:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559994197; bh=8LE2e3SGba5lnFpm50ovF2Oc9Dmum+PlA1c7BdyGrlE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qGmjU8tL3F0u6lWojeCNlp6+Lfr6bF25UA/fN5Sm4xeUTNiGpcOejH2787w51YcJs lj49LeyDzzpKPnEhmsCeAgBiRar+sEgPtmjysta84jViPJ2i16tfupeWuaxEfP0umS 4FZEwjDm6aD/E0tZi3CD1EiH6LYv/K+SUdihJwBc= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yabin Cui , Peter Zijlstra , Alexander Shishkin , Arnaldo Carvalho de Melo , Arnaldo Carvalho de Melo , Jiri Olsa , Linus Torvalds , Namhyung Kim , Stephane Eranian , Thomas Gleixner , Vince Weaver , mark.rutland@arm.com, Ingo Molnar , Sasha Levin Subject: [PATCH AUTOSEL 4.19 13/49] perf/ring_buffer: Fix exposing a temporarily decreased data_head Date: Sat, 8 Jun 2019 07:41:54 -0400 Message-Id: <20190608114232.8731-13-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190608114232.8731-1-sashal@kernel.org> References: <20190608114232.8731-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Yabin Cui [ Upstream commit 1b038c6e05ff70a1e66e3e571c2e6106bdb75f53 ] In perf_output_put_handle(), an IRQ/NMI can happen in below location and write records to the same ring buffer: ... local_dec_and_test(&rb->nest) ... <-- an IRQ/NMI can happen here rb->user_page->data_head = head; ... In this case, a value A is written to data_head in the IRQ, then a value B is written to data_head after the IRQ. And A > B. As a result, data_head is temporarily decreased from A to B. And a reader may see data_head < data_tail if it read the buffer frequently enough, which creates unexpected behaviors. This can be fixed by moving dec(&rb->nest) to after updating data_head, which prevents the IRQ/NMI above from updating data_head. [ Split up by peterz. ] Signed-off-by: Yabin Cui Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: mark.rutland@arm.com Fixes: ef60777c9abd ("perf: Optimize the perf_output() path by removing IRQ-disables") Link: http://lkml.kernel.org/r/20190517115418.224478157@infradead.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin --- kernel/events/ring_buffer.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c index 99c7f199f2d4..31edf1f39cca 100644 --- a/kernel/events/ring_buffer.c +++ b/kernel/events/ring_buffer.c @@ -52,11 +52,18 @@ static void perf_output_put_handle(struct perf_output_handle *handle) head = local_read(&rb->head); /* - * IRQ/NMI can happen here, which means we can miss a head update. + * IRQ/NMI can happen here and advance @rb->head, causing our + * load above to be stale. */ - if (!local_dec_and_test(&rb->nest)) + /* + * If this isn't the outermost nesting, we don't have to update + * @rb->user_page->data_head. + */ + if (local_read(&rb->nest) > 1) { + local_dec(&rb->nest); goto out; + } /* * Since the mmap() consumer (userspace) can run on a different CPU: @@ -88,9 +95,18 @@ static void perf_output_put_handle(struct perf_output_handle *handle) rb->user_page->data_head = head; /* - * Now check if we missed an update -- rely on previous implied - * compiler barriers to force a re-read. + * We must publish the head before decrementing the nest count, + * otherwise an IRQ/NMI can publish a more recent head value and our + * write will (temporarily) publish a stale value. + */ + barrier(); + local_set(&rb->nest, 0); + + /* + * Ensure we decrement @rb->nest before we validate the @rb->head. + * Otherwise we cannot be sure we caught the 'last' nested update. */ + barrier(); if (unlikely(head != local_read(&rb->head))) { local_inc(&rb->nest); goto again; -- 2.20.1