Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755209AbcDID1f (ORCPT ); Fri, 8 Apr 2016 23:27:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57118 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751195AbcDID1e (ORCPT ); Fri, 8 Apr 2016 23:27:34 -0400 Reply-To: xlpang@redhat.com Subject: Re: [PATCH] sched/deadline/rtmutex: Fix a PI crash for deadline tasks References: <56FE685E.6080001@redhat.com> <19912883-8AB1-4DFD-A0E1-F23057785243@infradead.org> <56FE78E0.5060504@redhat.com> <20160401215143.GB2906@worktop> <57037974.1020002@redhat.com> <20160405091954.GI3448@twins.programming.kicks-ass.net> <20160405092954.GC24771@twins.programming.kicks-ass.net> <20160408122510.15978179@gandalf.local.home> <20160408173835.GC1087@worktop> <20160408145055.13c98a75@gandalf.local.home> <20160408185916.GQ3448@twins.programming.kicks-ass.net> <20160408151542.24328fd6@gandalf.local.home> <20160408152801.3f0b1c33@gandalf.local.home> To: Steven Rostedt , Peter Zijlstra Cc: linux-kernel@vger.kernel.org, Juri Lelli , Ingo Molnar , Thomas Gleixner From: Xunlei Pang Message-ID: <570876A3.3000704@redhat.com> Date: Sat, 9 Apr 2016 11:27:31 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20160408152801.3f0b1c33@gandalf.local.home> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Sat, 09 Apr 2016 03:27:33 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1244 Lines: 31 On 2016/04/09 at 03:28, Steven Rostedt wrote: > On Fri, 8 Apr 2016 15:15:42 -0400 > Steven Rostedt wrote: > >> From what I understand, the slowfn() modifies the task pi_list (or >> rbtree, as it is today). As this is an unlock, the task being woken >> (the next one to grab the lock) is removed from the previous task's pi >> list. >> >> In rt_mutex_adjust_prio(current) I see it simply grabs current's >> pi_lock and calls __rt_mutex_adjust_prio(current). This calls >> rt_mutex_getprio(current) which returns current's normal prio if it >> doesn't have any pi waiters, or it looks at the top pi waiter on the >> tasks list and returns that. Which wouldn't be the task on wake_q, >> otherwise we wouldn't be deboosting in the first place. >> > OK, I now see that the your previous patch is changing what I'm looking > at :-) This is what happens when you go away and try to catch up on > email and not read the emails by threads. I see the > rt_mutex_adjust_prio() is being changed. > > I'll go back and look at your previous patch (as I looked at that while > traveling and didn't think too hard about it). Sorry for that, I should add more comments about it, will add more next version. Regards, Xunlei > > -- Steve