lkml.org 
[lkml]   [2010]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Lockdep splat in cpuset code acquiring alloc_lock
CC Oleg
CC Ingo

on 2010-4-15 5:10, Paul Menage wrote:
> Looks like select_fallback_rq() shouldn't be calling
> cpuset_cpus_allowed_locked(), which does a task_lock(), which isn't
> IRQ safe. Also, according to its comments that should only be held
> with the cpuset callback_mutex held, which seems unlikely from a
> softirq handler.
>
> Also, calling cpuset_cpus_allowed_locked(p, &p->cpus_allowed) stomps
> on state in p without (AFAICS) synchronization.
>
> The description of commit e76bd8d9850c2296a7e8e24c9dce9b5e6b55fe2f
> includes the phrase " I'm fairly sure this works, but there might be a
> deadlock hiding" although I think that the lockdep-reported problem is
> different than what Rusty had in mind.

This problem have been fixed by Oleg Nesterov, and the patchset was merged
into tip tree, but it's scheduled for .35 ...

http://lkml.org/lkml/2010/3/15/73

Thanks!
Miao



\
 
 \ /
  Last update: 2010-04-15 08:41    [W:0.037 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site