public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* idt change in a running kernel? what locking?
@ 2003-10-03  5:52 Catalin BOIE
  2003-10-03  6:34 ` Jamie Lokier
  0 siblings, 1 reply; 7+ messages in thread
From: Catalin BOIE @ 2003-10-03  5:52 UTC (permalink / raw)
  To: linux-kernel

Hi!

What may happen if I modify idt on a running kernel?
It's lock_kernel enough?

Of course that the new location contain a valid idt table.

Thank you very much!

---
Catalin(ux) BOIE
catab@deuroconsult.ro

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: idt change in a running kernel? what locking?
  2003-10-03  5:52 idt change in a running kernel? what locking? Catalin BOIE
@ 2003-10-03  6:34 ` Jamie Lokier
  2003-10-03  6:52   ` Catalin BOIE
  0 siblings, 1 reply; 7+ messages in thread
From: Jamie Lokier @ 2003-10-03  6:34 UTC (permalink / raw)
  To: Catalin BOIE; +Cc: linux-kernel

Catalin BOIE wrote:
> What may happen if I modify idt on a running kernel?
> It's lock_kernel enough?

lock_kernel won't help at all.  It doesn't disable interrupts.

It's more likely, you want to use get_cpu()/put_cpu() to prevent the
current kernel thread from being pre-empted to a different CPU.

> Of course that the new location contain a valid idt table.

If the new table has the same entries as the old one for all
interrupts which are enabled it should be fine.  "lidt" is an atomic
operation with respect to interrupts.

If you are intending to change idt on all CPUs, you'll need something
more complicated.

-- Jamie

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: idt change in a running kernel? what locking?
  2003-10-03  6:34 ` Jamie Lokier
@ 2003-10-03  6:52   ` Catalin BOIE
  2003-10-03 17:02     ` Jamie Lokier
  0 siblings, 1 reply; 7+ messages in thread
From: Catalin BOIE @ 2003-10-03  6:52 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: linux-kernel

On Fri, 3 Oct 2003, Jamie Lokier wrote:

> Catalin BOIE wrote:
> > What may happen if I modify idt on a running kernel?
> > It's lock_kernel enough?
>
> lock_kernel won't help at all.  It doesn't disable interrupts.
>
> It's more likely, you want to use get_cpu()/put_cpu() to prevent the
> current kernel thread from being pre-empted to a different CPU.
get_cpu locks the thread on a CPU until put_cpu?

> > Of course that the new location contain a valid idt table.
>
> If the new table has the same entries as the old one for all
> interrupts which are enabled it should be fine.  "lidt" is an atomic
> operation with respect to interrupts.
Great.

> If you are intending to change idt on all CPUs, you'll need something
> more complicated.

Hm. I realized that on a SMP it's a little hard to do it.
How can I change that on all cpus?
There is something to use that i can force my code to run on a specific
cpu?

>
> -- Jamie

Thank you very much, Jamie!

---
Catalin(ux) BOIE
catab@deuroconsult.ro

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: idt change in a running kernel? what locking?
  2003-10-03  6:52   ` Catalin BOIE
@ 2003-10-03 17:02     ` Jamie Lokier
  2003-10-06  5:12       ` Catalin BOIE
  0 siblings, 1 reply; 7+ messages in thread
From: Jamie Lokier @ 2003-10-03 17:02 UTC (permalink / raw)
  To: Catalin BOIE; +Cc: linux-kernel

Catalin BOIE wrote:
> > It's more likely, you want to use get_cpu()/put_cpu() to prevent the
> > current kernel thread from being pre-empted to a different CPU.
> get_cpu locks the thread on a CPU until put_cpu?

Yes, it disables preemption.
Taking any spinlock will do it too.

> > If you are intending to change idt on all CPUs, you'll need something
> > more complicated.
> 
> Hm. I realized that on a SMP it's a little hard to do it.
> How can I change that on all cpus?
> There is something to use that i can force my code to run on a specific
> cpu?

on_each_cpu() will call a function on each CPU.  Be careful that the
function is safe in the contexts in which it will be called.

If you just want to force you code to run on one cpu, that is
automatic if you are holding a spinlock (but then you can't schedule,
return to userspace etc.)

In general you can fix a task to a cpu using set_cpus_allowed().

-- Jamie

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: idt change in a running kernel? what locking?
  2003-10-03 17:02     ` Jamie Lokier
