From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2055.outbound.protection.outlook.com [40.107.237.55]) (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 39E332F22 for ; Fri, 3 Jan 2025 04:24:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.237.55 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735878268; cv=fail; b=hUN3xkh+E7T9fRzO4/vB//OliUJubgCd/es61U8jz39OQKqHS1NlpJjf9X0BPAC6xDwvE3NX29L2oe+1+JimE9OUXS60qKpyJ9avz19vqrtT5dg7ykBQdfFjJsZYiy9lLpc2542V8XOawhCuFKnmxuHoBLW+AEiJ2NEYfagCD+U= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735878268; c=relaxed/simple; bh=BQz6nwf6uUy5u0F9JaqqXcjjBuwVLXfBf0ze1Svh0NU=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=Oj1U96eeuzCRIFLVDb59YjNAK/xWyZ2o7AAfz5dGqQ5BOrccqhbDpLH7CV+/kYnJW3VD73RxVs10eFALY1dEIaP3mNV5Rl6r01qqEgvS1db5Nnu2IASpwv9Dm5PAON312FOoAk9Y9JhPbVIfRyDLfmftL1IWyIw1S62QO3lLUC0= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=DhAqbGfb; arc=fail smtp.client-ip=40.107.237.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="DhAqbGfb" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qs6HnbTiD7mUTr29kUGbUBVC14aCfYUUCAJcvg+CMmz8spalOyc1lnKKmypjtxYpJK+m2XXKzQc2b7TBp006+ua3Hpzmll84CzaRwuNg3CTOBl1Gjw+sAxxOBH05DYqBy9jwD4nN+9Qpw4GLJWm/VVFBzSskvbJsWaqMmePKwcjFUTU9C9GSSmmYaHTo1XwM7BLKxx12LHYatpRaPpyrJMsJJDhIomAe67sE4UFCEq91G0QfVwHOQxYbssMQI21+p25AxbBvBdD4LOZtrjQyx1sI91Tggf29oX9GmFVhhJfLaip090ceK8BQa5W1IwROFthbWnOvOBsEaYl8YV+AJA== 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=37G9K2+F/01zIM1LAX9iwmBw3LKLqfHt0XWdPdhtlTI=; b=tYzHxwEbuomphA7qWYV0c8MvMUuEYWopOo37rWg5SqFAdbqslsR9wVAbcNs8bwLNUTzSk2GLov5Id0gHscHgecj9ppjQsG7yEpqT4vRLnzwwhSrE9BYkB9XJ0GMqm00V4A35IvI40I0b4w6m+s5TCgy/sofg6a8b/UISSzCTXSzdP9pXwCqlozOBZas0+jV8678lct8UTdxaiMh71jrRLOtH+Lp+idqAesk7MHP5EKnMmuP1AJk4ZnnU8nDYXUVNs3INP0q7uXQeYbbtIOFsatWTxI5rj0iCCHkxpcizv78RvLuZS/BzG7nbc3NOCQa84TmJXwnxED80uBpFT+lHPA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=37G9K2+F/01zIM1LAX9iwmBw3LKLqfHt0XWdPdhtlTI=; b=DhAqbGfb4Ru1Z7XW563gLV8tJ5cP/HyPSvgM+yNUx5Nzw/yeW4VcP62W89FRLZECwG3N57wlMmVCkICz0lLhoyGmrsnXTWuhVOfLSq+civgFgs6AcDibolqdl5SsFfOeMn6zdIhwZxEqKZG6U5R+34dqn7vSTDrfifQecyenXWs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from PH7PR12MB6588.namprd12.prod.outlook.com (2603:10b6:510:210::10) by DS0PR12MB9276.namprd12.prod.outlook.com (2603:10b6:8:1a0::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8293.20; Fri, 3 Jan 2025 04:24:19 +0000 Received: from PH7PR12MB6588.namprd12.prod.outlook.com ([fe80::5e9c:4117:b5e0:cf39]) by PH7PR12MB6588.namprd12.prod.outlook.com ([fe80::5e9c:4117:b5e0:cf39%5]) with mapi id 15.20.8314.012; Fri, 3 Jan 2025 04:24:19 +0000 Message-ID: Date: Fri, 3 Jan 2025 09:54:09 +0530 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 19/19] perf: Make perf_pmu_unregister() useable To: Peter Zijlstra Cc: "mingo@kernel.org" , "lucas.demarchi@intel.com" , "linux-kernel@vger.kernel.org" , "willy@infradead.org" , "acme@kernel.org" , "namhyung@kernel.org" , "mark.rutland@arm.com" , "alexander.shishkin@linux.intel.com" , "jolsa@kernel.org" , "irogers@google.com" , "adrian.hunter@intel.com" , "kan.liang@linux.intel.com" , Ravi Bangoria References: <20241104133909.669111662@infradead.org> <20241104135519.715883982@infradead.org> <20241217091216.GK35539@noisy.programming.kicks-ass.net> <20241217115219.GH12500@noisy.programming.kicks-ass.net> <8c31f7bd-871d-4a38-ad15-a16a116e1f39@amd.com> Content-Language: en-US From: Ravi Bangoria In-Reply-To: <8c31f7bd-871d-4a38-ad15-a16a116e1f39@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PN2P287CA0004.INDP287.PROD.OUTLOOK.COM (2603:1096:c01:21b::6) To PH7PR12MB6588.namprd12.prod.outlook.com (2603:10b6:510:210::10) 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: PH7PR12MB6588:EE_|DS0PR12MB9276:EE_ X-MS-Office365-Filtering-Correlation-Id: 09581b06-b58a-48cc-027f-08dd2bae7d8a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?WmVDR0VDV3krR0lpaS9CWGxLUys5dzBxUDcwTzdDbytlMHBQbDVpL21PSHdC?= =?utf-8?B?V3JPaG5meEE1VkZkeWI4SGt5dmRyV1huZU1SdFdGbnJlOTgrdGpkVHk1MVpX?= =?utf-8?B?Mzl4b1Boa1JwTnFDSTFYOWhBY2pSa1FabXJVU1l5NHVXVG9PY3IrNE5YMWVt?= =?utf-8?B?Q1BCM1h6Q3B2OHgrN2E2c0NPUW9iM2FkZTV5dXp5eWl2YVVDWlZCdVcwNWov?= =?utf-8?B?SnYxVnJGWDN4UTRCQVV3bS9ZQkNPWmlsU0Q1eXBPTFJrSCtOcnBnM0lwOG5n?= =?utf-8?B?dG5TVVdSSS9BUmhyVVV3ai9wWGlseFVEZHpwWkhlc2dvczJVU1NHd2dLdlUy?= =?utf-8?B?cWo5THEvVHhhS3pQNHlTd01XS053Yms2c1grcmRMQVlUVVBsZ0tlclhGZTJ5?= =?utf-8?B?WHNiTjdKbGRLL3ZYQk50cUErQ3RZY0lrVG5zNklwdXRSL0kwZWxHN3Y4K2ZG?= =?utf-8?B?RDI4YWpGb1ZBNXBUUklkajRrUWpONlk1VHR5a1VZOFErODc3RWZvZjgwRXlX?= =?utf-8?B?Q3Qydm84QndTUkQ3YmVrcXQ4MS9vZ0NINHFNbFFDMVYwU1ZRR1B4OVlIbFFy?= =?utf-8?B?SkNkUnJHM3F4UTlEYU9aWWdmakREc0x2ZGNYeXI2OXdqbTB1dENLVXh5Q1c2?= =?utf-8?B?dTg3UVd2ejQ5WjQzcWMwOE9LQlk1L1lIVy9BMUdEYm1GK2ZEUFR3YzNlY0F5?= =?utf-8?B?cVIxZ1hKY1pKOTFOTWZzVVNiL2QyZ0lOQmh5cm1lbmlabjFIQzN5VlB5aGlX?= =?utf-8?B?emlhTEhydkhXc05pckhFVGxLV0NSbmNJdXNxVnZIUGZKMkkycC9id3QrVTFm?= =?utf-8?B?MEpnTEhuQlJLL09iTEYyb2Q2Zlp6Wng0ZXIwWEc4a2NwUVlnbGN2V1RHdFhK?= =?utf-8?B?U1NaSnRDVUhMd0tTcERkaXUxemRpZy8vcC91N2JWUHRxRzl5OGpSS1pZdzJp?= =?utf-8?B?cWhONnpoUzBwNUEyTldRdXIyelBTcW5KL0YzVEF5b0hzVlllMUYzd1RmMStj?= =?utf-8?B?SmVOZmFRcTZ5WE5nRVEreVVyZFE3cEdKREw3WS9UOFpaVWxLR2VIL3lETitY?= =?utf-8?B?M2ZQa3UySjlvVzZOM1ZYVjQvWExncnhnSUMxYWJDcDlzazQ3cHJzMmp3L2ky?= =?utf-8?B?WHFSVnkrRFVFalFTQWJIN05FazlVT2F4UDkvSXZvTHNCZDdqSDdRMWl4ZFlG?= =?utf-8?B?N3FZNGR1UXY1NzllLy9tTVRmOEdVYndQRXFhQ1ZZSVE2UWo5M3FodEVzbkdB?= =?utf-8?B?UUtyUWN2Y3pNWlBFbXhxSmV5d3FtNmcvM0FweWhjQ24xWHc5OUFtZ0lNSTJ3?= =?utf-8?B?akdZSXJJdlBNZVFHd09ocThSQ05JNkhRd1YxVHYvZWtvR0Z6KzNETzdIS1F6?= =?utf-8?B?RlJSVzRIMmU3OUZEbXVsV0VEZndaTWFBWldmVDZxVnJwUlpORU9QaUVxY0lS?= =?utf-8?B?RU1HcnhTdWdta2tMTFovRXA4aExsakR5aTFGQmc3THN4RnZsN3VkbzV2Wjh2?= =?utf-8?B?UEs1eUhndnhCalYyZWhrSUVQLy9FaEdwaXIzeFZsMzdrSDVhVlVaSmU4elZ6?= =?utf-8?B?VW1GbWpBNWlabnlKL25Sb213Z1c1Uk9SSDM5cm95MG92UExkRENoSnAyRHdl?= =?utf-8?B?VjdXbUkwMElNbHk1T2d1cHN1d0hnTU15VFZQbFNjdWFsN045TnFRd1ZPa1J0?= =?utf-8?B?ZllHbDYwN0hRRGdUS2dHeFNZeG45UTVsUjQ3TTBQWlZRUThZdEtycXpiWVBW?= =?utf-8?B?U0ZVb3Z0RVkvRlRDVXdYZ1VWclRqdVB5ZzkyOUtVSWJOYmJEcnFXQVIvVUFn?= =?utf-8?B?WFF5L1lWUndvZUZqRXlCM3RsWFNGM0RqL3lodTBJQjJwQ1VRYVR0RVJFV3BR?= =?utf-8?Q?+PCzQ25/QH12A?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB6588.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SituVjFaU0RUK2RFTlR0bjY5TmVsQ0JESHdRMXJIcElKT3dlTE10UUU5UkND?= =?utf-8?B?RUVJbXh6UWQyUU9ydTl1WjRQaHE0WFZKWnFRR2xLNlk2ZE9FRHg3UTZsaHVn?= =?utf-8?B?SXg2VW1oSmk2M2Fkd3RUNXlkQkk3RWY3VHkzUHI1azNWT1A4VSszMHJDQm9V?= =?utf-8?B?YzA1aVBaNGd6dGdHZlVqVjEvYURCYW5GMnhXYWtmZnErbzVoRmx1cXR1aGxG?= =?utf-8?B?V1FGRUpHLzcxN1pLVVFCcVVMYW01dDI4YUZ0VzlqZTVzZndkc3RQZlpvQ3dj?= =?utf-8?B?dnU1WWVNd1VyQVlDeUdqc3ZlSWdEUksxaURZZmNHZGN2eUJ0cGFFM2hjOGk4?= =?utf-8?B?QW9DaFVQUE1WdUcveDdYNGExNElwS2gyeFU5bVRXNVZlNVBxbEcxdXlyTU9q?= =?utf-8?B?RkhPQXE2aVU3RzNsSTZXdzdtR3ZXbDFiQnJZVFlCNkVmRURkb2g3aWF2K2h5?= =?utf-8?B?UEJDTUNDVHZnTi9iMm5KR0I1bWlRN2Z4T0swcEFCbCtMTER2WHpxY0orSjlD?= =?utf-8?B?RUN3aVJmc1huaVhkckMzelh5dTJ6Vmw4anZLTXZyZkUrWFU0MHZmMUhaWCtN?= =?utf-8?B?MmlKMy9BMlk4K2w4dHMwVE54YVRmcVgvZUNnTEs5YWFmUktrK3IwSXhGZUky?= =?utf-8?B?WG1vbzlOeFZHc3BzZCtNVWJIVXlkU1BaNWF1SHdRNXNiSWNWSFdFRUpJTkt3?= =?utf-8?B?eDJZb1BiS0dST200ZFNVVjF4ZUNRMk84Z2U4YURvclBrWjZPTmtvRlp3U2RZ?= =?utf-8?B?ZC9vM1I5UzNLeUhUUUFEbitjY2F6ZHBqYUZQSW1LeUFkdkR1UjJIckpDdU05?= =?utf-8?B?eldQYVB5bkhYOThnMnNzRTZpcDBCekVyRUhjNWd5UHcyeW9lS01rSkdxdDQ5?= =?utf-8?B?bWNkaldZeUEyckFVdFoxZEhvaXVxNEg3b3JNQ2tpZzZxejJZVFlrMDFVOFdv?= =?utf-8?B?UC9rQUpzdUMxUWZWZ1pXMzNGa0Z5dStnZ2pyNXlNNWU2WWdUa3UrTHZOenRE?= =?utf-8?B?YzZ6N3ZuMGxsbi9iWE5YNCtXOHRuVlVJSE9Ybk9xakZZWlFiZE5OZWFrMDZ5?= =?utf-8?B?dGl4VVEweWRTTy85Nm1JM21vcHpGVzF4a1hzcG9EeXJ6V3V5bnJCU3Q0QWNM?= =?utf-8?B?bnhHVG4zb05qWXpiV3NQZHdSWmJHaTF0QnB2M3ZhR2YxS2MzQTBUWWFRYWlp?= =?utf-8?B?RnptNFB6aC9kdkk0VUxMdkUxdHFGZFNQWk5mQUFMc2RiSC9uS0Zzcyt3NXJw?= =?utf-8?B?bDNYSEJGMDZLckR4V2U5THUwSUJEUHJzRkdMaW91bitqSi9lek5WU2JIMlZi?= =?utf-8?B?ME5qT2E4N0NZVVhHdDQvMjRubkJqSU1HQWl5SkpwbmtKeFJBWmNMVFhGTXFp?= =?utf-8?B?VlpUbWRCdEoxQ1Z6UEM3MjBlbHR6RnhRWmNESENiRks4VG9zQTljMEU5bjN0?= =?utf-8?B?clRYUUZMbTdUOUZ2UGFmdXIrbHQ1UXhPQnpubzlING9qL0hqZ3ZEeUVlUWdv?= =?utf-8?B?bk5JcEV0Q1ViWmRvYk5KMUxxSC9VSHB5blEvbk1LVDNlNnJKdTZZV3QxWEd4?= =?utf-8?B?UlA3L09qNjlBL0JZSmwyZ3I0NFZ0VnQ4TndkVTZMb3llcW9vSkVaZkhKb1cw?= =?utf-8?B?QUFhemlmMThoTkZkZ0pDQVZZZUx1K0tzbldpZ2tycFVQdzJOSzQrYXBBdWhO?= =?utf-8?B?TThsYkh1NWlhRVhKNXdGenV2R0UxNkNFbXpBSzJPaHJ2SmNrTTlrL3YybHh4?= =?utf-8?B?ckVoNmhmb2NwbDQxamJXVlptRW9ucSttTHFXOG8zc1hvNXhWTklsd2dwSWx3?= =?utf-8?B?OWRjSGRUTVhSRHRpM1drSHo4M2hUQTJEYXovaUd6R3gvVS9ieUFyVmxEMzIz?= =?utf-8?B?blZGYTFURGl5QzFqWEhKSCtLZEs4L3FPR3QreGpXbTN6UVA1RkFGdFdoWXFH?= =?utf-8?B?VFVTQ3o5NFNQbmNtZTVad0dlL2o1UWVhTjJ3Tm95Z0JTeERoRDlPcFYwYS80?= =?utf-8?B?aXJNREZ0MVRHU0w1NThtKy9PRGpVeVd5Ri9DL1lXTUFOcXlCWXFKTXVtZFdy?= =?utf-8?B?Z1JtaSt4NUtQZVBBNUx1V2N2eUlCVW1kc2x5UVJKVUhka3dqS0p5MTIyQUZC?= =?utf-8?Q?I8XNU2HBroW0B2SG5zoUfitkq?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 09581b06-b58a-48cc-027f-08dd2bae7d8a X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB6588.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jan 2025 04:24:19.0555 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: /o8mJPmDEbv2uOK2w1GlHScy4R+LRVyHQenfbLqJqpNPNsoGn41cVH7jcMpMU2eNEgKApMkIEWp3GicOfAMccw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9276 Hi Peter, Sorry for the delay. Was on vacation. >>>> In any case, below sequence of operations triggers a splat when >>>> perf_mmap_close() tries to access event->rb, event->pmu etc. which >>>> were already freed by __pmu_detach_event(). >>>> >>>> Sequence: >>>> >>>> Kernel Userspace >>>> ------ --------- >>>> perf_pmu_register() >>>> fd = perf_event_open() >>>> p = mmap(fd) >>>> perf_pmu_unregister() >>>> munmap(p) >>>> close(fd) >>> >>> Right, let me go have a look. Thanks! >> >> Bah, that's a right mess indeed, however did I miss all that. >> >> The easiest solution is probably to leave the RB around on detach, but >> now I need to remember why I did that in the first place :/ >> >> Oh.. I think I mostly that to serialize against perf_mmap(), which >> should reject creating further maps. But we can do that without actually >> detaching the RB -- we only need to acquire and release mmap_mutex. >> >> Ah, there's that perf_event_stop() inside of ring_buffer_attach(), that >> must not happen after detach, obviously. So that must be dealt with. >> >> Hmm, also if we leave ->rb around, then we need to deal with >> perf_event_set_output(), someone could try and redirect their things >> into our buffer -- which isn't technically broken, but still weird. >> >> Something like the below. >> >> How did you test; perf-fuzzer or something? > > Prepared a simple test that does pmu register(), unregister() and > "perf record" in parallel. It's quite dirty, I'll clean it up and > share it here. > >> --- a/include/linux/perf_event.h >> +++ b/include/linux/perf_event.h >> @@ -1742,7 +1742,7 @@ static inline bool needs_branch_stack(st >> >> static inline bool has_aux(struct perf_event *event) >> { >> - return event->pmu->setup_aux; >> + return event->pmu && event->pmu->setup_aux; >> } >> >> static inline bool has_aux_action(struct perf_event *event) >> --- a/kernel/events/core.c >> +++ b/kernel/events/core.c >> @@ -5409,7 +5409,6 @@ static void _free_event(struct perf_even >> security_perf_event_free(event); >> >> if (event->rb) { >> - WARN_ON_ONCE(!event->pmu); >> /* >> * Can happen when we close an event with re-directed output. >> * >> @@ -12023,7 +12022,10 @@ static void __pmu_detach_event(struct pm >> */ >> scoped_guard (mutex, &event->mmap_mutex) { >> WARN_ON_ONCE(pmu->event_unmapped); >> - ring_buffer_attach(event, NULL); >> + /* >> + * Mostly an empy lock sequence, such that perf_mmap(), which >> + * relies on mmap_mutex, is sure to observe the state change. >> + */ >> } >> >> perf_event_free_bpf_prog(event); >> @@ -12823,6 +12825,9 @@ perf_event_set_output(struct perf_event >> goto unlock; >> >> if (output_event) { >> + if (output_event->state <= PERF_EVENT_STATE_REVOKED) >> + goto unlock; >> + >> /* get the rb we want to redirect to */ >> rb = ring_buffer_get(output_event); >> if (!rb) > > I needed this additional diff on top of your change. With this, it survives > my test. perf_mmap_close() change seems correct. Not sure about perf_mmap(). > I'll inspect the code further. > > --- a/kernel/events/core.c > +++ b/kernel/events/core.c > @@ -6540,7 +6540,7 @@ static void perf_mmap_close(struct vm_area_struct *vma) > bool detach_rest = false; > > /* FIXIES vs perf_pmu_unregister() */ > - if (event->pmu->event_unmapped) > + if (event->pmu && event->pmu->event_unmapped) > event->pmu->event_unmapped(event, vma->vm_mm); > > /* > @@ -6873,7 +6873,7 @@ static int perf_mmap(struct file *file, struct vm_area_struct *vma) > vm_flags_set(vma, VM_DONTCOPY | VM_DONTEXPAND | VM_DONTDUMP); > vma->vm_ops = &perf_mmap_vmops; > > - if (!ret && event->pmu->event_mapped) > + if (!ret && event->pmu && event->pmu->event_mapped) > event->pmu->event_mapped(event, vma->vm_mm); > > return ret; Both of these are incorrect. They just reduce the race window, doesn't actually solve the race. Anyway, I could spot few other races: 1) A race between event creation and perf_pmu_unregister(). Any event create code path (perf_event_open(), perf_event_create_kernel_counter() and inherit_event()) allocates event with perf_event_alloc() which adds an event to the pmu->events list. However, the event is still immature, for ex, event->ctx is still NULL. In the mean time, perf_pmu_unregister() finds this event and tries to detach it. perf_event_open() perf_pmu_unregister() event = perf_event_alloc() pmu_detach_event(event) list_add(&event->pmu_list, &pmu->events); perf_event_ctx_lock(event) /* perf_event_ctx_lock_nested(ctx) * event->ctx is NULL. ctx = READ_ONCE(event->ctx); /* event->ctx is NULL */ */ if (!refcount_inc_not_zero(&ctx->refcount)) { /* Crash */ perf_install_in_context(ctx, event); 2) A race with perf_event_release_kernel(). perf_event_release_kernel() prepares a separate "free_list" of all children events under ctx->mutex and event->child_mutex. However, the "free_list" uses the same "event->child_list" for entries. OTOH, perf_pmu_unregister() ultimately calls __perf_remove_from_context() with DETACH_CHILD, which checks if the event being removed is a child event, and if so, it will try to detach the child from parent using list_del_init(&event->child_list); i.e. two code path doing list_del on the same list entry. perf_event_release_kernel() perf_pmu_unregister() /* Move children events to free_list */ ... list_for_each_entry_safe(child, tmp, &free_list, child_list) { perf_remove_from_context() /* with DETACH_CHILD */ ... __perf_remove_from_context() list_del(&child->child_list); perf_child_detach() list_del_init(&event->child_list); 3) A WARN(), not a race. perf_pmu_unregister() increments event->refcount before detaching the event. If perf_pmu_unregister() picks up a child event, perf_event_exit_event() called through perf_pmu_unregister() will try to free it. Since event->refcount would be 2, free_event() will trigger a WARN(). perf_pmu_unregister() event = pmu_get_event() /* event->refcount => 2 */ ... perf_event_exit_event() if (parent_event) { /* true, because `event` is a child */ free_event(event); if (WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1, "unexpected event refcount: %ld; ptr=%p\n", atomic_long_read(&event->refcount), event)) 4) A race with perf_event_set_bpf_prog(). perf_event_set_bpf_prog() might be in process of setting event->prog, where as perf_pmu_unregister(), which internally calls perf_event_free_bpf_prog(), will clear the event->prog pointer. perf_pmu_unregister() perf_event_set_bpf_prog() ... perf_event_set_bpf_handler() perf_event_free_bpf_prog() event->prog = prog; event->prog = NULL; I've yet to inspect other code paths, so there might be more races. Thinking loud, a plausible brute force solution is to introduce "event specific lock" and acquire it right at the beginning of all code paths and release it at the end. event->lock shouldn't create any contention, since event would mostly be going through only one code path at any point in time. Thanks, Ravi