From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from YQZPR01CU011.outbound.protection.outlook.com (mail-canadaeastazon11020129.outbound.protection.outlook.com [52.101.191.129]) (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 D39E213AF2 for ; Fri, 10 Jul 2026 00:03:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.191.129 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783641832; cv=fail; b=eJx2ax1KCtknmGNgT3JPGdIIA7nsC4VyMIE6VrntGS6iAcaS7OGT7kyYEnb39uPs7gCg2j9J7Vb2ag4rGYSTeqKDltESPj4eSsbcWM5JYDw2Qf8gJNcjGKU9mQb1RRNedB5UXCJ8dUfJ2/iaWPESOiBtaEsDZ8hXL/jz4mPcA4Y= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783641832; c=relaxed/simple; bh=5kPDkaFW3MbJviPBiBHX8FLrBO75YhQrOGHLfz+hnVg=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=qIU7cmNSRBSH0BTSj+t+C3ShMsjDU6ihTke6L+6Of8cUwpi8lENhsvxeSLBR/AE5Ginq0hwoJnlQPx1sYo+h5Itbd3ySMePAEy9eiG8ueuPZmLXIDOmzvUp130snavTY++HlQrHSPnkxEHoj78W6qnLvC+zHo2nKZaIAilZOb88= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com; spf=pass smtp.mailfrom=efficios.com; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b=Bi/3SNfH; arc=fail smtp.client-ip=52.101.191.129 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=efficios.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="Bi/3SNfH" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dnT//p7Mn+ZMN1d8Yw0kXi82vVwDs4VYOX/m3BfL4oZDuolsfw13yjUx+aonz2/+c+GB3bFgnw1jRTwb0X3nnX7TqJNy0MLPyfdfAEcI8N88aZlyM7A5ttVA3jwyN5Mlc8W7Fy+1cuwnVe1hglUMdBcx7nVeVWfgkg2wF39ixBU+mR7mpOCx6fX5qUq2yoZ7L/n7FQqIQVLUUtInjg9KJ78CcVsMtT33xrFURRBic2u1TGt5DRSo+y44ZhgDt4JdYchE7+T8xTCyMJzw8HxZhvWfivIA3rTSbnH3E85eh7nJIMzPTTxVM5uo6OnFnfZWWtJKeN8l7m91Hx3ladtknw== 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=UMtTVqg0moleaf4lldon3zpy6u4e9aZePQLXQxwKuPg=; b=OhdUagaYcfIN85tk2VOJtADrMHr2eYL6loBarhukImolIcwM4u48fGiJpVWMO/LXV4lKLzC66y96Ex/rkVo5vdh+CA+VdM/jKK0+Yy3k5qq7L/JMzPbhjM25zuEPqnzja+GsYquKjjyW1I9ix4eso3hbKe5ooIyP40oKjnIHyi6lsQLLNSd5vU22lnJ04k545uA9JvfAjx2XRh/2GIsW/YQl3KfBECAYJ5jBGeVpJK6oElFgeOZ8G/cLY6lLeQ/z3tyl4Uu6TJYxtxUZZwAr/umjvZfj/QArjZxh8E/DA1j6I+S+lp7OOHUM0V3AqF24+ZGbYJ7Jh1+7kIJ9fADcZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=efficios.com; dmarc=pass action=none header.from=efficios.com; dkim=pass header.d=efficios.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UMtTVqg0moleaf4lldon3zpy6u4e9aZePQLXQxwKuPg=; b=Bi/3SNfHDmj8za+dCpTIBxNo25E2JsS6VnexuXrxJv1Pp7Gz1kAeeA0jSlB0fzYjOmtuVbo0bePxgpyeOFJkC8PBVuy/kBKoNd4+BtwXroMFBJpt290dQ3HIEsoxmp1SPkPs39Mr1eyqzBhBOS0rsth2JheUgk29WmT+du5aU9s6xOu6RoSeRsLPFGxPg/W1QurXR/s8shKIWDygR3dWDnvlQKVv7/zDlT7ERa5GfReLS6ajtzmN41L7Pg9gLb/T2kNB5gSQ5mRHVy/PGd6qRJSAOfQlfSR/KO3FDr1FHtDpqCO2RmDNCkRflOVTGOITSvSupn+P0s8xhhFkSWsOQA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=efficios.com; Received: from YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:be::5) by YT2PR01MB10385.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:df::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.181.16; Fri, 10 Jul 2026 00:03:46 +0000 Received: from YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM ([fe80::6004:a862:d45d:90c1]) by YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM ([fe80::6004:a862:d45d:90c1%4]) with mapi id 15.21.0181.017; Fri, 10 Jul 2026 00:03:46 +0000 Message-ID: <15184196-c470-47f8-8fa0-16f043b1569f@efficios.com> Date: Thu, 9 Jul 2026 20:03:45 -0400 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] hazptr: Introduce CONFIG_HAZPTR_DEBUG misuse detection To: Boqun Feng Cc: paulmck@kernel.org, linux-kernel@vger.kernel.org References: <20260709183009.6814-1-mathieu.desnoyers@efficios.com> <20260709183009.6814-2-mathieu.desnoyers@efficios.com> <2402b90a-7f26-4ef8-b5ff-b3c92d1be9d0@paulmck-laptop> <55079bd3-b049-4e0f-9225-ad41e3562500@efficios.com> <222ca62f-a39f-4b6e-b5b4-7e40bb5ceb36@paulmck-laptop> <2c7f97fa-8429-4fbb-bb33-53e015629f01@paulmck-laptop> <2d801522-6a77-47ad-8daf-d23cc85cbb7a@efficios.com> From: Mathieu Desnoyers Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: YQZPR01CA0147.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:8c::7) To YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:be::5) 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: YT2PR01MB9175:EE_|YT2PR01MB10385:EE_ X-MS-Office365-Filtering-Correlation-Id: b09aed60-7a3f-4b15-e0e9-08dede16b615 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|10070799003|366016|1800799024|5023799004|56012099006|4143699003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: xgJuktjtfVtxrFEoUDmT8pN838Jj1DHGAz+JP8zq7reDHBl/+eqkPmjK75tkKY/gwOzzIYfAzdy5X8rr/vM4fpfna94zX/fhPUcWHGl1espTxIBo9fAHg3hoVa5AGElkKU9eAXA/LmauYcIy+JTUoAWYjPoQq3f3St0l6/pvRW4OJtSoROVR1v6qolIgJ9HQbhjYUuYS5AizfZGiC76PzI+fpkvYE9HB4KxFjEOKpCVbFNNda+UOFtGZd2dm1MBpn9/AcjPxrc+kkGcO6IXM39qVshyI//shHXA/1CjkcqGtvRu3xjF99TtKMVZKMt5p3xWG6vIoVyND1ItX1oldjm20XZm5SjncMa4Iim/JQ/MP1LB6fhX85vNHacu+mlfE6sEOihiGSowjByqfHjm9IwqMKiOKMbZjt2rzeT0P6hBUAqnnSNcCsg3+iXFHvm+J5AlHNP1psWIreH0pujMUQs/q+XOox0pqBob4LFnxZn5leDUfulbPBwMD4uPNKcTZayw0tRRlYzGx+rdfPlkaT5L2hRmoQzxqx718Uv2xpIF7Bnf9Y5P1EPfAbW4bI/B+shtH0asjB1/wHIE1K58KfQO0DJV4IYJ5aMu/zaCZJBQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(10070799003)(366016)(1800799024)(5023799004)(56012099006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RWNuUzlKZXZKM3V1TTJXWFRRemlhNVZEL0tmMlNzeDlvenhKTFhQNVdiNW1S?= =?utf-8?B?N0tPaHRiR3JzYlA2SVplUG1iUjg4QWVmNW8wamtTWkxBVDI5dUFhNmtlelhp?= =?utf-8?B?TjNZaVYzTG9nTjI3MFlLOExRenA4S3RycHNHMlpEU2dGNkhNNnovWHdETmMy?= =?utf-8?B?dG81ODNKYnNtcVpSSit6SVNmV0hXbGdMNHdHSVVpQ0VYWjlCRW5hbmZlcFIy?= =?utf-8?B?UVZJTHZaaDNad2IvaGpidVJtU1JUTTVaZ25zOHo0dk5QZ25GK2ZGWGZWRDFa?= =?utf-8?B?cE1lYzRVNVRkL3c0UkZ1azViZ0ticFYxNVBlTThRb2NnbFNqaDdyRC9hVk5R?= =?utf-8?B?QUsvNlN1N3VRRUFRbzFrSjhwQjZJc2d3eGxzaURZVjhVaWNmY0N6MlN5SWhw?= =?utf-8?B?Yy9HajNZWHJoUHQ1MGtNTnBmVEtWczR2amdqM0lwWHY0OEtlR2tvY05rNDhG?= =?utf-8?B?TDJOSW5venA4anFxQ0x5S0g1SjRhZnhOSmxYc0J0RGRuOUVYT2xubksyU2lQ?= =?utf-8?B?Sk1XdW9KaG5BTkIzb3UzOWxOQ0l4SXVLTllERnhNdXZlZ1NhK3cycjdzL2g4?= =?utf-8?B?SEhQT09nRnVzQlhlWFRubVlFMWZwQUk0UVBZbEo3dXprOGk1RUNLVnNhWkhh?= =?utf-8?B?ZGZQUnYwWENmaEpPcElFeDZDRlV4NCtMRy84YXN2QjVOYWR5VFFYKyt6Rk9u?= =?utf-8?B?QUl0R2ZzNldEdTc4YUxkQ0NkVm84OEVaOGxWZDBGQzRPMk1XdHBSR2gxNmZk?= =?utf-8?B?T0JkY3dPLy9raHBRYnVZUEpjRGtkQ2JOeE1mOUZBZTc2Q0QybzFhRWc3c3lM?= =?utf-8?B?d3RCdXVhK0ttekMyQ29NQnlVd1c1ZEtCeFY0SlRiZndOL2kxNWYrd29CTU1X?= =?utf-8?B?MkNaOEd0MHgvY0JmMXlsNkNKb0s0d3BzSzNMU0NxTDlvZ2h5Szlla3hIc205?= =?utf-8?B?ck02UGNGUlhxRXdOL3JIU3J1MU0wN1ltd2tFTk9SYThsU0FxcVhZNDBSNk8y?= =?utf-8?B?VEF5c09HQWNhQjlvWWIrczJGN2xtM2wzdjAyTStpUGhKTEdPZnRqZ3VJZThi?= =?utf-8?B?ZTUzT2FOOGpMc255a29hdkkzOWxLMjJzdnBqcElNSGgrNmZ2cGZ6YnltQkFv?= =?utf-8?B?aFI5TDQvR09Vb0hSWTJ0cjc4VjA2eE9oNWlLb3JLMDJKR0cyWFpHZWhKcEU1?= =?utf-8?B?b2toMjZtZWdrWVpRVTllNnc2b2J2aDc2cGkwdUZGa3dDNWlGb0NrcW4wZkh5?= =?utf-8?B?M05IMXlnQjNFMDk0UkJZQTRia2d3cXUxaTVZWTIwdnBRa1JUMWdscTJqQkQr?= =?utf-8?B?VWprR2ZXbW9EUUczL1loYktVMHFyeHZOUmZPcGQ3b0preWJzQmUyTXA1bHc3?= =?utf-8?B?R3ByVmJremZPWkl6UWZURU9CSXlYL3lia3hOUTVCdzZDNURhMlNVQnpCWE41?= =?utf-8?B?TERLcmJxUEhTamhCd3BVU3EyRUpkNzA4QVVPTXJIZndNTzI0NEhGOEo2YUo0?= =?utf-8?B?OXVxNEZqZGZnZXllMnlHRFFBaWJYTC8wNWduYjhYa3NnOVZyVjRuektBUlhW?= =?utf-8?B?NFExQmdiS0R3NTlWS2w5Sms4ODljdTNQd2hoSTVqcllZbHJYOFUwVzVPU3Zi?= =?utf-8?B?SUt6dWF3Wk1mVlY5Q3F3S3dEbFlxYjkyTEkwUDNFZHVXNTZzVUJjaitqSVFH?= =?utf-8?B?SUJjM05xNy9hb1lCazNUNExPazlHeXg2bWtYeS9JdGxWWSs4a1hwNGNLaFJy?= =?utf-8?B?RWorRE9xU2lxSmdiRFpiMzZ5R1BHcWJxbXRMRWZjOUJhUjhabzhsaGNBRFpp?= =?utf-8?B?V2ttN1V6U1kzVWhxKy82cjUwVWtxcDlNNy83NnllQU0wU2hjZWswYWRMaDY3?= =?utf-8?B?YW92NjFTY0pXcFFCL3hCUGoyM2RRMFh0NWNsbXdhZXp2eng2bnU0NlZGVnhv?= =?utf-8?B?dkF4Qm5PSFd6NE5lQjBPUVRnRUVrNU5yVGlNTmplemFyeGdVVzRZQ09JYzFw?= =?utf-8?B?STN2TUhyZUhKa3BLNXpwQ2F1amdlNllHU2NmVTN5eUluRmlqMXFsT0tIeTNu?= =?utf-8?B?d0VsOXRZbkZDMG0yYzRTdzR3UDExd3VKditlNHJuRFprUzdFakdjVTlIbVVE?= =?utf-8?B?KzFaamZBQjlCa3I4ZzA5SUhyNW5EeWJCbUZvbVFIc3ZEQ2V3L2ViMlFDWVdw?= =?utf-8?B?NlRQamRtUWQ5L1Z0RUp1RCtZb1ZUaGpaNVVnWHUwOW9la3hjeVovRE44RU5t?= =?utf-8?B?azdHcGpTRXpxVGhOY045UzBvd0RGNWhkR3YwT21zc1N4TDU2bit0VlVKcElZ?= =?utf-8?B?Q1h1NFRqeFdyWmtYT3VEcHN5SUNaekpBWDhpYldGeUVvT29tRWp0M3B0RStx?= =?utf-8?Q?GCDNBc91nqoKenGLs5zG/2Vz+OD2xdGv3jAayBPEMp0Ms?= X-MS-Exchange-AntiSpam-MessageData-1: /d0mwLbYZ0OWwvDlkSaQcXOgToUAKbfIxZs= X-OriginatorOrg: efficios.com X-MS-Exchange-CrossTenant-Network-Message-Id: b09aed60-7a3f-4b15-e0e9-08dede16b615 X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2026 00:03:46.1092 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4f278736-4ab6-415c-957e-1f55336bd31e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: nG1qGdvOsjeQQjTN180LLPTVa5oX/Y9ZZeTBLDtseVDbsUf8jTBz60ybwNfCcsMkRhk9x0W8OzBdtT75GwJkX3E1f6rKtp53Hx+5Tlwk0xk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT2PR01MB10385 On 2026-07-09 19:57, Boqun Feng wrote: > On Thu, Jul 09, 2026 at 07:22:18PM -0400, Mathieu Desnoyers wrote: >> On 2026-07-09 19:05, Paul E. McKenney wrote: >>> On Thu, Jul 09, 2026 at 05:47:00PM -0400, Mathieu Desnoyers wrote: >> [...] >>>>> + */ >>>>> static inline >>>>> void hazptr_detach_from_task(struct hazptr_ctx *ctx) >>>>> { >>>>> @@ -160,17 +178,29 @@ void hazptr_note_context_switch(void) >>>>> } >>>>> } >>>>> -/* >>>>> - * hazptr_acquire: Load pointer at address and protect with hazard pointer. >>>>> +/** >>>>> + * hazptr_acquire - Load pointer at address and protect with hazard pointer. >>>>> + * >>>>> + * @ctx: The hazard-pointer context to be passed to hazptr_release(). >>>>> + * @addr_p: Pointer to the pointer that is to be hazard-pointer protected. >>>>> * >>>>> * Load @addr_p, and protect the loaded pointer with hazard pointer. >>>>> - * When using hazptr_acquire from interrupt handlers, the acquired slots >>>>> - * need to be released before returning from the interrupt handler. >>>> >>>> I see that you removed wording of a major constraint here which allowed >>>> use of hazptr locally in a interrupt handler: the need to pair the >>>> acquire/release within the handler. >>> >>> I did indeed remove that wording. You could do something like this: >>> >>> Task Context IRQ Handler Interrupts Task >>> ------------ --------------------------- >>> preempt_disable(); >>> ihp = __this_cpu_read(irq_hc); ihp = __this_cpu_read(irq_hc); >>> p = hazptr_acquire(ihp, &gp); >>> lp = xchg(p, NULL); >>> if (lp) { >>> do_something(lp); >>> hazptr_release(ihp, lp); >>> } >>> preempt_enable(); >>> >>> If I understand the rules correctly (ha!), this is perfectly legal >>> and does not require a hazptr_detach_from_task(). >>> >> I am concerned about it, because I knowingly just used preempt disable >> to protect hazptr_acquire from the scheduler, but not from interrupt >> handlers, because it's faster than irqoff. >> >> I am concerned that this use of hazptr_acquire could confuse the >> thread-level hazptr_acquire, let's dig: >> >> void *hazptr_acquire(struct hazptr_ctx *ctx, void * const *addr_p) >> { >> struct hazptr_percpu_slots *percpu_slots; >> struct hazptr_slot_item *slot_item; >> struct hazptr_slot *slot; >> void *addr; >> >> guard(preempt)(); >> percpu_slots = this_cpu_ptr(&hazptr_percpu_slots); >> slot_item = &percpu_slots->items[0]; >> slot = &slot_item->slot; >> [...] >> >> from here -------------------- >> if (unlikely(slot->addr)) >> return __hazptr_acquire(ctx, addr_p); >> WRITE_ONCE(slot->addr, HAZPTR_WILDCARD); /* Store B */ >> >> /* Memory ordering: Store B before Load A. */ >> smp_mb(); >> >> /* >> * Load @addr_p after storing wildcard to the hazard pointer slot. >> */ >> addr = READ_ONCE(*addr_p); /* Load A */ >> >> /* >> * We don't care about ordering of Store C. It will simply >> * replace the wildcard by a more specific address. If addr is >> * NULL, we simply store NULL into the slot. >> */ >> WRITE_ONCE(slot->addr, addr); /* Store C */ >> to here ---------------------------- >> >> I designed hazptr_acquire so a _nested_ interrupt which _brings back_ >> the slot addr to its original state will work. Now let's see if >> that's still OK if the interrupt handler leaves the slot->addr >> populated with an address. >> >> And no. If the interrupt happens right before "Store B", its >> reserved slot address is overwritten by the thread. That's incorrect. >> >> So as it is today, the irq handler needs to vacate the slot before it >> returns, either through a hazptr release or a detach. >> >> That being said, this is the code as it is today. If someone finds a >> clever way to support this use-case and keep it fast and not too complex, >> I'm all ears! :) >> > > I don't find this use-case is very useful, but I guess a different set > of percpu slot for interrupts can resolve this issue? Correct, but then you add overhead to hazptr synchronize because it needs to consider additional percpu slots. And then there are softirqs and nmis, so complexity piles up fast. Maybe not an issue, but it's certainly a tradeoff. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com