On Mon, Apr 09, 2007 at 07:41:42PM -0700, Andrew Morton wrote:
> > > This means we'll call set_cpus_allowed() while in atomic state, but
> > > set_cpus_allowed() does sleepy stuff.
> >
> > Puzzled. This diff shouldn't change anything about the context we're in
> > when we call set_cpus_allowed, and as we're not seeing warnings now,
> > I'm not sure what I'm missing?
>
> set_cpus_allowed() will only sleep in special circumstances: when we're
> telling the target task that it is not allwed to run on a CPU upon which it
> is presently executing. So it needs to be synchronously migrated off that
> CPU, which requires that the set_cpus_allowed() caller block.
>
> You're probably just not hitting that case.
Oh, now I see it. The set_cpus_allowed that was inside the preempt stuff
I was adding. (that the diff elided). Yeah, that's a problem. Bugger.
> Probably we should have a might_sleep() in set_cpus_allowed(), although
> there might be callers who are guaranteeed to never hit that case and who
> might legitimately want special treatment to avoid the warning.
This whole file is going away in .22, and we have a viable alternative in
.21 (acpi-cpufreq), so I'm not overly worried about fixing this up
given it only shows up in debug kernels, especially at this stage in -rc.
(Yeah, it's a cop-out, but unless someone with more interest in this problem
steps up, I've bigger fishes to fry).
Dave
--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
