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;
Date:   Wed, 23 Nov 2022 23:26:43 +0800
From:   Pengfei Xu <pengfei.xu@intel.com>
To:     Peter Zijlstra <peterz@infradead.org>
CC:     <peter.zijlstra@intel.com>, <linux-kernel@vger.kernel.org>,
        <heng.su@intel.com>, Marco Elver <elver@google.com>,
        Mark Rutland <mark.rutland@arm.com>
Subject: Re: [Syzkaller & bisect] There is "__perf_event_overflow" WARNING in
 v6.1-rc5 kernel in guest
Message-ID: <Y347syXAYqnAsSDK@xpf.sh.intel.com>
References: <Y3RbiRmAKrDlVCxC@xpf.sh.intel.com>
 <Y3Z5WTk+cvHSt0lf@hirez.programming.kicks-ass.net>
 <Y3hDYiXwRnJr8RYG@xpf.sh.intel.com>
 <Y342qkDw7yqA1VOD@hirez.programming.kicks-ass.net>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Y342qkDw7yqA1VOD@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Z1IEXOGzL4a2xQOVHTVBZcFphj5qO2tN85/w3AQk6evNErWYuRFyysNVznrZ?=
 =?us-ascii?Q?HHGPVlddcD+8VYf2UrtilMnY2MQYncTLIPl5BlTz4iCfF9Jwqk5fj0mIWydf?=
 =?us-ascii?Q?r8v9h2EQ2RRMFgBaEdSE1uJTD4fnNpgwNW2weMkxVEZ9WN8prYrczixJjQI8?=
 =?us-ascii?Q?e7SK8Oyatp3VA4TIntuyYnQj/7NJaxii83k45/2XZybOf9RFdXYYhIJEkodM?=
 =?us-ascii?Q?wpuwO73Cd4JRWwpq/7mJZ2M18Km1DoIHTWleNOuDaJrFlg2Y+yuX+2R4Bd/A?=
 =?us-ascii?Q?A9HSH34DC1RrFJ/GuxPR9w98fPmishjKAwsHWjjxniwtCiwSm+0AlrX79wON?=
 =?us-ascii?Q?uoLi1WfXsBv4Es1ma58vct5PfsVqpOL7NmcEgIqssF/e22NF9Zd0MZziDUUw?=
 =?us-ascii?Q?06CQsPozBFYRqYjfyk4afx2f8gXEoBFqEz5OM9QtlyODjWzpmIhGmGKIOJDt?=
 =?us-ascii?Q?6631Oy46BMSnW04vWdqFhE2JH/ddvfpAtVI5NLNw18oN/DVK3qOmLZ7EU965?=
 =?us-ascii?Q?4mLE/VwdPYa6q9fxMMOM1ve18jHR12AqNV2dadKUdRfBVH6IJAotUuTKGc2J?=
 =?us-ascii?Q?3V1RJU/UIChbJvXD57pj/LCEnjN2Q1E/WrVq9A2zIp+p7rXXPsNnAk8VRRYW?=
 =?us-ascii?Q?GEnZjC3IYfiNvLPtIDMtsgQFerta8IMEgFdhYG/z/p/Nm8CV9RnTUzvtOWcN?=
 =?us-ascii?Q?sXfZYN03Jof89kg6Bvs571dNiHpnDa5GqhfLJDdQwL3bBaiFM7JkpGFVz7tG?=
 =?us-ascii?Q?yTR1JE/O5eINic9RfNUQINs9iyWFdEpnEuCofpHlk2AUmTzTJfjjrsqJ1jkm?=
 =?us-ascii?Q?VXnzkFQrpUr832cXyWc0QH0VbUMOIsR/Y4PZwwD1qV1CIaIPC2jDxty9/QYP?=
 =?us-ascii?Q?2QXiuGRuCmC9xpAYLhmW/LGNcsbjpQo4zs9J/gX19hgFUShgpSThwvfknYuh?=
 =?us-ascii?Q?xv6k26mqwBWjH1gZIq99EtntEVv2pJYlkq34ALAjTVxJttzT7H8J6RilBVCE?=
 =?us-ascii?Q?bKmRtbV7n+MP7gu6MAxCY7pgpu6VuCX/o9+kq+KOc+V6bDqLsjiD5NVOk3k6?=
 =?us-ascii?Q?VfUqMEZm46hMm53yOHoukNHC7tuH3rz5iXCwjpnwEMUg4hnulW/rB+aDRIuB?=
 =?us-ascii?Q?ScpdEi+sIfqwR3hhiSQT1XE1yerUNI/Ry1d/P22u8DdHRYQ2LNmHAHR/Onxm?=
 =?us-ascii?Q?cLakJ2DrC5XXjzmPETEspGIu2LoEvt6HjpeEvPhTccoy43Nd8mHxaqnd4H+l?=
 =?us-ascii?Q?0SKn+zCVf7/VY3nQWE69q2SowfZ0BC3PWg+1oVVJg9KzUkWpmooioHx0Qz3k?=
 =?us-ascii?Q?MTn7q64T82pDB5LRZ57uWZmoaAwGZe0zcuNhb1AQY8YfUpKz2hdtc2q9R/xO?=
 =?us-ascii?Q?WP95RQSFH6NqhM1TYQdjuLPqe+7Dn23tmOgJb4kgjJMMZeHRLIsnyUAZH2Yz?=
 =?us-ascii?Q?Q9yEZAe0ZRK84cJm9rW4uAyPXPlc1d/4BYGhQPkPNS/MtMOofsXsoOhEa3wP?=
 =?us-ascii?Q?QhnUcZh9SmRhhP73xJdaRq8NDduzruKRSpJDDXegHg+CweN7KWQ+G7I150+I?=
 =?us-ascii?Q?aTdEfN1SQ6GAQGWmh4+7KVnIbisnaBX053p2ETkojSAxBIfzFLtOqGN2EYnP?=
 =?us-ascii?Q?GQ=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 7beff52d-8d2e-40f3-3838-08dacd6712a1
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4839.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Nov 2022 15:26:20.5164
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Fx09F1P3enD9QgL1aX8EmGaUXZIEdwDzS2sstR83W2Iv7qR4ANEBigg37v5zjYW3copDMNfb7Ik+nIrEnNmsFA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB6702
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Peter,

On 2022-11-23 at 16:05:14 +0100, 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
> 
  Yes, sure, it's my pleasure! I will clone and test the origin/perf/urgent
  branch in this repo and update the email soon.
  git clone git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git time
  out in my side, and I git cloned https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git,
  it should be the same repo.

  Thanks!
  BR.

> ---
> Subject: perf: Consider OS filter fail
> From: Peter Zijlstra <peterz@infradead.org>
> 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 <pengfei.xu@intel.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Tested-by: Pengfei Xu <pengfei.xu@intel.com>
> Link: https://lkml.kernel.org/r/Y3hDYiXwRnJr8RYG@xpf.sh.intel.com
> ---
>  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);
>  	}