From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S267628AbUHWWXJ (ORCPT ); Mon, 23 Aug 2004 18:23:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267293AbUHWWTv (ORCPT ); Mon, 23 Aug 2004 18:19:51 -0400 Received: from x35.xmailserver.org ([69.30.125.51]:5519 "EHLO x35.xmailserver.org") by vger.kernel.org with ESMTP id S267628AbUHWWSi (ORCPT ); Mon, 23 Aug 2004 18:18:38 -0400 X-AuthUser: davidel@xmailserver.org Date: Mon, 23 Aug 2004 15:18:27 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@bigblue.dev.mdolabs.com To: Linus Torvalds cc: Andi Kleen , Linux Kernel Mailing List , Andrew Morton Subject: Re: [patch] lazy TSS's I/O bitmap copy ... In-Reply-To: Message-ID: References: <20040823233249.09e93b86.ak@suse.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 23 Aug 2004, Linus Torvalds wrote: > On Mon, 23 Aug 2004, Davide Libenzi wrote: > > > > The eventually double GPF would happen only on TSS-IObmp-lazy tasks, ie > > tasks using the I/O bitmap. > > You could also check for the error code (at least the low 16 bits) being > 0, I guess, just to cut down the noise. Yep, that's right there available. > > The check for the I/O opcode can certainly be > > done though, even if it'd make the code a little bit more complex. > > Have to be very careful there to avoid nasty security issues. And with > ins/outs, you can have various prefixes etc, so decoding is not as trivial > as it could otherwise be. Even the regular in/out can have a data size > overrides.. > > in/out is also commonly used from vm86 mode, so decoding it really needs > to get all of the segmentation base crap right too. Nasty nasty nasty. > > In short, I think that if we do this at all, I'd much rather just do the > simple "trap twice" thing that Davide did. It's too easy to get it wrong > otherwise. IMHO since the GPF path is not a fast path like a page fault, we shouldn't be in bad shape with the current approach. No? - Davide