* The msr_safe functions and returning -EFAULT
@ 2009-08-30 21:05 H. Peter Anvin
2009-09-01 0:24 ` Jeremy Fitzhardinge
0 siblings, 1 reply; 3+ messages in thread
From: H. Peter Anvin @ 2009-08-30 21:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Ingo Molnar, Thomas Gleixner, Jeremy Fitzhardinge, Avi Kivity
Right now, the *msr_safe() functions are returning -EFAULT. As far as I
can tell, this makes absolutely no sense -- EFAULT is a nonsensical
error (it means a pointer into user memory given to a system call is
invalid), and the only user that seems to use this as anything other
than a boolean is the MSR driver, which wants EIO.
Sending out an email in case I have missed any instances, but I'm
inclined to just change this to EIO globally.
Anyone has objections?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: The msr_safe functions and returning -EFAULT
2009-08-30 21:05 The msr_safe functions and returning -EFAULT H. Peter Anvin
@ 2009-09-01 0:24 ` Jeremy Fitzhardinge
2009-09-01 0:27 ` H. Peter Anvin
0 siblings, 1 reply; 3+ messages in thread
From: Jeremy Fitzhardinge @ 2009-09-01 0:24 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linux Kernel Mailing List, Ingo Molnar, Thomas Gleixner,
Jeremy Fitzhardinge, Avi Kivity
On 08/30/09 14:05, H. Peter Anvin wrote:
> Right now, the *msr_safe() functions are returning -EFAULT. As far as I
> can tell, this makes absolutely no sense -- EFAULT is a nonsensical
> error (it means a pointer into user memory given to a system call is
> invalid), and the only user that seems to use this as anything other
> than a boolean is the MSR driver, which wants EIO.
>
> Sending out an email in case I have missed any instances, but I'm
> inclined to just change this to EIO globally.
>
> Anyone has objections?
>
I think the only rationale for EFAULT is that the *msr will fail with
GP, and a GPing instruction will send a SIGSEGV to usermode, and EFAULT
is the synchronous error-code equiv of SIGSEGV. Sorta.
EIO makes more sense overall. Or ENXIO.
J
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: The msr_safe functions and returning -EFAULT
2009-09-01 0:24 ` Jeremy Fitzhardinge
@ 2009-09-01 0:27 ` H. Peter Anvin
0 siblings, 0 replies; 3+ messages in thread
From: H. Peter Anvin @ 2009-09-01 0:27 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: Linux Kernel Mailing List, Ingo Molnar, Thomas Gleixner,
Jeremy Fitzhardinge, Avi Kivity
On 08/31/2009 05:24 PM, Jeremy Fitzhardinge wrote:
> On 08/30/09 14:05, H. Peter Anvin wrote:
>> Right now, the *msr_safe() functions are returning -EFAULT. As far as I
>> can tell, this makes absolutely no sense -- EFAULT is a nonsensical
>> error (it means a pointer into user memory given to a system call is
>> invalid), and the only user that seems to use this as anything other
>> than a boolean is the MSR driver, which wants EIO.
>>
>> Sending out an email in case I have missed any instances, but I'm
>> inclined to just change this to EIO globally.
>>
>> Anyone has objections?
>>
>
> I think the only rationale for EFAULT is that the *msr will fail with
> GP, and a GPing instruction will send a SIGSEGV to usermode, and EFAULT
> is the synchronous error-code equiv of SIGSEGV. Sorta.
>
> EIO makes more sense overall. Or ENXIO.
Well, EIO is what we want for the MSR driver, so I have just switched it
to EIO across the board. As far as I can tell, there were no other
users that didn't just test for error or no error.
-hpa
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-09-01 0:28 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-30 21:05 The msr_safe functions and returning -EFAULT H. Peter Anvin
2009-09-01 0:24 ` Jeremy Fitzhardinge
2009-09-01 0:27 ` H. Peter Anvin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox