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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 D992FC4361A for ; Fri, 4 Dec 2020 22:14:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9219C22CB9 for ; Fri, 4 Dec 2020 22:14:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729917AbgLDWOc (ORCPT ); Fri, 4 Dec 2020 17:14:32 -0500 Received: from mx2.suse.de ([195.135.220.15]:32990 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728273AbgLDWOc (ORCPT ); Fri, 4 Dec 2020 17:14:32 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 46B34AFEB; Fri, 4 Dec 2020 22:13:50 +0000 (UTC) Date: Fri, 4 Dec 2020 13:48:36 -0800 From: Davidlohr Bueso To: Linus Torvalds Cc: Bernd Edlinger , "Eric W. Biederman" , Linux Kernel Mailing List , Peter Zijlstra , Ingo Molnar , Will Deacon , Jann Horn , Vasiliy Kulikov , Al Viro , Oleg Nesterov , Cyrill Gorcunov , Sargun Dhillon , Christian Brauner , Arnd Bergmann , Arnaldo Carvalho de Melo , Waiman Long Subject: Re: [PATCH 3/3] exec: Transform exec_update_mutex into a rw_semaphore Message-ID: <20201204214836.3rncqw5kox42b4i2@linux-p48b.lan> References: <87tut2bqik.fsf@x220.int.ebiederm.org> <87ft4mbqen.fsf@x220.int.ebiederm.org> <875z5h4b7a.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 04 Dec 2020, Linus Torvalds wrote: >On Fri, Dec 4, 2020 at 12:30 PM Bernd Edlinger > wrote: >>> >> > perf_event_open (exec_update_mutex -> ovl_i_mutex) > >Side note: this one looks like it should be easy to fix. > >Is there any real reason why exec_update_mutex is actually gotten that >early, and held for that long in the perf event code? afaict just to validate the whole operation early. Per 79c9ce57eb2 the mutex will guard the check and the perf_install_in_context vs exec. > >I _think_ we could move the ptrace check to be much later, to _just_ before that > > * This is the point on no return; we cannot fail hereafter. > >point in the perf event install chain.. Peter had the idea of doing the ptrace_may_access() check twice: first lockless and early, then under exec_update_mutex when it mattered right before perf_install_in_context(): https://lore.kernel.org/linux-fsdevel/20200828123720.GZ1362448@hirez.programming.kicks-ass.net/ > >I don't think it needs to be moved down even that much, I think it >would be sufficient to move it down below the "perf_event_alloc()", >but I didn't check very much. Yeah we could just keep a single ptrace_may_access() check just further down until it won't deadlock. Thanks, Davidlohr