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 2EC16C10F27 for ; Mon, 9 Mar 2020 19:52:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E8A5D20866 for ; Mon, 9 Mar 2020 19:52:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E8A5D20866 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 9F4D06B0005; Mon, 9 Mar 2020 15:52:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CBFC6B0006; Mon, 9 Mar 2020 15:52:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 894C46B0007; Mon, 9 Mar 2020 15:52:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id 6E8826B0005 for ; Mon, 9 Mar 2020 15:52:41 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5483A81FC for ; Mon, 9 Mar 2020 19:52:41 +0000 (UTC) X-FDA: 76576871322.16.tax45_519c0e7d5b047 X-HE-Tag: tax45_519c0e7d5b047 X-Filterd-Recvd-Size: 9246 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05olkn2079.outbound.protection.outlook.com [40.92.89.79]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Mar 2020 19:52:40 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LR5UP4nTXlbz2VSPanyoMb4DvKn1Zoud47dOxIaTPqOmya0bjr/Q7M0UmZ3duUxb7iIiJ752I8jrw3FT9bM7mbFRjXEvNWidhhf6CbC4OdTfsGVE5WCWUvrTPzx6YVZ2H7XJH8hw7yIzb/AsH/MDl3a9SPwLVfklYkwBNNFBlfINBDQ5JJhGZMEP66B5QPEvJ9pg7NmhL2fdIgvrta6oEkuFvdleekdsCMoIGhQHRGoqqA7uaNZimXeVnO85kfaK7Ls/dzB+uSsD5M5dcgAsRNIvvz8zn1JkWNivg8l/dlxmdTPgCOMa47hV50Vq5E79nS1a0Vw1VlsUs9vgvbJAPw== 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=us7arMLgUlBinqeZu1Mkp+JM24VyW/yqREJVsjdZp6Q=; b=HISgO7i7QNl/28ZDpwnSD97ugP9S+2K0ywa/zRvyRPExtckec02LRwxwv2GE2m5ueG4tU28fYA4heLDKAdl5/aocPkjiJyyVsdx//zHueICENyl42lb3sKhYsMLiTpQ4+Y25yiakqZFs83mvmFpk9gxuV12uc+WeZ6iuLmCb/QGS2VkrtfS6y9LeuLRasKapyHKHNEbiDBsiWgxN0cEiAikLI/ivy8KZNuU+ewhP7s4l5wfB4J237zonZCFzj4TZr0eB8E8cKkVDJ6iFIoIQgYBga3hin6kFzUG967cCUPCFCIKgiJaZSiv9wwa2bbxfzK3+bGcVUPWG74dBtY+GWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from DB8EUR05FT061.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc0f::37) by DB8EUR05HT254.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc0f::480) 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 19:52:38 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (10.233.238.56) by DB8EUR05FT061.mail.protection.outlook.com (10.233.238.67) 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 19:52:38 +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 19:52:38 +0000 Received: from [192.168.1.101] (92.77.140.102) by AM0PR06CA0073.eurprd06.prod.outlook.com (2603:10a6:208:fa::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.14 via Frontend Transport; Mon, 9 Mar 2020 19:52:37 +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+o9CTpCnOInKhAqHsAgAADjVGAAAFjAA== Date: Mon, 9 Mar 2020 19:52:38 +0000 Message-ID: References: <202003021531.C77EF10@keescook> <20200303085802.eqn6jbhwxtmz4j2x@wittgenstein> <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> In-Reply-To: <87tv2xz510.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: AM0PR06CA0073.eurprd06.prod.outlook.com (2603:10a6:208:fa::14) To AM6PR03MB5170.eurprd03.prod.outlook.com (2603:10a6:20b:ca::23) x-incomingtopheadermarker: OriginalChecksum:E052DB8E0D4BE9F52D3BB250C54FCE66C8E08203BC122772396A1B3B47280602;UpperCasedChecksum:D2B8584132588694E957B129C60342ECF08B154AE93F08996C18C724C5FD4F63;SizeAsReceived:9906;Count:50 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [gg8QiKW80X8x8ER3daN6HWEBHHRMradi] x-microsoft-original-message-id: x-ms-publictraffictype: Email x-incomingheadercount: 50 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 6e585488-bf69-4a39-5fc5-08d7c4636b81 x-ms-traffictypediagnostic: DB8EUR05HT254: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6QJ1WYrUSrzeSIAWhwAyprirzoT32kImPYMAY4VcRk/gMufeUzP38OS8sB6tdYzIP0Vd9PdZx+HIAmEvqO3Wl+d5tadaQfufGZQ/qT2Ulyop8XKQzmpkuZtpstmzlcwyQiHCpQ1Db3hSO99znan8QWpT+EEv51ww56Bf00vCAlfyVkc3CCmcOZ5um5PtVQnC x-ms-exchange-antispam-messagedata: Su4XjFp3ZwTE/nkD8ppkkZwR3LyyEtggQmpSHLQVK3qnGjUZ1inFOMYGLWZxZ2cUK/joDA9TWF+yHb2TQgFQZlksSqBtLNGZ4eadbSEm6cuci6FQqO9QlzbMMBowfGCGM7uQwLG36QbPG0atzhVLUw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-ID: <3D428C8F34AC3245A2ECA39F23444B91@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: 6e585488-bf69-4a39-5fc5-08d7c4636b81 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2020 19:52:38.3929 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8EUR05HT254 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:45 PM, Eric W. Biederman wrote: > Bernd Edlinger writes: >=20 >> On 3/8/20 10:38 PM, Eric W. Biederman wrote: >>> >>> This consolidation allows the creation of a mutex to replace >>> cred_guard_mutex that is not held of possible indefinite userspace >> >> can you also reword this "held of" thing here as well? >=20 > Done: >=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 siginficant benefits. It makes watch out: sig_i_nificant > 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 > Futher this consolidates all of the possible indefinite waits for Add some r to "Futher", please? > 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 > Eric >=20