From: Cliff Wickman <[email protected]>
This patch tweaks a couple things:
- uv_flush_tlb_others()
the WARN_ON(!in_atomic()); fails if CONFIG_PREEMPT is not enabled
The #ifdef may not be the right fix. The fix is probably in the
in_atomic macro, but I'm not sure what in_atomic() should return
if CONFIG_PREEMPT is turned off. I tested making it return 1 in that
case, but that yielded tons of warnings.
The simpler fix for tlb_uv.c would be to just drop the WARN_ON.
- uv_flush_send_and_wait() should return a pointer if the broadcast
remote tlb shootdown requests fail. That causes the conventional IPI
method of shootdown to be used.
Diffed against 2.6.29-rc2
(Ingo's tree)
Signed-off-by: Cliff Wickman <[email protected]>
---
arch/x86/kernel/tlb_uv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux/arch/x86/kernel/tlb_uv.c
===================================================================
--- linux.orig/arch/x86/kernel/tlb_uv.c
+++ linux/arch/x86/kernel/tlb_uv.c
@@ -259,7 +259,7 @@ const struct cpumask *uv_flush_send_and_
* the cpu's, all of which are still in the mask.
*/
__get_cpu_var(ptcstats).ptc_i++;
- return 0;
+ return flush_mask;
}
/*
@@ -316,7 +316,9 @@ const struct cpumask *uv_flush_tlb_other
int locals = 0;
struct bau_desc *bau_desc;
+#ifdef CONFIG_PREEMPT
WARN_ON(!in_atomic());
+#endif
cpumask_andnot(flush_mask, cpumask, cpumask_of(cpu));
* Cliff Wickman <[email protected]> wrote:
> From: Cliff Wickman <[email protected]>
>
> This patch tweaks a couple things:
>
> - uv_flush_tlb_others()
> the WARN_ON(!in_atomic()); fails if CONFIG_PREEMPT is not enabled
>
> The #ifdef may not be the right fix. The fix is probably in the
> in_atomic macro, but I'm not sure what in_atomic() should return
> if CONFIG_PREEMPT is turned off. I tested making it return 1 in that
> case, but that yielded tons of warnings.
>
> The simpler fix for tlb_uv.c would be to just drop the WARN_ON.
>
> - uv_flush_send_and_wait() should return a pointer if the broadcast
> remote tlb shootdown requests fail. That causes the conventional IPI
> method of shootdown to be used.
hm, this isnt a cleanup but a fix - i.e. needs to go into x86/urgent as a
separate patch, right?
and this:
> @@ -316,7 +316,9 @@ const struct cpumask *uv_flush_tlb_other
> int locals = 0;
> struct bau_desc *bau_desc;
>
> +#ifdef CONFIG_PREEMPT
> WARN_ON(!in_atomic());
> +#endif
is indeed somewhat ugly - and we have no proper primitive to test for
atomicity. (mainly because we dont know about atomicity on a non-preempt
kernel)
Ingo
On Thu, Jan 29, 2009 at 09:35:17PM +0100, Ingo Molnar wrote:
>
> * Cliff Wickman <[email protected]> wrote:
>
> > From: Cliff Wickman <[email protected]>
> >
> > This patch tweaks a couple things:
> >
> > - uv_flush_tlb_others()
> > the WARN_ON(!in_atomic()); fails if CONFIG_PREEMPT is not enabled
> >
> > The #ifdef may not be the right fix. The fix is probably in the
> > in_atomic macro, but I'm not sure what in_atomic() should return
> > if CONFIG_PREEMPT is turned off. I tested making it return 1 in that
> > case, but that yielded tons of warnings.
> >
> > The simpler fix for tlb_uv.c would be to just drop the WARN_ON.
> >
> > - uv_flush_send_and_wait() should return a pointer if the broadcast
> > remote tlb shootdown requests fail. That causes the conventional IPI
> > method of shootdown to be used.
>
> hm, this isnt a cleanup but a fix - i.e. needs to go into x86/urgent as a
> separate patch, right?
Yes, it is a fix. I'll re-post, and send the WARN_ON issue as a
separate patch.
> and this:
>
> > @@ -316,7 +316,9 @@ const struct cpumask *uv_flush_tlb_other
> > int locals = 0;
> > struct bau_desc *bau_desc;
> >
> > +#ifdef CONFIG_PREEMPT
> > WARN_ON(!in_atomic());
> > +#endif
>
> is indeed somewhat ugly - and we have no proper primitive to test for
> atomicity. (mainly because we dont know about atomicity on a non-preempt
> kernel)
>
> Ingo
> --
> 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/
--
Cliff Wickman
Silicon Graphics, Inc.
[email protected]
(651) 683-3824