Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp733808pxu; Fri, 4 Dec 2020 14:19:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJxxG0CxbPjhJmSwbEvRaYNCwfFNF77HiVs29IF2hQ3GY8rtiarTI2l9LhI2mQjrdBfgpahO X-Received: by 2002:a17:906:a51:: with SMTP id x17mr9239308ejf.97.1607120379494; Fri, 04 Dec 2020 14:19:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607120379; cv=none; d=google.com; s=arc-20160816; b=C4SVuYfh/qVkj2lTCJVKuINnQr+YcYkWk2zvDnrRhVehoB6VF2jf8y0DwC2TNx39Go CVlmxjOUGgfiIp70WEbzhRudMjm2bLkgeNvu/xHwN0CmhCALduKSZfd51zATEuPon7X4 UIwnBym5le+PM5GWg1mdhsLUtW+bxtFH5Feo70V7DzO8nYPw+qjCA+G8q7uZhsVy11gO UsU7zmmeihpxXFuahhDYZSjUQbtbf/4CaO8ey/CafoIm0hOIUUXTBeiZEtPjPo+3i90r 15+MkrRSzNlny0V2q7kesqEAzKnTYudamJ8+XwzzlmL+2tgLBkiUGaoSUcJ+6G6QCi3P vvpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=kRKKk5v/+26rE93gjeZK9hup41et9wHtfYhJakFEyDk=; b=GJmwBecclLSQVzdJ8XJFtVj9iky8pCgR8CAkRnU3NiZNLkLt7xypmoQKy9MRVA+/1X iceYLYXX7HfoYYGvYAZYE4wXmpuTrnV7m/2yapyB99Gs74WjkNOLxdBOf0JZDbQeYOh2 qeELlNKZb7vRzLOU5rDrggG10udBdZ5MlXQFWb5CCifbzWEAvz48I3YWK600TqufhzyS afJ1GJRs5iB89/ygdaCfImhsII5o4omHpbFVvhFOZ3BAInjLdH7GZot+Lhwog9Jw93U2 D27EZ8On89/5425mhnDAMCRPVNqDd7SqJPfIR3gyyfZKwXRV+e3+LpY8JTirutEpuJp6 crog== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a29si3832399edm.401.2020.12.04.14.19.16; Fri, 04 Dec 2020 14:19:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729367AbgLDWOc (ORCPT + 99 others); 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