@ 2003-10-06  5:12       ` Catalin BOIE
  2003-10-06 17:07         ` Jamie Lokier
  0 siblings, 1 reply; 7+ messages in thread
From: Catalin BOIE @ 2003-10-06  5:12 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: linux-kernel

Thanks again!

On Fri, 3 Oct 2003, Jamie Lokier wrote:

> Catalin BOIE wrote:
> > > It's more likely, you want to use get_cpu()/put_cpu() to prevent the
> > > current kernel thread from being pre-empted to a different CPU.
> > get_cpu locks the thread on a CPU until put_cpu?
>

> Yes, it disables preemption.
> Taking any spinlock will do it too.
>
> > > If you are intending to change idt on all CPUs, you'll need something
> > > more complicated.
> >
> > Hm. I realized that on a SMP it's a little hard to do it.
> > How can I change that on all cpus?
> > There is something to use that i can force my code to run on a specific
> > cpu?
>
> on_each_cpu() will call a function on each CPU.  Be careful that the
> function is safe in the contexts in which it will be called.
>
> If you just want to force you code to run on one cpu, that is
> automatic if you are holding a spinlock (but then you can't schedule,
> return to userspace etc.)
>
> In general you can fix a task to a cpu using set_cpus_allowed().
>
> -- Jamie
>

What I realy want is to reload idt on every cpu.
So, probably on_each_cpu is the way to go, right?

---
Catalin(ux) BOIE
catab@deuroconsult.ro

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: idt change in a running kernel? what locking?
  2003-10-06  5:12       ` Catalin BOIE
@ 2003-10-06 17:07         ` Jamie Lokier
  2003-10-07  4:35           ` Catalin BOIE
  0 siblings, 1 reply; 7+ messages in thread
From: Jamie Lokier @ 2003-10-06 17:07 UTC (permalink / raw)
  To: Catalin BOIE; +Cc: linux-kernel

Catalin BOIE wrote:
> What I realy want is to reload idt on every cpu.
> So, probably on_each_cpu is the way to go, right?

Yes.  If you also want to synchronise the changes, so that all CPUs
appear to change idt at the same instant, you'll need some extra
locking.

-- Jamie

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: idt change in a running kernel? what locking?
  2003-10-06 17:07         ` Jamie Lokier
@ 2003-10-07  4:35           ` Catalin BOIE
  0 siblings, 0 replies; 7+ messages in thread
From: Catalin BOIE @ 2003-10-07  4:35 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: linux-kernel

On Mon, 6 Oct 2003, Jamie Lokier wrote:

> Catalin BOIE wrote:
> > What I realy want is to reload idt on every cpu.
> > So, probably on_each_cpu is the way to go, right?
>
> Yes.  If you also want to synchronise the changes, so that all CPUs
> appear to change idt at the same instant, you'll need some extra
> locking.
>
> -- Jamie

Thanks!

---
Catalin(ux) BOIE
catab@deuroconsult.ro

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2003-10-07  4:37 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-10-03  5:52 idt change in a running kernel? what locking? Catalin BOIE
2003-10-03  6:34 ` Jamie Lokier
2003-10-03  6:52   ` Catalin BOIE
2003-10-03 17:02     ` Jamie Lokier
2003-10-06  5:12       ` Catalin BOIE
2003-10-06 17:07         ` Jamie Lokier
2003-10-07  4:35           ` Catalin BOIE

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox