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 X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E8EB0C3F2DA for ; Mon, 2 Mar 2020 15:56:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A4EB3222C4 for ; Mon, 2 Mar 2020 15:56:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A4EB3222C4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=hotmail.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4C6B46B0003; Mon, 2 Mar 2020 10:56:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 49FC56B0005; Mon, 2 Mar 2020 10:56:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 38D1A6B0006; Mon, 2 Mar 2020 10:56:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0176.hostedemail.com [216.40.44.176]) by kanga.kvack.org (Postfix) with ESMTP id 1FC816B0003 for ; Mon, 2 Mar 2020 10:56:16 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B051BBA1F for ; Mon, 2 Mar 2020 15:56:15 +0000 (UTC) X-FDA: 76550873910.11.sand76_53719cdd7620c X-HE-Tag: sand76_53719cdd7620c X-Filterd-Recvd-Size: 8426 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-oln040092065108.outbound.protection.outlook.com [40.92.65.108]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Mon, 2 Mar 2020 15:56:13 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l2r3lvduDL96KS0h0EN+7YkSAgje1jk+5tNPueNh3896BYDWWc5Euj89wNeorAf+i+XQ4oAcQE5FLJ1MT1c9UXTxXVeXf8HhgoiQxlDsuaPWwiWI4Wsv/BRUja8QhjUaEW26tHDP5DFU9fnrg6fU9YKfvy9aP/prZqb/k79qFZjYyVO5Gpc2uRM4n8tPsZNtC7T0MuOFyj17VZ6MXq1Ig+mVPiJpysZz0893ZAKGaTmpWpMVJ58sXFU8iA99gZKshoXcsKxfg8RonimPSg1ol882GyiFB55K8G3hqt5pQ/vP54SII9CtkHoWBT80M+UOJ0uXHVQ49XOBtjKg01EI4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D+Kd81xLm1x3TxoEszHoxLRpj/1LPM1dSZ2/tf9dSgw=; b=PmJA18Lywan1RnlRmim+xy+Px27lFm8eH6q8ZWG8aNfsHhYqeD/JL43NlVaV2Uqkx5OqqAEc6R+C4x3FJ6FSrjuDC2uA6P7aY9sb6B7etQBMWAwevGa+rkPo802JZJFFQI9/sB3J1qurcCH1ByhPxaiAYsCdK3V4tgPZHe+Jgjug3qkijLkw1OGE75A89/JHUVFlntbqBskbfGdSHQKOyTT++CdHNZeQzRJQ6Toq/ZNlWDBY6tVbIG78xZp8z9A4J3rP5HUcWM8jlxelfVCo5vgtOY3sxazEPhk55dJNnnwOyqVJq/Shux9dcnBYxD0iUNM6uo7ltWk8oZTAZVNxaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from VE1EUR01FT020.eop-EUR01.prod.protection.outlook.com (2a01:111:e400:7e19::39) by VE1EUR01HT123.eop-EUR01.prod.protection.outlook.com (2a01:111:e400:7e19::346) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Mon, 2 Mar 2020 15:56:07 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (10.152.2.58) by VE1EUR01FT020.mail.protection.outlook.com (10.152.2.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14 via Frontend Transport; Mon, 2 Mar 2020 15:56:05 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::1956:d274:cab3:b4dd]) by AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::1956:d274:cab3:b4dd%6]) with mapi id 15.20.2772.019; Mon, 2 Mar 2020 15:56:04 +0000 Received: from [192.168.1.101] (92.77.140.102) by AM0PR06CA0075.eurprd06.prod.outlook.com (2603:10a6:208:fa::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.19 via Frontend Transport; Mon, 2 Mar 2020 15:56:03 +0000 From: Bernd Edlinger To: Oleg Nesterov CC: Jann Horn , Christian Brauner , Jonathan Corbet , Alexander Viro , Andrew Morton , Alexey Dobriyan , "Eric W. Biederman" , Thomas Gleixner , Frederic Weisbecker , Andrei Vagin , Ingo Molnar , "Peter Zijlstra (Intel)" , Yuyang Du , David Hildenbrand , Sebastian Andrzej Siewior , Anshuman Khandual , David Howells , James Morris , Kees Cook , Greg Kroah-Hartman , Shakeel Butt , Jason Gunthorpe , Christian Kellner , Andrea Arcangeli , Aleksa Sarai , "Dmitry V. Levin" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "stable@vger.kernel.org" Subject: Re: [PATCHv2] exec: Fix a deadlock in ptrace Thread-Topic: [PATCHv2] exec: Fix a deadlock in ptrace Thread-Index: AQHV8AjGwZG4WijWc0+aQpdADP+q6qg1PBaAgAA5/QA= Date: Mon, 2 Mar 2020 15:56:04 +0000 Message-ID: References: <20200301185244.zkofjus6xtgkx4s3@wittgenstein> <20200302122828.GA9769@redhat.com> In-Reply-To: <20200302122828.GA9769@redhat.com> Accept-Language: en-US, en-GB, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM0PR06CA0075.eurprd06.prod.outlook.com (2603:10a6:208:fa::16) To AM6PR03MB5170.eurprd03.prod.outlook.com (2603:10a6:20b:ca::23) x-incomingtopheadermarker: OriginalChecksum:3859E16BF71A8EC6423EB232D80AE29A1E09FEE95B4D7450D9F8D23EAC84772D;UpperCasedChecksum:B223ECFEDCD92A9F2C1781AAC90A39F9E0AA91ECCB1C8618827A1BBCB80C5D95;SizeAsReceived:9182;Count:50 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [RgRM/hymeKlspWJoHmyR0Ulb73pdTH9g] x-microsoft-original-message-id: x-ms-publictraffictype: Email x-incomingheadercount: 50 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: b61d0c25-2554-4b5a-1def-08d7bec23679 x-ms-traffictypediagnostic: VE1EUR01HT123: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zGFfTOXtwopFCtyvp7ptFwafemwNiCw/uWpTmVi+SLPvY/6zuwibbsn8jTFPu/q2u2H6q8coBRQSeCgdgFDYwHrY3rtF5IsrQXElOAMtsrgIiN5EHlgln0I7tWBp6pwuZO7kOf9/huDfs3VB5dZWQAnep8rzczUeg+2gWknmc1KDpBTdjEbspnnS2QTbrGb2lvk4zzlDGbQQ27IB//zFxqMUM5tkCXNn1q4/dbz4gEE= x-ms-exchange-antispam-messagedata: 5b5OpsuSrxieJKpRNkYaSOPnTdNv+Phjlo/8abt2jrLPA/WxuhhMsDmFiKcLHzV+6jKJLoxI6QI9LkQJHYJcQn0kl/B+AwkcAN4XXQUap6t+GL3Qw5sqxWNdwePFmm7WZmHpszbmMt79ctrvP8Wu2w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: b61d0c25-2554-4b5a-1def-08d7bec23679 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 15:56:04.6412 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR01HT123 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: On 3/2/20 1:28 PM, Oleg Nesterov wrote: > On 03/01, Bernd Edlinger wrote: >> >> This fixes a deadlock in the tracer when tracing a multi-threaded >> application that calls execve while more than one thread are running. >=20 > Heh. Yes, known problem. See my attempt to fix it: > https://lore.kernel.org/lkml/20170213141452.GA30203@redhat.com/ >=20 >> @@ -1224,7 +1224,7 @@ struct mm_struct *mm_access(struct task_struct *ta= sk, unsigned int mode) >> struct mm_struct *mm; >> int err; >> =20 >> - err =3D mutex_lock_killable(&task->signal->cred_guard_mutex); >> + err =3D mutex_lock_killable(&task->signal->cred_change_mutex); >=20 > So if I understand correctly your patch doesn't fix other problems > with debugger waiting for cred_guard_mutex. >=20 No, but I see this just as a first step. > I too do not think this can justify the new mutex in signal_struct... >=20 I think for the vm_access the semantic of this mutex is clear, that it prevents the credentials to change while it is held by vm_access, and probably other places can take advantage of this mutex as well. While on the other hand, the cred_guard_mutex is needed to avoid two threads calling execve at the same time. So that is needed as well. What remains is probably making PTHREAD_ATTACH detect that the process is currently in execve, and make that call fail in that situation. I have not thought in depth about that problem, but it will probably just need the right mutex to access current->in_execve. That's at least how I see it. Thanks Bernd.