From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 88B18CFC539 for ; Sat, 22 Nov 2025 17:10:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 41D486B0008; Sat, 22 Nov 2025 12:10:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CDE36B000A; Sat, 22 Nov 2025 12:10:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26E266B000C; Sat, 22 Nov 2025 12:10:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 042E56B0008 for ; Sat, 22 Nov 2025 12:10:21 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 8BB0C1A08B5 for ; Sat, 22 Nov 2025 17:10:20 +0000 (UTC) X-FDA: 84138881400.16.6AD27C0 Received: from DU2PR03CU002.outbound.protection.outlook.com (mail-northeuropeazolkn19011025.outbound.protection.outlook.com [52.103.32.25]) by imf27.hostedemail.com (Postfix) with ESMTP id 07D8D40005 for ; Sat, 22 Nov 2025 17:10:16 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=HOTMAIL.DE header.s=selector1 header.b=iVB6XAxf; dmarc=pass (policy=none) header.from=hotmail.de; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf27.hostedemail.com: domain of bernd.edlinger@hotmail.de designates 52.103.32.25 as permitted sender) smtp.mailfrom=bernd.edlinger@hotmail.de ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1763831417; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Fh94mW012b4b4pM7k9F/n2kTOFskPj6U9WAq5+2R+pU=; b=t+SAlvWnl6Zh21ZFA2wGqnYiQcd/zKiU4E6c944WS69rq9Y9iZpIME+3mnGIS8KovIZ6Gu us1gla681msJdcEZM1NotrdoJ9VfrXocsmndSFnBhFm/6NarqgfU5XWoOPZ652NwTo8u/E wd4ZYbYhpOHXaBOP/mA6xy4tzbCbALg= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1763831417; a=rsa-sha256; cv=pass; b=mfNR+Ix+H9lR/0XLeSprED4f+1yvunlQF4CbDe+2JRnspncY+dGQDFqvgaHXUE2i67e0rf rnhFoJlG6lKQ9aUdYQVWSA3s/OpPbTJnfDw7TRxU7+zEK3ghTIzOXndXXQIleA7Ah1CgZZ L83H4Aar60TV3k1iY+355LUJePbM4Dg= ARC-Authentication-Results: i=2; imf27.hostedemail.com; dkim=pass header.d=HOTMAIL.DE header.s=selector1 header.b=iVB6XAxf; dmarc=pass (policy=none) header.from=hotmail.de; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf27.hostedemail.com: domain of bernd.edlinger@hotmail.de designates 52.103.32.25 as permitted sender) smtp.mailfrom=bernd.edlinger@hotmail.de ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=I1Q0QfGsxkbC5C7Na6dLYQ8+dKnycXKWlsoN3U5Hl9XlInMRX2WL91zy32ftyQ7ClaaK+4arR41Hkup7dBo3lTT/s+0qyyYpG1ddafFOcjVOlMzM10tdRHt6Sr1ty4r7ltRo29S0DexHFs4pA5aTzHKEfK9p6rL6wBC9wWgVdJd5FrOzAp/tUMWSpUER98ZmDs8+yQCAFjzSvXSWF6OmtAkorCRhc99xxNFBWl5r4gRn/Src5ri7ixGkLLTqfPXiunnCqehkmpaoSC0uIzhAKY4iU3gMROG4Xy2S47fzIIXh1Qm56SMRuN63+ZBwu46Wcrlz12lapp+KYmllc+WXAQ== 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=Fh94mW012b4b4pM7k9F/n2kTOFskPj6U9WAq5+2R+pU=; b=L/FpZZ8BFnI3FOWJD9K2S6hPuMMbpSnJzsv71FRIGIDHwnY0fM6edk2++EPBfAgnKPj+ha0VqAuylEyM9rap/W5MxaQYEUjgDg6frBBn91tYUT5j173YO59PoFKs1c1t6EE8qEatmqvcOzUsx9lSGmW/vND8Ye6zdtiMw3JoUIRkUTIQZBJS8Zcq54bABsfBa6Lo4E2+uBv5k9FfUzXT2kk7GGyGjwgOc1oBaMQQusdyrTz0zeQ37jfA1VsmWBCVD9JGLKoCAGT4XnFi5dDgmjY8NmWdiz88SzlBYIa/VnwStvKcrlyDefGaSw/Pu355ARdcnKoSLS8rBpwaykvvEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HOTMAIL.DE; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Fh94mW012b4b4pM7k9F/n2kTOFskPj6U9WAq5+2R+pU=; b=iVB6XAxfqpg8ik8VljS+E9E+ibQ0fjQkgRtuprkulw4cKt6crm9uG41LnHr9eDeqgqC5LE7szgIKhVCwhQY4+0ofXlPySZPh+o/n4VqmtXJsd/RaNlUNc6PgB8FYM922xnk4JRkK1WiZSeD4qraCJ3syIeW+64ybib27yjgMmAuAWa85Kzdc6Qc7bMlPneBKTnKRqO/Z8vFqgT/vFBnLwypPsISQj3/DTV4ACXuGXq0/ZsYmgrtHgJDCeDsqXcAho5w7Qdzykb3dgL0sbd7pgnxS60KZKPH+M2rjPZHEVGWado++N/YZI7wUms5ApsWm8gUHX6BRVC6PJBTf8REdcw== Received: from GV2PPF74270EBEE.EURP195.PROD.OUTLOOK.COM (2603:10a6:158:401::8d4) by PRAP195MB1484.EURP195.PROD.OUTLOOK.COM (2603:10a6:102:292::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9343.15; Sat, 22 Nov 2025 17:10:13 +0000 Received: from GV2PPF74270EBEE.EURP195.PROD.OUTLOOK.COM ([fe80::dde:411d:b5f2:49]) by GV2PPF74270EBEE.EURP195.PROD.OUTLOOK.COM ([fe80::dde:411d:b5f2:49%8]) with mapi id 15.20.9343.009; Sat, 22 Nov 2025 17:10:13 +0000 Message-ID: Date: Sat, 22 Nov 2025 18:10:10 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v18] exec: Fix dead-lock in de_thread with ptrace_attach To: "Eric W. Biederman" Cc: Alexander Viro , Alexey Dobriyan , Oleg Nesterov , Kees Cook , Andy Lutomirski , Will Drewry , Christian Brauner , Andrew Morton , Michal Hocko , Serge Hallyn , James Morris , Randy Dunlap , Suren Baghdasaryan , Yafang Shao , Helge Deller , Adrian Reber , Thomas Gleixner , Jens Axboe , Alexei Starovoitov , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, tiozhang , Luis Chamberlain , "Paulo Alcantara (SUSE)" , Sergey Senozhatsky , Frederic Weisbecker , YueHaibing , Paul Moore , Aleksa Sarai , Stefan Roesch , Chao Yu , xu xin , Jeff Layton , Jan Kara , David Hildenbrand , Dave Chinner , Shuah Khan , Elena Reshetova , David Windsor , Mateusz Guzik , Ard Biesheuvel , "Joel Fernandes (Google)" , "Matthew Wilcox (Oracle)" , Hans Liljestrand , Penglei Jiang , Lorenzo Stoakes , Adrian Ratiu , Ingo Molnar , "Peter Zijlstra (Intel)" , Cyrill Gorcunov , Eric Dumazet , Ryan Lee , apparmor@lists.ubuntu.com, selinux@vger.kernel.org References: <87tsyozqdu.fsf@email.froward.int.ebiederm.org> <87wm3ky5n9.fsf@email.froward.int.ebiederm.org> Content-Language: en-US From: Bernd Edlinger In-Reply-To: <87wm3ky5n9.fsf@email.froward.int.ebiederm.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR4P281CA0339.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:ea::13) To GV2PPF74270EBEE.EURP195.PROD.OUTLOOK.COM (2603:10a6:158:401::8d4) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: GV2PPF74270EBEE:EE_|PRAP195MB1484:EE_ X-MS-Office365-Filtering-Correlation-Id: 6a0cab07-1e0e-4009-d723-08de29e9ffc3 X-Microsoft-Antispam: BCL:0;ARA:14566002|51005399006|6090799003|5072599009|461199028|15080799012|23021999003|12121999013|8060799015|19110799012|440099028|3412199025|40105399003|12091999003|56899033; X-Microsoft-Antispam-Message-Info: =?utf-8?B?MVZvYk1tdzB6YXBjRFNZUTlMMHVtU1gxTGFCaEVKZlZvRC9RcVdzbDFRRTBa?= =?utf-8?B?U0J3QUo4V1B4ZTEzM3BIbjN0MS9HeTIwaEhnR3RnV1lBbWw2TzRKNkpLMmQ2?= =?utf-8?B?REZmSWppQkFhY1VCaVNsL1ZmN3UrNTRpemVNajJ2MFpROUVwYjJqVG9pcU5Q?= =?utf-8?B?dWJTSnZ5MzE3NldnMXlTb0QyRlRZbUsvK0lmZFZHcFpjbFZoRDV0a2d4b2Nj?= =?utf-8?B?cjVWbmF5SVdkc1pmbk9hdzF4eXR5dmdRSjVaQXE4c002OFRnWjRBaEQvMVgx?= =?utf-8?B?aEVKZGhGazFhNmZ4RktNcmhmdTJRNWZaNTQ4dU9qU0FaYjRKY1R0NDVrR2Fw?= =?utf-8?B?ZFVKdGpvdnlmR2xxR1FVNUtvWWVlcVJ1THdKRHZLSzFSV1kwSm5oVGs4a3dY?= =?utf-8?B?a1d0VUJZUWxMelBqeFUxbkIxaVhaWmJZb2J2ak9LMWRQdHdvUEd6bTF4eDZQ?= =?utf-8?B?Y2ZaUFZlNGRMaUxENG4vT3dvVWcycEZWdlpaeWltQSt2RGp1UkI0MmFaaGVt?= =?utf-8?B?cE1acTJYNjMxTGJSd0xaY0taWm1rQWlmNitMdzFjVk5NTThUbGxhUi9yUmdl?= =?utf-8?B?UW5wbzRKWXBCWFhqb2ZpRWJ5bmFNcHNoenI5d1B5NnhzRjNkcnpCbERWbkxL?= =?utf-8?B?WnpmM3Urd2FJM3dRd0dSU29OSFZZdk9VNVUxc2xtc0xDYmQ4ZzdNZXdrbk5E?= =?utf-8?B?czBnUlI5UG5mNGFMK0NiTHgzR2VmWW9lVjUwalMwSENseDVuSTNES2VaTEox?= =?utf-8?B?UURucHZEVFFPU0Zud3RXZG5LNGdNWVF1WkFWVkJlTWhmajhTNTdZSkxSQlJM?= =?utf-8?B?bUk5MmNRWlVVOXVzUnlqbjNKMG80MzJLQ3V0Ym9iRUg0YVRRRFF2enpHVUhR?= =?utf-8?B?b0VNbU8vYlM5WExyQzluTXlLRGQ0aGJTUjIzNmdZbnJVbVJDUjlLNllEeTRr?= =?utf-8?B?WnZQc09HREdTNFIrOGhEdWFSdHlETnJLWGR3VjlDNmttNFI3U01nQkhnejdM?= =?utf-8?B?dlBjYXV4OStpWVphMGJ4SW81N0xZaUk0OEZWR0ZiUjVDVWplcTBLVTNPL1Nm?= =?utf-8?B?ZTdHSUs2Z29RTjZPWWhaUVF5aDlPYXhhQk5oVzVWQmZvRjFpVE5hWGxhYlI0?= =?utf-8?B?NFl2Z1A0MjR6RmhsRUFHSzZ4bmNQNXhkRVVraTRYOWhLWStvNjlDdW02cHFB?= =?utf-8?B?V1NlTVE1VkttTGFaNG84MjVteUYweHU3cFB2ZEZMNU5yMmNobFZXc2h5aUMr?= =?utf-8?B?anRXRVZ4bmVwUlFhL0VQbmNVWlF5VXkxVFNiYWszVUlHRmp1Wmt3SHhoclpn?= =?utf-8?B?ejc0TDNVeGZpS2ZwNEtsTXNXVlZGSTlYdTBZVFIyZjhLYzNncjI4ZXNESnJv?= =?utf-8?B?a1FLaEErQlkzeU5zaGxpckU0dUdFTXczbnlITVUrNjhNOThXNDV3OWUxWU5U?= =?utf-8?B?OFpSVklHVGpyellGUkxqSEtWa1NZVVM5WEx5ZjJ2cGR1WDhqSnM5Zm1vWStF?= =?utf-8?B?OTNFcDl4bllVYUtRSGg1NEdMN0k4M2REclNQeG9RTHhVcWhZVTk0bFhpai9K?= =?utf-8?B?dkw2cnpQbUxWNHFQVktuZnJ6YXFVWUo2UnR4L0VyV2hGZzlMYmNrNi85RnJO?= =?utf-8?B?TlZiSUR0VkZhR3d3b3NuU3pnYkF2UmhXQWl5aTNyNlRCTWtsMU5DdEluMENU?= =?utf-8?B?dzE1TGNPYXhpYURvZXN2bGJSQU04RG5wMHRFR1pqYVJuR1JySVlzZnlRPT0=?= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?anRiL1lsa2ZOdXB4WVowM3NkMklYNnJvbENhY1AxTzVVdk1wQ081S3FrK1gz?= =?utf-8?B?b2lXbnlJZzQwZ0VqZ291QnRLbmlmVW9zRExheEpEQXp5VVlhV1pJT2RlRmdH?= =?utf-8?B?UHVCdndmNTJUMFFZVmtLY2hyWnFPWTRsZFhJMHNRNHpYMnJHK1Q5d3JoT252?= =?utf-8?B?d1l6WUtKV1pUNStJRXNWNlVhRStBaVpsV1F2ZjNqUlA0WEY5a3pqUUswcVRS?= =?utf-8?B?SXM1RU9aTWgvMDBRQWs3TnB6QVlhRTRNNkFvYzJaWlFCOTVQTmozeEFXZ0pG?= =?utf-8?B?UzRzaEpKNlFRcEFzNTBqTWVNRWVSWXZkYzM0ZXdkbWFRTUNsMDROVE9mME00?= =?utf-8?B?bUNoWnlkWHIyckFYd2llSU9KZVNhSWRRQk1rNjBtTTFtMThQd0c2aWlCcnJS?= =?utf-8?B?WllFbGhuditkSVNETmh3RVpZZ05JNFpObUdDZFJ2Ni93OHRhT2lMSWU5KzdU?= =?utf-8?B?UEJ2eHlhYUk1K1RRdDV4L3BEbDBHRnVNWVliZ3RkL3ZNbzN4ZDlBYkhyY0RW?= =?utf-8?B?K1BZdVNkaFZ4bEFPZldNbGZxL1FCeGwvMmEwb3EzLzdKZ2JKWFo0YjBoOFFj?= =?utf-8?B?RG93RnJ1R3M2MzZqcHZsTXMxTXBUWjU3bFRYQW15ZzFDb3JRV0JWSUJ0SnJ0?= =?utf-8?B?ZllXMTlqQnFWQTNoa1FlWUxGMnNCTUpoR05mWlNMRzJwOFpyUDJ6K1NUd1cx?= =?utf-8?B?TmJWc083Vkt2M2wyUmZDK0lWVmo3dEpaMW1ZbURzK21SWTNYdFlRV08wMk1L?= =?utf-8?B?dXlSQUtwNU9yMzVtRE9zZ25UR0N1VmpoYU5ZZnRVUUxkclM1VG1aZ0RCMEgx?= =?utf-8?B?QzZVand4VmVLWVhmRll3MTNvYzViQndRNW1Gek5CQUpGdGorOEg5VFR0K1NL?= =?utf-8?B?VENHWW1RaFJEMmVqbDVMQUxGQzlHYzBPR29FT1lSYlNqbldIbmFFSFhNOUVX?= =?utf-8?B?ZUwvSFRka3R5T1JLZTJrTkpwcjZUdkRGL3dXUU5hdys1bkhkc05uZmJTUnhJ?= =?utf-8?B?K3AyeWhOQjY2UHVYRlExRm04QkZUaHpaNU12UFBUelE5ZjUrd2dLL2MrQ1RG?= =?utf-8?B?RTFaaC8rTnZMQitVYUlkUmRWSHBKNnJsWktFWjA5ZHBwOW01NGZ3SjR3WXhU?= =?utf-8?B?NnRSWUtsb3d3eUxVVXZSRDBDcXBaVmp3K3dvWHFHTXVKb0JDV21GSlpSb2tG?= =?utf-8?B?eDliSndRclQrMmU0dWRjY1o2OVhqa09SVnFXdG8xdGExY2ZnRCtLUmtaMTY3?= =?utf-8?B?U1B0aTIxQmRTN0xOeFFCTnNSYmhvWlN3Tng0eW1Wb2JqeEZndzBwY0cwWUw4?= =?utf-8?B?Zm5oUGVHZGc5WThQY2RGaHJZK0xpbm1lOFdQaGZXNVlieUNjVE9RMERIYTdp?= =?utf-8?B?N2VFcXF3YnJOa3VjRC9Pa0tzOCtmOFRQM0NNREpwamxqRnNkRTQ2MmZBeW5a?= =?utf-8?B?Y3BYOThobEtVYXhscG5Ja3plLzRSZzdtLzRUMnY4QUp4Mk4vZnNoUTN0Y3Qv?= =?utf-8?B?OE90TldmN1l2b0h1UFExeDU4bEs5Q1I0dXZOZFFBSnF6WUc5RTFUVHZVLzdY?= =?utf-8?B?c0tHNDZ3b0czT1pNMUViUDRob2hMVDZvd0NKUFZSVFYwaDI4OVI4R0h2ZkN6?= =?utf-8?B?Wk54WlR0bmdnVHdMd0lDL1ZzdmlrZlBtZjR2anJzQWczWjV1eWIySmRPV2NT?= =?utf-8?B?NlhoYTYzYzhHN3VNSGtjYzFaT0d2T0RnbUNkNWcrR3NjUWxSY0IxRlZqcE5X?= =?utf-8?Q?wCMBaYQO+gJGciPYFPG1rTFVHrFDvZQoT68y7EB?= X-OriginatorOrg: sct-15-20-8534-20-msonline-outlook-87dd8.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 6a0cab07-1e0e-4009-d723-08de29e9ffc3 X-MS-Exchange-CrossTenant-AuthSource: GV2PPF74270EBEE.EURP195.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2025 17:10:13.3583 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PRAP195MB1484 X-Stat-Signature: 5wnixqagafbpo7k5m1t3go1yop9u5poj X-Rspam-User: X-Rspamd-Queue-Id: 07D8D40005 X-Rspamd-Server: rspam10 X-HE-Tag: 1763831416-781542 X-HE-Meta: U2FsdGVkX19Gj6OM5NirmZbQrSe8SdrfLRJlvMli0zvjk0c/c/o+n5mO7WNJdq37oRAhqWsR6J2DKu+GUHyPnU9nr5spBI4pyVPvwInui3IGwenzR9mwSOTDl1iL6stvCWE0OqdnZKI0GIFYt1PzSDLpzAHS7WPnO91+ObEQkKaW4TkwvGkXfw12OneDHHU8JnXSOeRlNx82uu8mlwSqZZOTOuXWOM12qUk63PagZhNcg2mhgkA/1ujEAwFiVXJX/lCoYtiTrdPsrBBbiU8l3nDvpOl3qq2Mo6BGvJvsMFVUmLz3PsD/+qgZdnE2zD8MyW1Smv6iNltgiyaWmWrpeL4T3DgkHE/y2cnAVfd1EflSlsNK7Sz3lkaW0MdMtTh6HT+WRIQmg14HSipPHdXRgEwsmJV0ipmFU4MwrCVqE5S4KlQl2PpjqmPigWIK1qin0KKeHk6lM8Sj42eKO7gpNQ10ZEB9/Q7ESlHS9FbtoGv1X5FFMchLTwuQOJZT07QnBCxjxcpnoAfe4Xz9usAJhf8Kv6BWUHaBb51JmzkXn00Tf0v0kBdgg/WftrsS8G8zq3AxEB2srzCS05N68loLknAXm97U1cJlc80bt67bWR/uc/6mxOaIXMmLuekFTlwXoh+UaxbSUd80eA6iM/IMpYT/VXi4T4zhNVj8o+2e2Aj6YIM2iR/qvDizgew+L5c2SW450QC4mxt09BUBBfBSRyrJfKoegkAPr4dXWIh+4DgRkdLZTNmjgQhCFQxligsPUl1dHTaK7Hwb6Nq3hkIxfurhUuHDpY75NnNPRpsK0BtaHoiFDp1AMcFBiP10AqONGkPGbEDp1oHEj2YkT4miDto7Hv8WbF0uRfQkHwMb6L8HFHgXMYHik/u2l7bvPnK3sCgqGZELRIz7c6lOhQ/5F6SfESxnIMvjJ5kOGx84Azp2jpOjclWFfsACGk5AE0JI403yF66UHQ05MDq1884 Lc/e812S h5ZJGtMCnZqkAs2jPinuchHY8UegJthrwFgdHjoQPbqdGrVFM6RlCqn5lN+4uuxzroj6pJQurVbL126YLYT9VxYKsMo/wg1W3PnEojKO1eW3fCVLrbcIOWQfHwO0oibH5xIhs2dYDRnJn54qn/w+jZ1wc9aSJIYMV07IafsQHCMczdHaz2U+AcWa0hr+d3sk+r7BlkfTZOC5qJV31ZwAKu0t8Qjd2ckzUbuF6vPMjhJHLpoQQXLl4ItcMGyotI70I9O8cUyzckvJFS18OyYz1QYijLpj5iXoVLex0oLM5IRs1PYUWHbNW/M4Atrk4jABMmKMyFdkL5Afx6sm4J7/YzvM4PeP50veX7EHoeYha73JN33SRzQ432VoyoFSt7U7YFyV1d90i+Fc5G5QD08PbFv9XYoCfEVWLqJge5rir34H+1FlY88d3q8EjlVht+hbsHuXNHdylKJQgPDfKRETKXDP1lxmAiB2RpQke3Ql6rA429QF/5juKqHakGM15Qpd9gbtRnI8T6z/ZDlvnxo7Eb7BNKq+esGJAqsUZW3Gt8CShReZBNH0s0U03mPE+nQOG/pGEvWCM9k6DzJP43DnZ7JjKrg3t24DoHgif+SE+bUUD85nHGnYoHQTJQRuIwOd+HoHRW5rcaKYAnJEtI9IKsiKKgzGvEWeRaqkZMqnTUfN7Y80zQRzwAjiZCcXm5XQMlcsF9mJsBoh1E6dXRRcdd4f+wActQFoVTdQB X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 11/20/25 18:29, Eric W. Biederman wrote: > "Eric W. Biederman" writes: > >> Bernd Edlinger writes: >> >>> This introduces signal->exec_bprm, which is used to >>> fix the case when at least one of the sibling threads >>> is traced, and therefore the trace process may dead-lock >>> in ptrace_attach, but de_thread will need to wait for the >>> tracer to continue execution. >> >> A small quibble it isn't a dead lock. It isn't even really a live lock, >> as it is possible to SIGKILL our way out. >> That is of course what I meant to say with that sentence. In my language an application process can "dead-lock" by waiting on a mutex forever. Indeed the original problem with the dead-lock (I think in mm_access) was worse, as both involved processes were only killable by "kill -9", but with the remaining problem in ptrace_attach, the debugger can be killed by a simple CTRL-C. So if I understand you right, you want me use a different term here like "the trace process may be blocked in trace_attach" or so? Or could you please give me a concrete suggestion how to rephrase the patch description. BTW, unless there are objections I would also want to rephrase the description of cred_guard_mutex to replace the term "Deprecated" with "Not recommended", like this: --- a/include/linux/sched/signal.h +++ b/include/linux/sched/signal.h @@ -260,11 +260,11 @@ struct signal_struct { struct mutex cred_guard_mutex; /* guard against foreign influences on * credential calculations * (notably. ptrace) * Held while execve runs, except when * a sibling thread is being traced. - * Deprecated do not use in new code. + * Not recommended to use in new code. * Use exec_update_lock instead. */ >> Thinking about this there is a really silly and simple way we can deal >> with this situation for PTRACE_ATTACH. We can send SIGSTOP and wait for >> the thread to stop before doing anything with cred_guard_mutex. >> >> PTRACE_ATTACH already implies sending SIGSTOP so as long as we have >> enough permissions to send SIGSTOP I don't see that being a problem. >> >> The worst case I can see is that we get a case where we stop the >> process, the permission check fails under cred_guard_mutex and >> and ptrace attach has fails and has to send SIGCONT to undo it's >> premature SIGSTOP. That might almost be visible, but it would still >> be legitimate because we can still check that we have permission to >> send SIGSTOP. > > Bah no I am full of it. > > The challenging behavior is in the semantics of the kernel operations. > We need to describe it as such please. > > It is the same class of problem as a single threaded process calls exec > with a pipe attached to both stdin and stdout of the new process. > > For the stdin and stdout we can say just use pull and nonblocking I/O. > > The problem is that both PTRACE_ATTACH and PTRACE_SEIZE block over > the duration of exec, and if exec is waiting for a thread to exit, > and that thread is blocked in PTRACE_EVENT_EXIT waiting for that very > same tracer those processes will hang. Not deadlock. > > > I haven't seen anyone clearly describe the problem lately so I am > repeating it. > > > Just looking at the code I don't think there is any fundamental reason > to call commit_creds after de_thread. If we can change that we can sort > this out without any change in userspace semantics. > > If we can't move commit_creds we have to either give > PTRACE_ATTACH/PTRACE_SEIZE a non-block mode, or break out of > PTRACE_EVENT_EXIT in de_thread. > > I will post a proof of concept of moving commit_creds in just a minute. > > Eric Note: I forgot to add apparmor and selinux mailing list to this patch, previous versions of this did try to avoid to touch the security engine code, and did instead temporarily install the new credentials, mostiy for the benefit of the security engines. But that is considered an unacceptable solution, therefore I want to use instead a new option to ptrace_may_access. All security engines have to handle this option, but the advantage is, that the engines could detect and maybe also deny the unsafe execve. This is an alternative to Eric's patch: "exec: Move cred computation under exec_update_lock" that is supposed to solve the same problem, but tries instead to avoid any user visible API change. Thanks Bernd.