lkml.org 
[lkml]   [2008]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
    Date
    On Friday 26 September 2008 01:42:13 Linus Torvalds wrote:
    > On Thu, 25 Sep 2008, Rusty Russell wrote:
    > > This turns out to be awful in practice, mainly due to const.
    > > Consider:
    > >
    > > #ifdef CONFIG_CPUMASK_OFFSTACK
    > > typedef unsigned long *cpumask_t;
    > > #else
    > > typedef unsigned long cpumask_t[1];
    > > #endif
    > >
    > > cpumask_t returns_cpumask(void);
    >
    > No. That's already broken. You cannot return a cpumask_t, regardless of
    > interface. We must not do it regardless of how we pass those things
    > around, since it generates _yet_ another temporary on the stack for the
    > return slot for any kind of structure.

    No, for large NR_CPUS, cpumask_t is a pointer as shown. And we have numerous
    basic functions which return a cpumask_t. Yes, this is part of the problem.

    > What _is_ relevant is how we allocate them when we need temporary CPU
    > masks. And _that_ is where my suggestion comes in. For small NR_CPUS, we
    > really do want to allocate them on the stack, because calling kmalloc for
    > a 4- or 8-byte allocation is just _stupid_.

    Right, but cpumask_t is used for far more than stack decls, thus the problems.

    I can make a separate "cpumask_stack_t" and use your method tho. I think that
    might even reduce churn and allow us to do this in parts.

    > which has to be converted some way. And I think it needs to be converted
    > in a way that does *not* force us to call kmalloc() for idiotically small
    > values.

    Yeah, got that. But your suggestion to change cpumask_t turned out horribly
    ugly.

    Cheers,
    Rusty.


    \
     
     \ /
      Last update: 2008-09-26 07:27    [W:4.157 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site