On 06/27, Michal Hocko wrote: > > On Mon 27-06-16 17:51:20, Oleg Nesterov wrote: > > > > Yes I agree, it would be nice to remove find_lock_task_mm(). And in > > fact it would be nice to kill task_struct->mm (but this needs a lot > > of cleanups). We probably want signal_struct->mm, but this is a bit > > complicated (locking). > > Is there any hard requirement to reset task_struct::mm in the first > place? Well, at least the scheduler needs this. And we need to audit every ->mm != NULL check. > I mean I could have added oom_mm pointer into the task_struct and that > would guarantee that we always have a valid pointer when it is needed > but having yet another mm pointer there. and add another mmdrop(oom_mm) into free_task() ? This would be bad, we do not want to delay __mmdrop()... Look, we even want to make the free_thread_info() synchronous, so that we could free ->stack before the final put_task_struct ;) But could you remind why do you want this right now? I mean, the ability to find ->mm with mm_count != 0 even if the user memory was already freed? Oleg. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>