amd64/135014: [padlock] Using padlock(4) in 8-current triggers "fpudna in kernel mode!" warnings

[Mark Linimon]

The following reply was made to PR amd64/135014; it has been noted by GNATS.

From: Mark Linimon <linimon at lonesome.com>
To: bug-followup at FreeBSD.org
Cc:  
Subject: Re: amd64/135014: [padlock] Using padlock(4) in 8-current triggers
	"fpudna in kernel mode!" warnings
Date: Sun, 27 Dec 2009 13:57:52 -0600

 From: Bruce Evans <brde at optusnet.com.au>
 To: linimon at FreeBSD.org
 cc: freebsd-bugs at FreeBSD.org, freebsd-amd64 at FreeBSD.org
 Subject: Re: amd64/135014: [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