From owner-freebsd-current@FreeBSD.ORG Sun May 21 23:51:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72FB316A586; Sun, 21 May 2006 23:51:53 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E523543D45; Sun, 21 May 2006 23:51:50 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.4.20060308/8.13.4) with ESMTP id k4LNpmel095333; Sun, 21 May 2006 16:51:48 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.4.20060308/8.13.4/Submit) id k4LNpmhJ095330; Sun, 21 May 2006 16:51:48 -0700 (PDT) Date: Sun, 21 May 2006 16:51:48 -0700 (PDT) From: Matthew Dillon Message-Id: <200605212351.k4LNpmhJ095330@apollo.backplane.com> To: David Xu References: <20060430142408.fcd60069.rosti.bsd@gmail.com> <20060519210105.d4418b6f.rosti.bsd@gmail.com> <20060520012653.41cf7366.rosti.bsd@gmail.com> <200605211606.43381.davidxu@freebsd.org> Cc: Rostislav Krasny , Igor Sysoev , Colin Percival , freebsd-current@freebsd.org Subject: Re: [PATCH] FreeBSD-SA-06:14.fpu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2006 23:51:55 -0000 :> :> By the way, following command could be used to check how kernel has :> been compiled, regarding the CPU_FXSAVE_LEAK option: :> :> objdump -x /boot/kernel/kernel | grep fpu_clean_state : :The patch looks fine to me, but can it be CPU_FXSAVE_NOLEAK ? :so only people know the problem will turn it on. : :David Xu I don't think it really needs to be optioned. Since the FPU state is demand-loaded from a trap/exception anyway, a huge amount of code is run in the same path that fpu_clean_state is called from. fpu_clean_state itself only eats a few nanoseconds (like maybe ~1/10 of the time that fninit takes). -Matt