On Thu, Aug 21, 2014 at 09:37:04AM +0800, Chai Wen wrote: > On 08/19/2014 09:36 AM, Chai Wen wrote: > > > On 08/19/2014 04:38 AM, Don Zickus wrote: > > > >> On Mon, Aug 18, 2014 at 09:02:00PM +0200, Ingo Molnar wrote: > >>> > >>> * Don Zickus <dzickus@xxxxxxxxxx> wrote: > >>> > >>>>>>> So I agree with the motivation of this improvement, but > >>>>>>> is this implementation namespace-safe? > >>>>>> > >>>>>> What namespace are you worried about colliding with? I > >>>>>> thought softlockup_ would provide the safety?? Maybe I > >>>>>> am missing something obvious. :-( > >>>>> > >>>>> I meant PID namespaces - a PID in itself isn't guaranteed > >>>>> to be unique across the system. > >>>> > >>>> Ah, I don't think we thought about that. Is there a better > >>>> way to do this? Is there a domain id or something that can > >>>> be OR'd with the pid? > >>> > >>> What is always unique is the task pointer itself. We use pids > >>> when we interface with user-space - but we don't really do that > >>> here, right? > >> > >> No, I don't believe so. Ok, so saving 'current' and comparing that should > >> be enough, correct? > >> > > > > > > I am not sure of the safety about using pid here with namespace. > > But as to the pointer of process, is there a chance that we got a 'historical' > > address saved in the 'softlockup_warn_pid(or address)_saved' and the current > > hogging process happened to get the same task pointer address? > > If it never happens, I think the comparing of address is ok. > > > > > Hi Ingo > > what do you think of Don's solution- 'comparing of task pointer' ? > Anyway this is just an additional check about some very special cases, > so I think the issue that I am concerned above is not a problem at all. > And after learning some concepts about PID namespace, I think comparing > of task pointer is reliable dealing with PID namespace here. > > And Don, If you want me to re-post this patch, please let me know that. Sure, just quickly test with the task pointer to make sure it still works and then re-post. Cheers, Don -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
