From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 15 16:11:10 2009 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D08A61065670; Tue, 15 Dec 2009 16:11:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 656F88FC0A; Tue, 15 Dec 2009 16:11:10 +0000 (UTC) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id nBFEZBFl030486; Wed, 16 Dec 2009 01:35:11 +1100 Received: from c220-239-235-116.carlnfd3.nsw.optusnet.com.au (c220-239-235-116.carlnfd3.nsw.optusnet.com.au [220.239.235.116]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id nBFEZ75Q008119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 01:35:09 +1100 Date: Wed, 16 Dec 2009 01:35:07 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: linimon@FreeBSD.org In-Reply-To: <200912150035.nBF0ZsLi088804@freefall.freebsd.org> Message-ID: <20091216005926.T34815@delplex.bde.org> References: <200912150035.nBF0ZsLi088804@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-bugs@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: amd64/135014: [padlock] Using padlock(4) in 8-current triggers "fpudna in kernel mode!" warnings X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 16:11:10 -0000 [This probably won't make it into the followup, since gnats still doesn't generate useful followup addresses and I didn't tyy to edit the headers.] > Synopsis: [padlock] Using padlock(4) in 8-current triggers "fpudna in kernel mode!" warnings > By request of Michael Moll in followup, reclassify this as an amd64 > bug. His theory is that the floating-point registers may not be being > handled correctly in the kernel. This seems to be a bug in padlock(4). Apparently the inline asm that it uses requires the FPU. But use of the FPU in the kernel is not supported. (except the obsolete i586 copy optimizations). This bug doesn't seem to be amd64-specific. The bug was smaller on amd64 than on i386. i386 didn't even print a warning when the unsupported use is detected. emaste@ fixed this recently. He just added the printf, to help debug the problem. The printf should always have been a panic, but changing to a panic now would be too drastic. Various hacks are possible for using the FPU in the kernel. Here the use seems to be in a kernel thread (g_eli[n]?). Since all threads are heavyweight, they get a private virtualized copy of the FPU as part of their weight, and since they don't make syscalls, and since normal interrupt handlers are also heavyweight threads and "fast" interrupt handlers hopefully aren't so broken as to use the FPU, this copy hopefully doesn't get corrupted by them (kthreads) running in a separate kernel context, so ignoring the bug happens to give the correct behaviour. Even for user threads making syscalls, ignoring the bug would mostly give correct behaviour, since in normal ABIs syscalls are a sort of sequence point at which the FPU is mostly unused -- only changes to the FPU environment while in kernel context would corrupt the in-use part. So an fairly easy fix for the case in this PR might be for kthreads that use the FPU to tell the kernel that they really mean to use it and/or guarantee safe use, so that this use can be distinguished from accidental possibly-unsafe use. Bruce