Re: sched: WARNING: at include/linux/cpumask.h:108 select_fallback_rq+0x241/0x280()

Sasha Levin
2012-04-14T18:37:23Z

On Sat, Apr 14, 2012 at 8:12 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Sat, 2012-04-14 at 13:40 +0200, Sasha Levin wrote:
>> On Sat, Apr 14, 2012 at 11:17 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > On Sat, 2012-03-31 at 13:22 +0530, Srivatsa S. Bhat wrote:
>> >>
>> >> One of the perils of using macros instead of true function calls :-(
>> >>
>> > You can do type checking in macros too, its not pretty, but there's
>> > several such things already, see min()/max() for example.
>>
>> Would it make sense to somehow standardize type checking in kernel
>> macros? Possibly a set of wrappers that would make type checking easy
>> to get into new and existing macros?
>
>
> I had a quick go with the below and that doesn't quite work for no
> obvious reasons as of yet.. Also, that call out to cpumask_next() should
> already do type validation for us, so still no clue why my earlier code
> compiled at all.

I've also started working on it, I have something that looks pretty
good and detects the bug which has caused this discussion.

I want to apply it on several more macros around the kernel and I'll
send a RFC. Basically I want to deal with the cpumask thing, update
min()/max()/etc to use it and convert the list or rbtree macros to use
it as well. It'll give us a good look on how something like that would
look around the kernel.