[Click] [PATCH 2/2] Task: Kill process_pending dead lock

[Roman Chertov]

Eddie,
    Would this be a problem if in kernel mode a large config was dumped 
into a write handler via proclikefs?  Maybe Jelena's crashes were caused 
by that.
    I can conduct a few stress tests.  What are the key requirements for 
the test to see if the new changes work or not?

Roman

Eddie Kohler wrote:
> Joonwoo,
> 
>  > I took look into this lock up issue and I think I found something.
>  >
>  > RoutherThread::driver() calls run_tasks() with locked tasks.
>  > But after calling run_tasks(), current processor can be changed since
>  > schedule() might be called (eg. ScheduleLinux element)
>  > So I think that's problem.  How do you think?
> 
> I totally agree that this could be a problem.
> 
> It looks like EXCLUSIVE handlers never really worked before. :(
> 
> So my current analysis is this.  It is not appropriate for a thread to 
> call blocking functions and/or schedule() when that thread has prevented 
> preemption via get_cpu().  My prior patches prevented preemption.
> 
> The solution is to separate "locking the task list" from "blocking task 
> execution."  Clickfs, when executing an exclusive handler, "blocks task 
> execution."  A thread that wants to examine the task list "locks" the list.
> 
> This commit:
> http://www.read.cs.ucla.edu/gitweb?p=click;a=commit;h=ede0c6b0a1cface05e8d8e2e3496ee7fcd5ee143
> introduces separate APIs for locking the list and blocking task 
> execution.  Exclusive handlers block task execution, but do not lock the 
> task list.  I believe that task execution, in this patch, does not 
> prevent preemption.  I believe the locking works out too.  User-level 
> multithreading tests appear OK.
> 
> Any willing stresstesters?  Pretty please? :)
> 
> Eddie
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>