From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752072AbcAENml (ORCPT ); Tue, 5 Jan 2016 08:42:41 -0500 Received: from smtprelay0213.hostedemail.com ([216.40.44.213]:46120 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751663AbcAENmj (ORCPT ); Tue, 5 Jan 2016 08:42:39 -0500 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::::::::::::::::::::::::::::,RULES_HIT:41:355:379:421:541:599:800:960:966:968:973:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1777:1792:2194:2196:2199:2200:2393:2553:2559:2562:3138:3139:3140:3141:3142:3353:3622:3865:3866:3867:3871:3872:3873:3874:4385:5007:6261:6742:7875:9108:10004:10400:10848:10967:11026:11232:11473:11658:11914:12043:12050:12296:12438:12517:12519:12663:12740:13069:13311:13357:14096:14097:14659:21080:30054:30090:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:2,LUA_SUMMARY:none X-HE-Tag: waves95_33f7a8d16641b X-Filterd-Recvd-Size: 2769 Date: Tue, 5 Jan 2016 08:42:35 -0500 From: Steven Rostedt To: Chris Metcalf Cc: Gilad Ben Yossef , Ingo Molnar , Peter Zijlstra , Andrew Morton , Rik van Riel , Tejun Heo , Frederic Weisbecker , Thomas Gleixner , "Paul E. McKenney" , Christoph Lameter , Viresh Kumar , Catalin Marinas , Will Deacon , Andy Lutomirski , , Subject: Re: [PATCH v9 06/13] task_isolation: add debug boot flag Message-ID: <20160105084235.10ad5ff2@gandalf.local.home> In-Reply-To: <568B0348.2040601@ezchip.com> References: <1451936091-29247-1-git-send-email-cmetcalf@ezchip.com> <1451936091-29247-7-git-send-email-cmetcalf@ezchip.com> <20160104175220.310be95c@gandalf.local.home> <568B0348.2040601@ezchip.com> X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 4 Jan 2016 18:42:00 -0500 Chris Metcalf wrote: > On 1/4/2016 5:52 PM, Steven Rostedt wrote: > > On Mon, 4 Jan 2016 14:34:44 -0500 > > Chris Metcalf wrote: > > > > > >> >+#ifdef CONFIG_TASK_ISOLATION > >> >+void task_isolation_debug(int cpu) > >> >+{ > >> >+ struct task_struct *p; > >> >+ > >> >+ if (!task_isolation_possible(cpu)) > >> >+ return; > >> >+ > >> >+ rcu_read_lock(); > > What's the rcu_read_lock() for? I don't see what is being protected by > > rcu here? > > I'm not completely clear either, but this is the same idiom as is used throughout > kernel/sched/core.c when mapping from a pid or a cpu to a task_struct, since > obviously you could end up racing with the task_struct being removed after the > task dies. My best understanding is that the rcu_read_lock() holds up the final > free of the structure so that we have time here to get another reference to it. > > See for example sched_setaffinity() for a similar use of the idiom. > Ah you're right. I'm still trying to get back up to speed from the holidays. Yeah, we need to grab the lock to prevent the task from going away from the time we get cpu_curr() to the time we up it's ref count. -- Steve