[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080829.130455.54621315.davem@davemloft.net>
Date: Fri, 29 Aug 2008 13:04:55 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: torvalds@...ux-foundation.org
Cc: jes@....com, travis@....com, mingo@...e.hu, Alan.Brunelle@...com,
tglx@...utronix.de, rjw@...k.pl, linux-kernel@...r.kernel.org,
kernel-testers@...r.kernel.org, akpm@...ux-foundation.org,
arjan@...ux.intel.com, rusty@...tcorp.com.au
Subject: Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c -
bisected
From: Linus Torvalds <torvalds@...ux-foundation.org>
Date: Fri, 29 Aug 2008 09:14:44 -0700 (PDT)
> Well, it probably boots because it doesn't really seem to _change_ much of
> anything.
>
> Things like this:
>
> -static inline void arch_send_call_function_ipi(cpumask_t mask)
> +static inline void arch_send_call_function_ipi(cpumask_t *mask)
> {
> - smp_ops.send_call_func_ipi(mask);
> + smp_ops.send_call_func_ipi(*mask);
> }
>
> will still do that stack allocation at the time of the call. You'd have to
> pass the thing all the way down as a pointer..
True, but we have to get there one step at a time.
BTW, sparc64 already wants a pointer here, so it's completely ready for
this:
void arch_send_call_function_ipi(cpumask_t mask)
{
xcall_deliver((u64) &xcall_call_function, 0, 0, &mask);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists