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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6FC93C433F5 for ; Wed, 19 Jan 2022 19:13:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237244AbiASTNy (ORCPT ); Wed, 19 Jan 2022 14:13:54 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:35552 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230121AbiASTNx (ORCPT ); Wed, 19 Jan 2022 14:13:53 -0500 Received: from in02.mta.xmission.com ([166.70.13.52]:46500) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nAGP0-004pU3-MY; Wed, 19 Jan 2022 12:13:50 -0700 Received: from ip68-110-24-146.om.om.cox.net ([68.110.24.146]:45716 helo=email.froward.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1nAGOz-006ccZ-Aj; Wed, 19 Jan 2022 12:13:50 -0700 From: "Eric W. Biederman" To: Valentin Schneider Cc: linux-kernel@vger.kernel.org, Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Steven Rostedt , Sebastian Andrzej Siewior , Abhijeet Dharmapurikar , Dietmar Eggemann , Peter Zijlstra , Ingo Molnar , Vincent Guittot , Thomas Gleixner , Juri Lelli , Daniel Bristot de Oliveira , Kees Cook , Andrew Morton , Alexey Gladkov , "Kenta.Tada@sony.com" , Randy Dunlap , Ed Tsai , linux-api@vger.kernel.org References: <20220117164633.322550-1-valentin.schneider@arm.com> <20220117164633.322550-3-valentin.schneider@arm.com> <878rve89cc.fsf@email.froward.int.ebiederm.org> <878rvd6jgu.mognet@arm.com> <87h7a06hkr.fsf@email.froward.int.ebiederm.org> <875yqf7eq4.mognet@arm.com> Date: Wed, 19 Jan 2022 13:13:42 -0600 In-Reply-To: <875yqf7eq4.mognet@arm.com> (Valentin Schneider's message of "Wed, 19 Jan 2022 18:38:43 +0000") Message-ID: <87fspj7d3t.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1nAGOz-006ccZ-Aj;;;mid=<87fspj7d3t.fsf@email.froward.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.110.24.146;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+oSM1ZuUDl1IfWlCLn1yiB3bjw4dARZ6s= X-SA-Exim-Connect-IP: 68.110.24.146 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v2 2/2] sched/tracing: Add TASK_RTLOCK_WAIT to TASK_REPORT X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Valentin Schneider writes: > On 18/01/22 12:10, Eric W. Biederman wrote: >> Valentin Schneider writes: >>> >>> Alternatively, TASK_RTLOCK_WAIT could be masqueraded as >>> TASK_(UN)INTERRUPTIBLE when reported to userspace - it is actually somewhat >>> similar, unlike TASK_IDLE vs TASK_UNINTERRUPTIBLE for instance. The >>> handling in get_task_state() will be fugly, but it might be preferable over >>> exposing a detail userspace might not need to be made aware of? >> >> Right. >> >> Frequently I have seen people do a cost/benefit analysis. >> >> If the benefit is enough, and tracking down the userspace programs that >> need to be verified to work with the change is inexpensive enough the >> change is made. Always keeping in mind that if something was missed and >> the change causes a regression the change will need to be reverted. >> >> If there is little benefit or the cost to track down userspace is great >> enough the work is put in to hide the change from userspace. Just >> because it is too much trouble to expose it to userspace. >> >> I honestly don't have any kind of sense about how hard it is to verify >> that a userspace regression won't result from a change like this. I >> just know that the question needs to be asked. >> > > I see it as: does it actually make sense to expose a new state? All the > information this is conveying is: "this task took a lock that is > substituted by a sleepable lock under PREEMPT_RT". Now that you brought > this up, I don't really see much value in this vs just conveying that the > task is sleeping on a lock, i.e. just report the same as if it had gone > through rt_mutex_lock(), aka: That seems reasonable to me. Eric > > --- > diff --git a/include/linux/sched.h b/include/linux/sched.h > index d00837d12b9d..ac7b3eef4a61 100644 > --- a/include/linux/sched.h > +++ b/include/linux/sched.h > @@ -1626,6 +1626,14 @@ static inline unsigned int __task_state_index(unsigned int tsk_state, > if (tsk_state == TASK_IDLE) > state = TASK_REPORT_IDLE; > > + /* > + * We're lying here, but rather than expose a completely new task state > + * to userspace, we can make this appear as if the task had gone through > + * a regular rt_mutex_lock() call. > + */ > + if (tsk_state == TASK_RTLOCK_WAIT) > + state = TASK_UNINTERRUPTIBLE; > + > return fls(state); > } >