Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp8557576rwb; Thu, 24 Nov 2022 00:53:59 -0800 (PST) X-Google-Smtp-Source: AA0mqf4KiN7VoOQh+BL9zR3Ze5fAtcl2D2xz5jbpNgbTwjJUtzc79riXoRSqCNNPzl76S2VOO+4q X-Received: by 2002:a17:90a:8a86:b0:212:ec84:91d9 with SMTP id x6-20020a17090a8a8600b00212ec8491d9mr41465090pjn.139.1669280039264; Thu, 24 Nov 2022 00:53:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669280039; cv=none; d=google.com; s=arc-20160816; b=nXJ5jdTI++Ent2IJTUQ74xvPNhRHMRTzTagfjkjXVfLtj5ykKtmIj1DrDJKzDba/te OK/k8XukI7A/JOCK4bnoHoYQITaqorsAaR2/R4D5CC9GAQApDAPBuY4LnyyDMHWIIXT+ RFJ9vnV6QiuC6lDtDktzMbmOxv1kGSz16scisTVCZDJbVelxhaJwYfIDJN2asErk58GY IIICLE0IdbIBaTL1BL6L+4v0fd+F+vCkUj5WU0SXySLQ/WorydDCSvnK12a4jmli6iC1 WARB1kDmxiKsjnG500KEJE1l+W0p1azg2lQ6PPh0FUuDQlWAu5M7IzzuNTWG+pp1Yl21 kK8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=GIX8Qnm799zO1cdHABBf5oTsapUrm+E7rvTghMjWXdo=; b=QL26yiVpDpn+mZuKsj+fOQZxaVZPevFfQwMn7Xl9B1w70hybX0pgkhhRKogd0SSUl1 /v7peEySvLJqus3ncaqZwBAWreXAcN4EG9qtj8Df8rL4/vsDyoVMqee/X0iD4iSvPXUM t7DRtzps+A1dv5Zw+6/cNfpDBMf2tqxh3TnykXC0d5dJoiYoBklkjn2rvSl7zcq69p6u P0TNOXg9Poaq9QwV8xadKdKhmMkq5zwd+EheTBPAjdwAwmoES2eRKywJeRh5pC/RQUqQ F8O5oNJZu3dHbpTdzy5+0rKm/wMTN1oJpCSBnYOMkR1FLFTOsLWdCqK6Fv0J6d87xoBq dkTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="NL8/AMqy"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z17-20020a170903019100b00184c33ddeb8si531909plg.23.2022.11.24.00.53.46; Thu, 24 Nov 2022 00:53:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="NL8/AMqy"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229751AbiKXIbx (ORCPT + 87 others); Thu, 24 Nov 2022 03:31:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229512AbiKXIbv (ORCPT ); Thu, 24 Nov 2022 03:31:51 -0500 Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A0EDEC9AB7 for ; Thu, 24 Nov 2022 00:31:47 -0800 (PST) Received: by mail-yb1-xb36.google.com with SMTP id i131so1048134ybc.9 for ; Thu, 24 Nov 2022 00:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GIX8Qnm799zO1cdHABBf5oTsapUrm+E7rvTghMjWXdo=; b=NL8/AMqyX/iY/osJzwzEOkmcdEIDFxin9toCDIysA1cE9EqFQxsEfU4o6QtGfB42vJ Aha6ojRqykynBJoTTMqoplog3gitGW4w9lku7U+6dFE8/JsKRShzV0XHiCzTxRWTh+Oz WYUKkFZ5uPQjKsjrpEPyQAGzqt+Fm6QmY2jDbWK6liBs02w983oh92Ftl7EBqeWimzvD d7O018bYQRK5vx4zThbofKfM07icbGXzQVN9SwxASsBlYa/nqzZAZEuAsnhULFvb8cXJ yOHODY3M9vjWTsRhFQh7SjlhD+5nmnsaCDSQYQ2FhtOJf8jmCQkAkPXEn7qtg8lEmSwM 51PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GIX8Qnm799zO1cdHABBf5oTsapUrm+E7rvTghMjWXdo=; b=Ds1d5wck3sm2xI7oSBTrK3meBogPvQFslq3Y80KWY4iYb1UX0lDhB9KiXctIwX4Bl1 O+epXNH+0nJsG1+26zG39wfi7pl1A731D/kv3Qk3x3mONWOLVSQZ8IHnnxn0sJ4yJHoP QeLgDK+suRJLuyf6A+63DyxBaxU4jcvji36YrWOpk3ant439djgXiynh5KBrwkN2fe3i H9rGpBCIP/fqOldNfvATgonOUSd1J+xK0LKu/uU203z17+fVwROyDK56k3BQyoJ3UnTb k6bKnlaWrNbTuxBP40yTq5qYSNJ0Wpz6Uqrap0m0HmfJt+lBqnx2nWEesI5QtK6GgXYJ lXuA== X-Gm-Message-State: ANoB5pmCS0x71ik8xK7JOGXGfgDa68jEEB10Lwfqln0cHtW3wa7in1AA 10tKXV9GTLQwzICRgGjKH99Vpb+rRTwNbr728q24Sg== X-Received: by 2002:a05:6902:1825:b0:6de:f09:2427 with SMTP id cf37-20020a056902182500b006de0f092427mr11694276ybb.125.1669278706819; Thu, 24 Nov 2022 00:31:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Marco Elver Date: Thu, 24 Nov 2022 09:31:10 +0100 Message-ID: Subject: Re: [Syzkaller & bisect] There is "__perf_event_overflow" WARNING in v6.1-rc5 kernel in guest To: Peter Zijlstra Cc: Pengfei Xu , peter.zijlstra@intel.com, linux-kernel@vger.kernel.org, heng.su@intel.com, Mark Rutland Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 23 Nov 2022 at 16:05, Peter Zijlstra wrote: > > On Sat, Nov 19, 2022 at 10:45:54AM +0800, Pengfei Xu wrote: > > > The result shows that your additional patch fixed this issue! > > If possible, could you add Reported-and-tested-by tag from me. > > After talking with Marco for a bit the patch now looks like the below. > I've tentatively retained your tested-by, except of course, you haven't. > > If I could bother you once more to test the branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/urgent > > --- > Subject: perf: Consider OS filter fail > From: Peter Zijlstra > Date: Sat, 19 Nov 2022 10:45:54 +0800 > > Some PMUs (notably the traditional hardware kind) have boundary issues > with the OS filter. Specifically, it is possible for > perf_event_attr::exclude_kernel=1 events to trigger in-kernel due to > SKID or errata. > > This can upset the sigtrap logic some and trigger the WARN. > > However, if this invalid sample is the first we must not loose the > SIGTRAP, OTOH if it is the second, it must not override the > pending_addr with an invalid one. > > Fixes: ca6c21327c6a ("perf: Fix missing SIGTRAPs") > Reported-by: Pengfei Xu > Signed-off-by: Peter Zijlstra (Intel) > Tested-by: Pengfei Xu > Link: https://lkml.kernel.org/r/Y3hDYiXwRnJr8RYG@xpf.sh.intel.com Thanks, FWIW Reviewed-by: Marco Elver One thing I wondered was, if the event fired in the kernel due to skid, is the addr always some kernel address, or does this also depend on the type of PMU? In any case, we don't even want to risk leaking kernel addresses this way, so this looks sane. > --- > kernel/events/core.c | 24 ++++++++++++++++++++++-- > 1 file changed, 22 insertions(+), 2 deletions(-) > > --- a/kernel/events/core.c > +++ b/kernel/events/core.c > @@ -9273,6 +9273,19 @@ int perf_event_account_interrupt(struct > return __perf_event_account_interrupt(event, 1); > } > > +static inline bool sample_is_allowed(struct perf_event *event, struct pt_regs *regs) > +{ > + /* > + * Due to interrupt latency (AKA "skid"), we may enter the > + * kernel before taking an overflow, even if the PMU is only > + * counting user events. > + */ > + if (event->attr.exclude_kernel && !user_mode(regs)) > + return false; > + > + return true; > +} > + > /* > * Generic event overflow handling, sampling. > */ > @@ -9306,6 +9319,13 @@ static int __perf_event_overflow(struct > } > > if (event->attr.sigtrap) { > + /* > + * The desired behaviour of sigtrap vs invalid samples is a bit > + * tricky; on the one hand, one should not loose the SIGTRAP if > + * it is the first event, on the other hand, we should also not > + * trigger the WARN or override the data address. > + */ > + bool valid_sample = sample_is_allowed(event, regs); > unsigned int pending_id = 1; > > if (regs) > @@ -9313,7 +9333,7 @@ static int __perf_event_overflow(struct > if (!event->pending_sigtrap) { > event->pending_sigtrap = pending_id; > local_inc(&event->ctx->nr_pending); > - } else if (event->attr.exclude_kernel) { > + } else if (event->attr.exclude_kernel && valid_sample) { > /* > * Should not be able to return to user space without > * consuming pending_sigtrap; with exceptions: > @@ -9330,7 +9350,7 @@ static int __perf_event_overflow(struct > } > > event->pending_addr = 0; > - if (data->sample_flags & PERF_SAMPLE_ADDR) > + if (valid_sample && (data->sample_flags & PERF_SAMPLE_ADDR)) > event->pending_addr = data->addr; > irq_work_queue(&event->pending_irq); > }