Messages in this thread | | | Subject | Re: FYI: mmap_sem OOM patch | From | Peter Zijlstra <> | Date | Thu, 08 Jul 2010 13:02:01 +0200 |
| |
On Thu, 2010-07-08 at 19:57 +0900, KOSAKI Motohiro wrote: > > On Thu, 2010-07-08 at 03:39 -0700, Michel Lespinasse wrote: > > > > > > > > > One way to fix this is to have T4 wake from the oom queue and return an > > > allocation failure instead of insisting on going oom itself when T1 > > > decides to take down the task. > > > > > > How would you have T4 figure out the deadlock situation ? T1 is taking down T2, not T4... > > > > If T2 and T4 share a mmap_sem they belong to the same process. OOM takes > > down the whole process by sending around signals of sorts (SIGKILL?), so > > if T4 gets a fatal signal while it is waiting to enter the oom thingy, > > have it abort and return an allocation failure. > > > > That alloc failure (along with a pending fatal signal) will very likely > > lead to the release of its mmap_sem (if not, there's more things to > > cure). > > > > At which point the cycle is broken an stuff continues as it was > > intended. > > Now, I've reread current code. I think mmotm already have this.
<snip code>
[ small note on that we really should kill __GFP_NOFAIL, its utter deadlock potential ]
> Thought?
So either its not working or google never tried that code?
| |