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 067A7C10F27 for ; Mon, 9 Mar 2020 13:58:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C686521927 for ; Mon, 9 Mar 2020 13:58:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C686521927 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 66BBD6B0005; Mon, 9 Mar 2020 09:58:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 61AB76B0006; Mon, 9 Mar 2020 09:58:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BB6F6B0007; Mon, 9 Mar 2020 09:58:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0074.hostedemail.com [216.40.44.74]) by kanga.kvack.org (Postfix) with ESMTP id 305836B0005 for ; Mon, 9 Mar 2020 09:58:20 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E4A5D83FD for ; Mon, 9 Mar 2020 13:58:19 +0000 (UTC) X-FDA: 76575978318.18.mind63_2b8bb04724c26 X-HE-Tag: mind63_2b8bb04724c26 X-Filterd-Recvd-Size: 8769 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05olkn2010.outbound.protection.outlook.com [40.92.89.10]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Mar 2020 13:58:19 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cNdLiRtrH5ekA27X/aoi4PoxksbtltwHlWqyD46y4ZHu3OvuFeJgAvO2f0wfcSFczty7bq90yLx6Z/QEZkq1rs67wNonBpfJnWj2sYG1YYrAsNvbnXxl7/U5zjih40hW/0bD/y7bClO4mqJ5DymGoX2aVez0KVQ2LT2E8dWto2PtBsXXqvzydjb2ZBI8RZN6ykNZIIXAMMsBS8ubTRtPzERk+EyX+aB5mBQ44IniSxINH9NqYjDb9MDYYHHOGRd7ahZf4/RLzhSiboC1Wp4pf8TJBp7g7hlzJUdcmM32DbTWXhYLqc2w6Mnvw6TTKrFgDhGAH85y0nt2eeSa70PKPA== 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=HzDi2PRRfzhlxXKQhfBmvy78dba+PGtFU/z7/fqNbQU=; b=G7OH7BxJQq10KiDhEcbh8xSALiTOKHDQRggzq4EEcjfrtjx60jksw5rxvanOvjyIUhO+/opzFayGiDgyCFbgYiK1HHRAFFmOka8olXUjGDgZ8EzSipFdfUj8kcn5VfYhoGd7uF/RVMH0r6TW+yuVBDVe0SpaAmGopbBSCT7YBhNqiOY73xJYsH8jw9UkS1i5xkPv2eLy2lqJ9fCCCztbGNUqSLiWOVfpMmcsVmbC5LcMwb5trE5rhdIs20Q22Wajlp1vt/fstxxnYxVZmawUTJO6UKlZ0RG5QxRljnesqbvekcpBn9pSnFvGD0tOatDkLs7TXUBRb1s86o7w24t6tA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from AM6EUR05FT032.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc11::36) by AM6EUR05HT090.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc11::206) 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 13:58:17 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (10.233.240.56) by AM6EUR05FT032.mail.protection.outlook.com (10.233.240.101) 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 13:58:17 +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 13:58:17 +0000 Received: from [192.168.1.101] (92.77.140.102) by AM3PR03CA0063.eurprd03.prod.outlook.com (2603:10a6:207:5::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17 via Frontend Transport; Mon, 9 Mar 2020 13:58:15 +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 0/5] Infrastructure to allow fixing exec deadlocks Thread-Topic: [PATCH 0/5] Infrastructure to allow fixing exec deadlocks Thread-Index: AQHV9ZG1D7QAmxV3AE+IpPLpt1dbHqhASmkA Date: Mon, 9 Mar 2020 13:58:17 +0000 Message-ID: References: <87v9nmjulm.fsf@x220.int.ebiederm.org> <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> In-Reply-To: <87v9ne5y4y.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: AM3PR03CA0063.eurprd03.prod.outlook.com (2603:10a6:207:5::21) To AM6PR03MB5170.eurprd03.prod.outlook.com (2603:10a6:20b:ca::23) x-incomingtopheadermarker: OriginalChecksum:3C3993E7E100E343A0EC8C7C8C46EB5BD10BDFAD6BA3112FFE3A16AC5EC265D3;UpperCasedChecksum:BC355047DC71EA8CF61542476612D2326E4B02764677BB50BC3707FBBB744701;SizeAsReceived:9903;Count:50 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [FgTnomUXHN0mDjAsUKv2sI1B6V1NrkpG] x-microsoft-original-message-id: <601293ca-4708-c1d6-a1d6-8569a6f97d51@hotmail.de> x-ms-publictraffictype: Email x-incomingheadercount: 50 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: aa23393d-0faa-458f-96e1-08d7c431eac8 x-ms-traffictypediagnostic: AM6EUR05HT090: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Tu0dHfAJ+lJ+a1N0BJxBp9BKqxl3nQHYDxey+ENntAgZJ2Ry0o8UAdWh3cyyI3oMU5h6Ko9VPMLh17VqdsrgpTJAm95LAWfSqFJxVOTlJcVSg91R+Uw+iw34yuoNcgZTM2WuJzL+fjeKDFsCx3BM4f5EG/XPE9vOlK3nY/CqeuS5ZxX/kjWYmwZMoZMWlUHM x-ms-exchange-antispam-messagedata: 12olxh/ofsbPD9E+JLgpcZSXE2Ip/uSrXpClYJjpNnlrpykN7LyafE7EOioXgegnky7WfZiNIsxp+6b/cUEuKXehIHLEGNaKAXIoQvRz5G6gcj4O2jKBT2EZVJTFT1iAl2JWKXUJX6lOwhofCrlB2g== 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: aa23393d-0faa-458f-96e1-08d7c431eac8 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2020 13:58:17.0818 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6EUR05HT090 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/8/20 10:34 PM, Eric W. Biederman wrote: >=20 > Bernd, everyone >=20 > This is how I think the infrastructure change should look that makes way > for fixing this issue. >=20 > - Cleanup and reorder the code so code that can potentially wait > indefinitely for userspace comes at the beginning for flush_old_exec. > - Add a new mutex and take it after we have passed any potential > indefinite waits for userspace. >=20 > Then I think it is just going through the existing users of > cred_guard_mutex and fixing them to use the new one. >=20 > There really aren't that many users of cred_guard_mutex so we should be > able to get through the easy ones fairly quickly. And anything that > isn't easy we can wait until we have a good fix. >=20 > The users of cred_guard_mutex that I saw were: > fs/proc/base.c: > proc_pid_attr_write > do_io_accounting > proc_pid_stack > proc_pid_syscall > proc_pid_personality > =20 > perf_event_open > mm_access > kcmp > pidfd_fget > seccomp_set_mode_filter >=20 > Bernd I think I have addressed the issues you pointed out in v1. > Please let me know if you see anything else. >=20 Yes, looks good, except some nits. Thanks Bernd.