Messages in this thread |  | | Date | Fri, 10 Feb 2012 21:21:31 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH 3/8] arm: Fix possible race on task->mm |
| |
On 02/09, Anton Vorontsov wrote: > > On Thu, Feb 09, 2012 at 07:33:46PM +0400, Anton Vorontsov wrote: > > On Wed, Feb 08, 2012 at 05:08:08PM +0100, Oleg Nesterov wrote: > > > On 02/07, Anton Vorontsov wrote: > > > > > > > > Checking for task->mm is dangerous as ->mm might disappear (exit_mm() > > > > assigns NULL under task_lock(), so tasklist lock is not enough). > > > > > > > > We can't use get_task_mm()/mmput() pair as mmput() might sleep, > > > > > > Yes, but > > > > > > > so let's take the task lock while we care about its mm. > > > > > > it seems that this needs find_lock_task_mm() too ? > > > > > > the same for the rest patches in this series. > > > > Yep, I think you're right, will add this change. > > Thinking about it more... making the code use find_lock_task_mm > would be a behaviour change. Sure, in trivial cases like ARM this > looks like a 100% safe thing to do, but in e.g. UML case, I > wouldn't bet much money on that 'mm->context.id.u.pid' would be > still meaningful.
OK, perhaps UML differs. I don't know what context.id.u.pid means. Although at first glance it would be meaningful anyway...
> So, I'd rather do it in a separate change, so this can be easily > reverted.
In the !UML case find_lock_task_mm() "obviously looks like the right thing...
But I won't argue, up to you.
Oleg.
|  |