Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp560545pxu; Fri, 4 Dec 2020 09:42:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJzU14K5BnQuku11vF6TavtBu5niURonX0DGZD7wHtlOedpjMBPb7pbertom4tjrZKTV74XE X-Received: by 2002:a17:906:8693:: with SMTP id g19mr8563874ejx.111.1607103768694; Fri, 04 Dec 2020 09:42:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607103768; cv=none; d=google.com; s=arc-20160816; b=wpPzF0MbwLza2lEiryEz75IKA9IrLWPBZh0nXawz0XNluVtPeJmQApARPiLQ5cXf1d Gtz4SP0dRrFcCB32ySpNM34DjPqWROVP2Fu7dy7m2Yrnrt4ER1rQfO259gvRK1OCY/80 AR2uWTNILveAj7cmf6Lh0cn8ZmRblZvmP+7tz43haT/lQ8/+zT8S+rY8q26Yi7t3y1L7 3p9DwhelfvsDFl8uJpCSzMNOlP5Dz4fofhFPzGxyeozovYCFAO1ptQa+M9VFvEdIVOyZ 9O8IvsqOIQVR0ecpRjtGtzlaxJNQBCB6+Skbuhxt3casuB+gwF0sYE1j+1aPwUeL+5Yc 6sBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:mime-version:user-agent:message-id :in-reply-to:date:references:cc:to:from; bh=n1lNiL0y00OZa7ZWGdyfE9fvtkNxji+g6wigCgGqjXg=; b=zr1oRpww/n9kSK5hFUqjmlhP1IeQMSwZ8UNLtZb+/Z7TefxyTk8Ov4gMXkL9Vt0HV/ 2dtbtJOsldeKnNcreaWEcT/XEmQJsKvJhkD0EzINvttlak4Dcyh6yHLq/bi2QBAdYUR1 EWD2ybZLY+jfaSFlgX6isAVSZM7kUg/yh2G9JJeIu1Dn3nOseIvTZN0gNQL/Eii+VbjG NPsjjeLakPYIo+RyyibbmFiCnPflQT+N3maJKzdvyJ9wctc4LPdLGjzLSN0AI6d2VQkI TwsK8/VNJD066efRewTBVIYfwsemuy8yy4vrmHrCzEZWm8+Qoj7Wp/gPL7ssiov/WTQu zXwQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t26si1756649ejx.4.2020.12.04.09.42.24; Fri, 04 Dec 2020 09:42:48 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731291AbgLDRkc (ORCPT + 99 others); Fri, 4 Dec 2020 12:40:32 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:58566 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726518AbgLDRka (ORCPT ); Fri, 4 Dec 2020 12:40:30 -0500 Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1klF3a-009PFt-D2; Fri, 04 Dec 2020 10:39:46 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1klF3Z-0002bV-IP; Fri, 04 Dec 2020 10:39:46 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Bernd Edlinger Cc: linux-kernel@vger.kernel.org, Linus Torvalds , Peter Zijlstra , Ingo Molnar , Will Deacon , Jann Horn , Vasiliy Kulikov , Al Viro , Oleg Nesterov , Christopher Yeoh , Cyrill Gorcunov , Sargun Dhillon , Christian Brauner , Arnd Bergmann , Arnaldo Carvalho de Melo , Waiman Long , Davidlohr Bueso References: <87tut2bqik.fsf@x220.int.ebiederm.org> <87ft4mbqen.fsf@x220.int.ebiederm.org> Date: Fri, 04 Dec 2020 11:39:11 -0600 In-Reply-To: (Bernd Edlinger's message of "Fri, 4 Dec 2020 17:08:01 +0100") Message-ID: <87y2id8o8w.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1klF3Z-0002bV-IP;;;mid=<87y2id8o8w.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18/dyuJ2QBuiFTXqQirv4qseGVz19j5qeg= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa07.xmission.com X-Spam-Level: *** X-Spam-Status: No, score=3.5 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,TR_XM_SB_Phish,T_TM2_M_HEADER_IN_MSG, T_TooManySym_01,XMNoVowels,XMSubLong,XMSubPhish11 autolearn=disabled version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4998] * 0.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 1.5 XMSubPhish11 Phishy Language Subject * 0.0 TR_XM_SB_Phish Phishing flag in subject of message X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;Bernd Edlinger X-Spam-Relay-Country: X-Spam-Timing: total 475 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 10 (2.2%), b_tie_ro: 9 (1.9%), parse: 0.91 (0.2%), extract_message_metadata: 12 (2.5%), get_uri_detail_list: 2.0 (0.4%), tests_pri_-1000: 5 (1.1%), tests_pri_-950: 1.23 (0.3%), tests_pri_-900: 1.03 (0.2%), tests_pri_-90: 90 (19.0%), check_bayes: 89 (18.7%), b_tokenize: 10 (2.0%), b_tok_get_all: 16 (3.3%), b_comp_prob: 2.6 (0.5%), b_tok_touch_all: 58 (12.2%), b_finish: 0.84 (0.2%), tests_pri_0: 342 (71.9%), check_dkim_signature: 0.53 (0.1%), check_dkim_adsp: 2.2 (0.5%), poll_dns_idle: 0.55 (0.1%), tests_pri_10: 2.0 (0.4%), tests_pri_500: 7 (1.4%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 3/3] exec: Transform exec_update_mutex into a rw_semaphore X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Bernd Edlinger writes: > Hi Eric, > > I think I remembered from a previous discussion about this topic, > that it was unclear if the rw_semaphores are working the same > in RT-Linux. Will this fix work in RT as well? The locks should work close enough to the same that correct code is also correct code on RT-linux. If not it is an RT-linux bug. An rw_semaphore may be less than optimal on RT-linux. I do remember that mutexes are prefered. But this change is more about correctness than anything else. > On 12/3/20 9:12 PM, Eric W. Biederman wrote: >> --- a/kernel/kcmp.c >> +++ b/kernel/kcmp.c >> @@ -70,25 +70,25 @@ get_file_raw_ptr(struct task_struct *task, unsigned int idx) >> return file; >> } >> >> -static void kcmp_unlock(struct mutex *m1, struct mutex *m2) >> +static void kcmp_unlock(struct rw_semaphore *l1, struct rw_semaphore *l2) >> { >> - if (likely(m2 != m1)) >> - mutex_unlock(m2); >> - mutex_unlock(m1); >> + if (likely(l2 != l1)) > > is this still necessary ? Yes. Both pids could be threads of the same process or even the same value so yes this is definitely necessary. rw_semaphores don't nest on the same cpu. > >> + up_read(l2); >> + up_read(l1); >> } >> >> -static int kcmp_lock(struct mutex *m1, struct mutex *m2) >> +static int kcmp_lock(struct rw_semaphore *l1, struct rw_semaphore *l2) >> { >> int err; >> >> - if (m2 > m1) >> - swap(m1, m2); >> + if (l2 > l1) >> + swap(l1, l2); > > and this is probably also no longer necessary? I think lockdep needs this, so it can be certain the same rw_semaphore is not nesting on the cpu. Otherwise we will have inconsitencies about which is the nested lock. It won't matter in practice, but I am not certain lockdep knows enough to tell the difference. If anything removing the swap is a candidate for a follow up patch where it can be considered separately from other concerns. For this patch keeping the logic unchanged makes it trivial to verify that the conversion from one lock to another is correct. >> >> - err = mutex_lock_killable(m1); >> - if (!err && likely(m1 != m2)) { >> - err = mutex_lock_killable_nested(m2, SINGLE_DEPTH_NESTING); >> + err = down_read_killable(l1); >> + if (!err && likely(l1 != l2)) { > > and this can now be unconditionally, right? Nope. The two locks can be the same lock, and they don't nest on a single cpu. I tested and verified that lockdep complains bitterly if down_read_killable_nested is replaced with a simple down_read_killable. >> + err = down_read_killable_nested(l2, SINGLE_DEPTH_NESTING); >> if (err) >> - mutex_unlock(m1); >> + up_read(l1); >> } >> >> return err; >> @@ -156,8 +156,8 @@ SYSCALL_DEFINE5(kcmp, pid_t, pid1, pid_t, pid2, int, type, >> /* >> * One should have enough rights to inspect task details. >> */ >> - ret = kcmp_lock(&task1->signal->exec_update_mutex, >> - &task2->signal->exec_update_mutex); >> + ret = kcmp_lock(&task1->signal->exec_update_lock, >> + &task2->signal->exec_update_lock); >> if (ret) >> goto err; >> if (!ptrace_may_access(task1, PTRACE_MODE_READ_REALCREDS) || >> @@ -212,8 +212,8 @@ SYSCALL_DEFINE5(kcmp, pid_t, pid1, pid_t, pid2, int, type, >> } >> >> err_unlock: >> - kcmp_unlock(&task1->signal->exec_update_mutex, >> - &task2->signal->exec_update_mutex); >> + kcmp_unlock(&task1->signal->exec_update_lock, >> + &task2->signal->exec_update_lock); >> err: >> put_task_struct(task1); >> put_task_struct(task2); > > > Thanks > Bernd.