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=-3.7 required=3.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, 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 60481C10F25 for ; Mon, 9 Mar 2020 20:03:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 21AE720578 for ; Mon, 9 Mar 2020 20:03:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 21AE720578 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 BC1B66B0005; Mon, 9 Mar 2020 16:03:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B70C26B0006; Mon, 9 Mar 2020 16:03:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5F666B0007; Mon, 9 Mar 2020 16:03:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0008.hostedemail.com [216.40.44.8]) by kanga.kvack.org (Postfix) with ESMTP id 8D9496B0005 for ; Mon, 9 Mar 2020 16:03:49 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 503768248068 for ; Mon, 9 Mar 2020 20:03:49 +0000 (UTC) X-FDA: 76576899378.12.mask34_2146735575511 X-HE-Tag: mask34_2146735575511 X-Filterd-Recvd-Size: 9027 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-oln040092074098.outbound.protection.outlook.com [40.92.74.98]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Mar 2020 20:03:48 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YwJRRzsPfDV6pw8niLXxxARaTQceSzf26gAUJk+Q78sCHOeQiKb9mPTblS6lLAjyAjhuCsOE52US5s8KlGozy6rNitynrMwamzYu7hE0DWbVOc1pR1OMRL/A0VRQ/yO/dTsyLdfRuniCNwDfFQJRDoUDcFdTwtCWUhdQrJJm8svKp5ktcjmcTHEXIfhbhcn7bAhbp2wsJdy90Lr7xcpCpLXgWqQxHVf8tn+FszIbobP6f8AkBTLl2eVRF58Qet/sRA7reEBPdcJQopU14yeOWxtdqw16peAkqFBXNyz6iNzktn66qqnLGL7VGY2DoCaiXTVjixogE1nROF7GeVU6vg== 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=oSMJLLgDr15D4VLWggN8xRkZ4pGZITaT8VMWQQSmgvk=; b=P11a1awaQcx8v8tqSj4tpN/xb2Zq/j9cS2gbUD/Vmxp/qkC713N7XeCrgrkyNgcKkcBWBWaOidWl98BnrzIw5qOdhFJCsCS4fF6yQ4PI6MiUor65ji7Fcu3RLhRkavQoEO6KTt4Jx2vmL63GCapKoERe3RioVEbhGFKS+5HFxXrrcyJWAvka9eT5CMshAak82+UQOgLjltMQ+Fxj6oV3BzTP8S9+8MrVc7IN6BSbt/rXGMKmOLDBbcnlDxKtIOixoYLGHCog+cetgoDq7iO4sa2M4VUcK+dn9oS9zLburSV+4/kKoiHa9CNB2kgfM6oU/YAQ1Uh3CWaaJa4eND1+1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from DB3EUR04FT034.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0c::39) by DB3EUR04HT009.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0c::302) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11; Mon, 9 Mar 2020 20:03:46 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (10.152.24.55) by DB3EUR04FT034.mail.protection.outlook.com (10.152.24.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11 via Frontend Transport; Mon, 9 Mar 2020 20:03:46 +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, 9 Mar 2020 20:03:46 +0000 Received: from [192.168.1.101] (92.77.140.102) by ZR0P278CA0042.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:1d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.16 via Frontend Transport; Mon, 9 Mar 2020 20:03:44 +0000 From: Bernd Edlinger To: "Eric W. Biederman" CC: Christian Brauner , Kees Cook , Jann Horn , Jonathan Corbet , Alexander Viro , Andrew Morton , Alexey Dobriyan , Thomas Gleixner , Oleg Nesterov , Frederic Weisbecker , Andrei Vagin , Ingo Molnar , "Peter Zijlstra (Intel)" , Yuyang Du , David Hildenbrand , Sebastian Andrzej Siewior , Anshuman Khandual , David Howells , James Morris , 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" , "linux-api@vger.kernel.org" Subject: Re: [PATCH v2 4/5] exec: Move exec_mmap right after de_thread in flush_old_exec Thread-Topic: [PATCH v2 4/5] exec: Move exec_mmap right after de_thread in flush_old_exec Thread-Index: AQHV9ZIq8LqSeoOzkk+o9CTpCnOInKhAqHsAgAADjVGAAAFjAIAAAk+agAAAywA= Date: Mon, 9 Mar 2020 20:03:46 +0000 Message-ID: References: <87v9nlii0b.fsf@x220.int.ebiederm.org> <87a74xi4kz.fsf@x220.int.ebiederm.org> <87r1y8dqqz.fsf@x220.int.ebiederm.org> <87tv32cxmf.fsf_-_@x220.int.ebiederm.org> <87v9ne5y4y.fsf_-_@x220.int.ebiederm.org> <875zfe5xzb.fsf_-_@x220.int.ebiederm.org> <87tv2xz510.fsf@x220.int.ebiederm.org> <87mu8pz4ex.fsf@x220.int.ebiederm.org> In-Reply-To: <87mu8pz4ex.fsf@x220.int.ebiederm.org> Accept-Language: en-US, en-GB, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: ZR0P278CA0042.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:1d::11) To AM6PR03MB5170.eurprd03.prod.outlook.com (2603:10a6:20b:ca::23) x-incomingtopheadermarker: OriginalChecksum:ED1668ACE5B6F42E2EC0B7404924F25A11196849EC0806CBF5A7AE4B20F63F3D;UpperCasedChecksum:15FACC825918DCFFC11AB2907EBB8D4EBF54753EBDBAA58E0FAE0DD48575A447;SizeAsReceived:9985;Count:50 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [jGD4KHCtwYTsvQc4p0+xqjqsU8Uw45SI] x-microsoft-original-message-id: <587348ba-6a01-2413-9b4b-f64a1f514ea7@hotmail.de> x-ms-publictraffictype: Email x-incomingheadercount: 50 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: e27f1dd5-758e-4932-b244-08d7c464f9af x-ms-traffictypediagnostic: DB3EUR04HT009: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZpR1yFOseKEmusWU5hW+o9s3YD1lY24qlFYfaX4n5cad/edVd3Jk/8j2cTT06ky0eYQppZ15v0/scxurFQlhToh9G0Qmm8yH2sI3Y77QG/V9dcmsJE6TybdsWxIH8+y60Crwti0Q1xgXYwgnuYfEhAc2uqdEqg+d6mAhDh8TGX5mg+yvrQ3GdKnp22s3ewpi x-ms-exchange-antispam-messagedata: r+bk0gUHakTOjL4n7/G/RzRY/5nUmQupLsoUnZYPNhIIVPCfppSindQ/bjdMmmRdMtZ8iOzWSQVv6IQzclqXFpaYHpFy6GhHxJsy6dSLN8yMXzNE6hGiT4wgYRGAQWVUEFBn9zG4ZAYtiMTYiguJdA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-ID: <100A2EDE7978314BBD2FF1EBC3B5B866@eurprd03.prod.outlook.com> 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: e27f1dd5-758e-4932-b244-08d7c464f9af X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2020 20:03:46.4347 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3EUR04HT009 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/9/20 8:58 PM, Eric W. Biederman wrote: >=20 > Ok. I think this has it sorted: >=20 > exec: Move exec_mmap right after de_thread in flush_old_exec > =20 > I have read through the code in exec_mmap and I do not see anything > that depends on sighand or the sighand lock, or on signals in anyway > so this should be safe. > =20 > This rearrangement of code has two significant benefits. It makes > the determination of passing the point of no return by testing bprm->= mm > accurate. All failures prior to that point in flush_old_exec are > either truly recoverable or they are fatal. > =20 > Further this consolidates all of the possible indefinite waits for > userspace together at the top of flush_old_exec. The possible wait > for a ptracer on PTRACE_EVENT_EXIT, the possible wait for a page faul= t > to be resolved in clear_child_tid, and the possible wait for a page > fault in exit_robust_list. > =20 > This consolidation allows the creation of a mutex to replace > cred_guard_mutex that is not held over possible indefinite userspace > waits. Which will allow removing deadlock scenarios from the kernel. > =20 > Reviewed-by: Bernd Edlinger > Signed-off-by: "Eric W. Biederman" >=20 >=20 > I don't think I usually have this many typos. Sigh. >=20 OK. never mind, Bernd. =20