From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 45A4E367F22 for ; Tue, 19 May 2026 05:59:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.9 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779170343; cv=fail; b=rdO35HJjMbOOtt2CtXmr5RyN9fbCKlbA4tmg+iSnMetqoVgLg+581noGZFc5/chCEe40Y5PUxU9jfvZzHlb6t6w+3wj3pNTo2DrTjZU5C0jLFR3B1u+5W2ymTsVjEVppnIde5msB6OV+Aa8UaT4kTjqnCnSLiJNfiKvDwB5QQ7Y= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779170343; c=relaxed/simple; bh=yZVmm848Bm5LiQdaUFfUIbyLEBwxEBPkEosBiTENf+c=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=h+g4ibrcMI50s+AHRQq4X3SxNX3MTV9mI2ckqq9eeVmbOAnumEXlAhTpeoFATITCB23naECeB+NC6hP+CYgF9i4bue4d4oIRqU/84UxmIVtVgmGuKXaaCYTIB3b12xRnH6nDvY8UoNXzy1pR/kmISI92i1Y8atRGzSh34M8C3tE= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=IRuulbYz; arc=fail smtp.client-ip=198.175.65.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="IRuulbYz" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1779170342; x=1810706342; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=yZVmm848Bm5LiQdaUFfUIbyLEBwxEBPkEosBiTENf+c=; b=IRuulbYzB1MWEySuLK9JK058baXV/qwR13kGlgZ1XiQjt5jfb7ULU8pk cTb4psY7IFSwBI46hFkZ4WWm/DmdP3w/h2SrzJW0I6YBXhZsRbShuWXTs RD2pFPLxGZuNm2CL3gx0+LIoLnZlkG3TX79ekOHYEIzQQhDKFVNUhA/sc MdkN9NOO09lSJGZ0bja0n0SuUe5VvGOyc10Rco8obkzKJYYXNVDpoqlGk O4Ch6pyzkG5WlbykGrOiqs+h6yoKRd8xcgHVCjYHU5yHcaySkOLPTYq/4 G/pwG4n7yNJel+i+PcKmUTsNL7u2sUXzmfdkhPhp2zYy2jqpVwoRc22KJ w==; X-CSE-ConnectionGUID: NiqRK0YqRwiGiIIDmq0cdg== X-CSE-MsgGUID: 0PVSBBH0QGOZnlMQaTD7ZQ== X-IronPort-AV: E=McAfee;i="6800,10657,11790"; a="102714772" X-IronPort-AV: E=Sophos;i="6.23,243,1770624000"; d="scan'208";a="102714772" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2026 22:59:01 -0700 X-CSE-ConnectionGUID: lEoS214yTfy54CUzJKMM5w== X-CSE-MsgGUID: PgRd1rawRLelrO4ZFc/vAw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,243,1770624000"; d="scan'208";a="277771199" Received: from fmsmsx903.amr.corp.intel.com ([10.18.126.92]) by orviesa001.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2026 22:59:00 -0700 Received: from FMSMSX903.amr.corp.intel.com (10.18.126.92) by fmsmsx903.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Mon, 18 May 2026 22:58:59 -0700 Received: from fmsedg901.ED.cps.intel.com (10.1.192.143) by FMSMSX903.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37 via Frontend Transport; Mon, 18 May 2026 22:58:59 -0700 Received: from CH1PR05CU001.outbound.protection.outlook.com (52.101.193.16) by edgegateway.intel.com (192.55.55.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Mon, 18 May 2026 22:58:58 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ikyvlI3zw/uuE/awwNb3VGL9sw6EGCQJQjVNZiBSdGm8PbgkSNmcYtDPM08tMPBrV4GH+S9zq5rKsyFhe5Yu4ZalE/rL+SppEprsQT3vmqoc3Yk51Ji+9OKv7Fam1+VaVBz7c6tWQc9byxfHnSj/C472CahakmAmwIhT5ccyKcafuOXteWhPFUjseXhivV59NRBR0EPS5AGgdYyP619CRL2i/ZKqfz2/947nsHJQdSRIsaIO7uBjVBtIPjXr2JyCEhbGNXPzlAIffLqO4OVM+/JM/ncP84XIkPbjao/RbsSAQS3jTqpcJR1nvAjw378bK4BfXU68z4V5iziIp5d0Cg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rDFr17ATTchvjWQvvGTzfwPOLljOLf85nEjJ2PjhWnA=; b=A7HNGszVqx2BdzqLgZb0vS21QAeMF/5Mfbbf3d1pgT0FX7mItDXhp2dEh28WCjwMZQfFz52H224l94FluZgltqz2ZzjucxPaHI35+/f5CJqkmoeKkIgxIdTc/ExWYyJnV3caWeMCc+JcZQjxe1j/CRA2Iqo+Yg5nTR7xO0PIAXcqk6F/KZasP4IdZkWsbK0xuN5OttlxUeGX4XZ/CPrn9zBQ5Cf/4DJzhCqOVl5CmEtGiec9aG6CYE0YJocl7/GFMbz127eqgHW0Axg9oTzJRlKOb72+SylHIw5Z2O9u7nG8gmDpgwUq2hWlbTS04DZFEThkEilEcaUD9057tMVwWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from IA1PR11MB7198.namprd11.prod.outlook.com (2603:10b6:208:419::15) by CO1PR11MB4996.namprd11.prod.outlook.com (2603:10b6:303:90::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.25.24; Tue, 19 May 2026 05:58:56 +0000 Received: from IA1PR11MB7198.namprd11.prod.outlook.com ([fe80::2c4e:e92a:4fa:a456]) by IA1PR11MB7198.namprd11.prod.outlook.com ([fe80::2c4e:e92a:4fa:a456%3]) with mapi id 15.20.9913.009; Tue, 19 May 2026 05:58:56 +0000 Message-ID: Date: Tue, 19 May 2026 08:58:52 +0300 User-Agent: Mozilla Thunderbird Subject: Re: perf AUX: race causes poll() hang To: Peter Zijlstra , =?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0JzQuNGF0LDQudC70L7Qsg==?= CC: Mark Rutland , References: <20260518094121.GT3102624@noisy.programming.kicks-ass.net> Content-Language: en-US From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo, Business Identity Code: 0357606 - 4, Domiciled in Helsinki In-Reply-To: <20260518094121.GT3102624@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DUZPR01CA0039.eurprd01.prod.exchangelabs.com (2603:10a6:10:468::17) To IA1PR11MB7198.namprd11.prod.outlook.com (2603:10b6:208:419::15) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA1PR11MB7198:EE_|CO1PR11MB4996:EE_ X-MS-Office365-Filtering-Correlation-Id: 5ee32534-84e9-44fb-bace-08deb56bb64f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|3023799003|4143699003|18002099003|22082099003|56012099003|11063799003; X-Microsoft-Antispam-Message-Info: 9ddZg1RK5vpVkQzIkqHwRkFdSGE/RRXuh2a4bVp0aXsTdAq/MRWrRME0bhb5niWaC7dqJi2vsmsmNgjce+3lah+QTv0MV6s9hPrCnxa2t4rsF2If+Bb26rEjHUZSbtMlelmYiEehz7xmqfPoo/La4jmJMucuPb9RaiGGDqQ4clCp9eNNAgMlT8OQQ3YU9ymfhY7ZOrKeyX+yDEMl/Q8AwumEF6M52lROH7YZHZSAxPPr+haeBO7O/acEJhetyFzhE9kgLGyD24qcNgcMp1cUEpmEgeBIX4K8gytKIqAFl8diEzApn4wIQ5N0yHgn0QVk6X0pNJ7tYN/6XO706Ke1UQLMEzv2R1bzyMqeJQkkJ97bp43W/IxvuOmznqNgw5BUxJuKXWyMCkAiDsV5jDXdwp9JgEYwI7hsfFgCeMPwZlU2/dqA38OM4jT6eiS3nUuYf8o647VMHQ4eOjiyy5RNNtK63D4ZAowyJRsPW+xsKzjiCVtvRaN4PmARNYRC1QklpzSlxwMi1oHK7h4GzCgf5Jebj0Zf/HdzgJilJ/A22zFnclgpt8ou1cTWGTGbKEWsisVGjCFmAQUm815xsGepKFzgzdtYvjQiZJZF6woQqnXk85xRPc/55vyVVfcQgqsJgnQ/eUwo/bjf3uYoL2BCFdNjh14iLW2jazm3kX/c2/QmEsvG/KfEkY2ft9WTYCVu X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR11MB7198.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(3023799003)(4143699003)(18002099003)(22082099003)(56012099003)(11063799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?amdSWXNaS2VlcGZXWG4xVTA3MGdFWGJWWVQ2czBLWHNmTGJibThpK0FLK00w?= =?utf-8?B?M0kvZWQyUmN5UWt2K3ZTTmNrNTJnajFITm9XOVVYQnZndEQ1R1NHQnhJWU1o?= =?utf-8?B?SzJhU2piKy93VStqdjhhYXpDQjRRMGpGU21DTlYvZmZQWWpkbTA2RW9XMmwx?= =?utf-8?B?U1hsWDg1TDR2T01TSUtXNC9yQlZSU01URlAweXgrQ1lDc3ZsUFBTVVUvSjNw?= =?utf-8?B?Z3NRS1VneUJTZHYzelV5UVhZNkI5K2RDU09TbkRQa1RhT3hpUVoyQmgvUnBh?= =?utf-8?B?YmJiTktDTDREcnZYYzV6K1FkTzJ1YXVVM2dqU081a25UZ3VoN1NuV0ZtdDhz?= =?utf-8?B?UEh3eVFBUmJURmFRb3NEeWpMMTM3djFVNGxpczV4cTNSNlkyQW9veVJsSS9o?= =?utf-8?B?REU5R3ZHRHhEQTlCV2pTckF5a2NMOEVld2YrOC83bUdoTDR6UEVTM2lRR2NU?= =?utf-8?B?RWhQNGswQkxJeWYvNEhmaGdPTS9IeE9xakFaUWxxTCtpYkp6Q2xNNDZ2ZzRw?= =?utf-8?B?S0l0dVk0VjRjNTNJeGJDU3h5R3laT1NGYlBxdW82UGVOZnhWMjVqLzc3Zk5E?= =?utf-8?B?enlkclNUcWFSL1VvbE85cnAwdlc3R3pJVHY5SnYvRHE3dUpZRGI0YzV4M2lK?= =?utf-8?B?R0h2VGNXRVV6NitkS0NSSE5EVmJOT21oeCtRS0hjNmI5NXJITjkydW1YUUt1?= =?utf-8?B?RUZIZ1EzWWNOSWIwTHU5bklTb3Q2ZmY2dFFHS1hNdmd1Y0o0WENPN0NHcGU2?= =?utf-8?B?dXZ2SitOSDRRSU9jRmx6eC9ONFZSb056Vkt0TFZLcE5GM2lzS09saExtamJi?= =?utf-8?B?RGJ4QVRpWlZKQUlBaTFLUjFDMWVGN2hrelQwM1ZOU2srRitZWnh5KzlUQ2lE?= =?utf-8?B?YUE1U1BxZXl4VjdUZEtTdy9FY3NkNUpVS3d0VGhwL052QlIxMkVIYjYvNXNQ?= =?utf-8?B?d21uRUU0K3hDK1VTYmp2ZFBqaEJBQTNVTGhTOG9MT3RFelJ4bFBmMnl2dzNq?= =?utf-8?B?V2hMV2NkT1ZKY3UzcXNpSlpFZEVFZDRYT3BoS09kTjJaaHQ1dFdJU1R4YlhW?= =?utf-8?B?VkNEMUc3amdrZWF4enFJS25NZUFOWkxKVHkzd3RWbFpoNlhZVWdjZ1VpU3dT?= =?utf-8?B?TXpYdmpXbWpRZzJ6SHpZc3ZhbXVLTWI2dVZXOUxKMFVHTm1sdDd6bHJxeFFv?= =?utf-8?B?a0s3YU9rQzJzQlg1alVvVXNrVHgwR2J6aG96Nzh2bjd3QTcxV0dIM1I2bjFF?= =?utf-8?B?U0owTERLK1cwd1l2ZVZaTzhDU3ZLT01YR09KamkzdCtmcjRoS1kvSzZ0K1RR?= =?utf-8?B?OXY5VllKN3Urd3VPRVdUT2tyYVFkYVIrVzN6eEgxWGlvZ0YyVi84WDdabkhQ?= =?utf-8?B?L3ZUeHIwZ0tEclBwWXdvSTg1SzVsNkNkQTNQalhENFZrRVEya3duajcyNWR0?= =?utf-8?B?L3RDYzBvMnRwdEJreW5ocHlkSzh4c2EzNHhONWdtekxuTXY5aVB2Vy94ZzM2?= =?utf-8?B?TEVpUW9rRVNRK2NoODJ6dnZHdUcvem5VUXQyTUNydGl5VERLTHpIdEpUZE0z?= =?utf-8?B?U2ZzN1liY1FCb2VObWp4bGRybzRyT2VCODd2ZzBqb1dodjY3aUdTYmZpMWJv?= =?utf-8?B?RnhGMzdZRjFCVm5OYlFiZlNsalBnb3RXR2UzaGcyYzl4R0dXdFBETTZqZW9a?= =?utf-8?B?eFZVZWJucjdnQVZIVURwYWovOHlrdTh4SFlrdHYyQnIvZmw4TUJWSURKQzZP?= =?utf-8?B?NlJadVpjdUtvY1lmVk4xL05Ea3daazlRa3BKK3N3MTVLWjJQdWhlWDlvVzBW?= =?utf-8?B?Ym5tQlhESGYrVG5TYjdWc29pSXZvajBCbTlVNm1KWVpySk5lUS9LOU5GQ1Bs?= =?utf-8?B?dnphNlVBUFZvSXdaWUx1aXI3NDBqNnk0bWRHQVBhUk5Yc3lhbXdmS0w2Q3Fa?= =?utf-8?B?M0FuRjNsVVovQ3RpVjRRMVFrT0diNThHdUpSYUJjUFhwelhTK1phdUR5Uk0y?= =?utf-8?B?eEh0aDFJUTBjSUlLOC9EczBsQVRQd1ZBcXppMFAyeTVqSGgyamt5dXZ4c1NI?= =?utf-8?B?YVlrWnQxcVFhV2JSNTZlcUIrcWdKMG9HVmEycmZUSFkvT2hZN2YxUmYwQVcy?= =?utf-8?B?b28rUnBycVJ6c2RpeEIwRDhHSWM3RWI5eUhRTE5GTmRlYW9XaTJHamxRaUU2?= =?utf-8?B?Q2hnVHVUS2E5cmthZ0YzcDR0MUdRNEJJVVZWcUpka3VyaW05TzV2WVJuRFE0?= =?utf-8?B?ZjBrUnM3b1E2ak8vSTRVM3VUaExvMkRxVEV3M0kxanJZbHV5UVZySEtHRlBv?= =?utf-8?B?MzRHRWxRQlJYeERZSWloSWMyNktZZjNac1JlWGY3N2RLSHprRFl2T3c2S0dU?= =?utf-8?Q?NxkvoS/08uosixBk=3D?= X-Exchange-RoutingPolicyChecked: Djw0wsi1IXj3ICgEY9S8Q9+p6p9FwP4mXjSOCK7AW5ujAnswnS80hEDXjyINOmJRXc4Y5VZhI3ILdezlLtgJ9nYkRv7fBSlPWp+oVpY+7GQ2IUvlhLzhkE+6d3U6A8sDL9hJa49AL5zZQbag1Q4LXV35I/7LPjZYu2kVyY5KoSDOIbIeWDs+XnkXgWjgGMtXCciiuE1B+EUHdeDW6zyvXccYsQeV2QQd8bZiE8fWIWW6tCiCMEhBZCDqtXi7mIYeGo2uj9dDopNuX6NczJAWoXiEM/9sB2zufc0BA6YPL+RZ2RG+BJssgChlGC2Za+RGGbG8zMMzJMUnHmx1AsfHQw== X-MS-Exchange-CrossTenant-Network-Message-Id: 5ee32534-84e9-44fb-bace-08deb56bb64f X-MS-Exchange-CrossTenant-AuthSource: IA1PR11MB7198.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 May 2026 05:58:56.0193 (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: LcO4yLv/3wiUEA6aiTDFHBCw0Gu+0P8y1GamfmatYq7B2LXZKFhNGJz/rGl9+XNw5G9gMHtWg79U/2Si83urQw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4996 X-OriginatorOrg: intel.com On 18/05/2026 12:41, Peter Zijlstra wrote: > On Fri, May 15, 2026 at 01:35:48AM +0300, Константин Михайлов wrote: >> Hello Peter and Adrian, >> >> I'd like to report a potential race condition in perf AUX buffer handling. >> >> AUX tracing is designed to allow the tracee continue running when the AUX >> buffer fills. The PMU driver must disable tracing when AUX buffer is full. >> Typically, it schedules IRQ work to disable the event later. Meanwhile, a >> typical tracer's workflow looks like: poll() on perf FDs, consume the data, >> re-enable the event via PERF_EVENT_IOC_ENABLE ioctl(), then poll() again. >> >> Given this, the following race is possible: >> ------------------- >> | CPU #0 | CPU #1 | >> | tracee | tracer | >> ------------------- >> | ** | | tracee fills the AUX buffer completely with some data >> ------------------- >> | ** | | PMU driver updates aux_head accordingly and schedules IRQ works >> | ** | | to disable the event and wake up the tracer (setting rb->poll in >> | ** | | perf_output_wakeup() along the way) >> ------------------- >> | | ** | tracer consumes all the data from AUX buffer, >> | | ** | thus clears rb->poll in perf_poll() >> ------------------- >> | | ** | tracer re-enables the tracing (the event is still active, >> | | ** | so ioctl(...) returns immediately) >> ------------------- >> | | ** | tracer starts poll()'ing the AUX buffer again >> ------------------- >> | ** | | IRQ work handler finally disables the event and >> | ** | | wakes up tracer >> ------------------- >> | | ** | tracer obtains zero rb->poll and continues polling >> ------------------- >> As a result, tracee runs without PMU tracing, and tracer's poll() will >> never be woken up unless it has some timeout. >> >> I reproduced this on an x86 machine with intel_pt and kernel v6.17. >> Reproducing this race on the vanilla kernel is timing-sensitive, so I added >> 30 ms delay in the error path in intel_pt_interrupt() when >> pt_buffer_reset_markers() returns an error - this delay widens the window >> between aux_head update and actual event disable in IRQ work handler. I'm >> not sure that pt_buffer_reset_markers()'s error means that buffer >> overflowed, but this error branch is taken sometimes and all needed IRQ >> works are scheduled during a call to perf_aux_output_end(). I also added 3 >> ms delay in perf in __auxtrace_mmap__read() before itr->read_finish(), >> ensuring the ioctl() falls into that window. With these changes, some perf >> runs collected smaller traces than usual. I added traceprints to intel_pt >> driver and enabled tracing for sys_poll and sys_ioctl, which confirmed the >> exact sequence described above. The problem was sometimes mitigated by >> tracee migration to another cpu (as perf creates an event for every cpu, >> the event is re-enabled by kernel when it is set on a new cpu). Otherwise, >> tracee stayed on the same cpu and tracer hung on poll() until tracee exited. >> >> Could you please confirm if this analysis is correct? Should we move >> setting of rb->poll *after* the event is disabled in IRQ work handler? > > I *think* (its been a minute since I looked at this code), that you're > right. > > Does something like the below cure things? > > --- > kernel/events/core.c | 54 +++++++++++++++++++++++++++++----------------------- > 1 file changed, 30 insertions(+), 24 deletions(-) > > diff --git a/kernel/events/core.c b/kernel/events/core.c > index 7935d5663944..490407618f36 100644 > --- a/kernel/events/core.c > +++ b/kernel/events/core.c > @@ -2677,6 +2677,9 @@ static void __perf_event_disable(struct perf_event *event, > struct perf_event_context *ctx, > void *info) > { > + if (event->pending_disable) > + event->pending_disable = 0; > + > if (event->state < PERF_EVENT_STATE_INACTIVE) > return; > > @@ -3278,32 +3281,37 @@ static void _perf_event_enable(struct perf_event *event) > { > struct perf_event_context *ctx = event->ctx; > > - raw_spin_lock_irq(&ctx->lock); > - if (event->state >= PERF_EVENT_STATE_INACTIVE || > - event->state < PERF_EVENT_STATE_ERROR) { > -out: > - raw_spin_unlock_irq(&ctx->lock); > - return; > - } > + scoped_guard (raw_spinlock_irq, &ctx->lock) { > + if (event->state < PERF_EVENT_STATE_ERROR) > + return; > > - /* > - * If the event is in error state, clear that first. > - * > - * That way, if we see the event in error state below, we know that it > - * has gone back into error state, as distinct from the task having > - * been scheduled away before the cross-call arrived. > - */ > - if (event->state == PERF_EVENT_STATE_ERROR) { > /* > - * Detached SIBLING events cannot leave ERROR state. > + * If the event is in error state, clear that first. > + * > + * That way, if we see the event in error state below, we know that it > + * has gone back into error state, as distinct from the task having > + * been scheduled away before the cross-call arrived. > */ > - if (event->event_caps & PERF_EV_CAP_SIBLING && > - event->group_leader == event) > - goto out; > + if (event->state == PERF_EVENT_STATE_ERROR) { > + /* > + * Detached SIBLING events cannot leave ERROR state. > + */ > + if (event->event_caps & PERF_EV_CAP_SIBLING && > + event->group_leader == event) > + return; > > - event->state = PERF_EVENT_STATE_OFF; > + event->state = PERF_EVENT_STATE_OFF; > + } > + > + if (event->pending_disable) > + event->pending_disable = 0; > + > + /* > + * Already running, nothing to do. > + */ > + if (event->state >= PERF_EVENT_STATE_INACTIVE) > + return; > } > - raw_spin_unlock_irq(&ctx->lock); > > event_function_call(event, __perf_event_enable, NULL); > } > @@ -7612,10 +7620,8 @@ static void __perf_pending_disable(struct perf_event *event) > * Yay, we hit home and are in the context of the event. > */ > if (cpu == smp_processor_id()) { > - if (event->pending_disable) { > - event->pending_disable = 0; > + if (event->pending_disable) At this point, can _perf_event_enable() on another CPU decide to do nothing ("Already running, nothing to do"), but then the disable below contradicts that? > perf_event_disable_local(event); > - } > return; > } >