Re: [patch] lazy TSS's I/O bitmap copy ...

Davide Libenzi
2004-08-23T21:54:32Z

On Mon, 23 Aug 2004, Andi Kleen wrote:

> On Mon, 23 Aug 2004 14:23:35 -0700 (PDT)
> Davide Libenzi <davidel@xmailserver.org> wrote:
>
> >
> > The following patch implements a lazy I/O bitmap copy for the i386
> > architecture. With I/O bitmaps now reaching considerable sizes, if the
> > switched task does not perform any I/O operation, we can save the copy
> > altogether. In my box X is working fine with the following patch, even if
> > more test would be required.
>
> IMHO this needs benchmarks first to prove that the additional
> exception doesn't cause too much slow down.

Yes, of course.

> > asmlinkage void do_general_protection(struct pt_regs * regs, long error_code)
> > {
> > + int cpu = smp_processor_id();
> > + struct tss_struct *tss = init_tss + cpu;
> > + struct task_struct *tsk = current;
> > + struct thread_struct *tsk_th = &tsk->thread;
> > +
> > + /*
> > + * Perform the lazy TSS's I/O bitmap copy. If the TSS has an
> > + * invalid offset set (the LAZY one) and the faulting thread has
> > + * a valid I/O bitmap pointer, we copy the I/O bitmap in the TSS
> > + * and we set the offset field correctly. Then we let the CPU to
> > + * restart the faulting instruction.
> > + */
>
> I don't like it very much that most GPFs will be executed twice now
> when the process has ioperm enabled.
> This will confuse debuggers and could have other bad side effects.
> Checking the EIP would be better.

The eventually double GPF would happen only on TSS-IObmp-lazy tasks, ie
tasks using the I/O bitmap. The check for the I/O opcode can certainly be
done though, even if it'd make the code a little bit more complex.

- Davide