Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1397398 > unrolled thread
| Started by | Yu-cheng Yu <yu-cheng.yu@intel.com> |
|---|---|
| First post | 2016-05-09 23:00 +0200 |
| Last post | 2016-05-10 02:00 +0200 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[PATCH v5 11/13] x86/xsaves: Add WARN_ON_FPU() when a disabled xstate component offset is requested for a compacted format Yu-cheng Yu <yu-cheng.yu@intel.com> - 2016-05-09 23:00 +0200
Re: [PATCH v5 11/13] x86/xsaves: Add WARN_ON_FPU() when a disabled xstate component offset is requested for a compacted format Dave Hansen <dave.hansen@linux.intel.com> - 2016-05-10 01:40 +0200
Re: [PATCH v5 11/13] x86/xsaves: Add WARN_ON_FPU() when a disabled xstate component offset is requested for a compacted format Yu-cheng Yu <yu-cheng.yu@intel.com> - 2016-05-10 01:50 +0200
Re: [PATCH v5 11/13] x86/xsaves: Add WARN_ON_FPU() when a disabled xstate component offset is requested for a compacted format Dave Hansen <dave.hansen@linux.intel.com> - 2016-05-10 02:00 +0200
| From | Yu-cheng Yu <yu-cheng.yu@intel.com> |
|---|---|
| Date | 2016-05-09 23:00 +0200 |
| Subject | [PATCH v5 11/13] x86/xsaves: Add WARN_ON_FPU() when a disabled xstate component offset is requested for a compacted format |
| Message-ID | <rx0rz-4yi-59@gated-at.bofh.it> |
Add a warning in case a disabled (not existing) xstate component offset
is requested.
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
---
arch/x86/kernel/fpu/xstate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 350814c..2e6dbfe 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -756,6 +756,7 @@ void *__raw_xsave_addr(struct xregs_state *xsave, int xstate_feature_mask)
{
int feature_nr = fls64(xstate_feature_mask) - 1;
+ WARN_ON_FPU(using_compacted_format() && !xfeature_enabled(feature_nr));
return (void *)xsave + xstate_comp_offsets[feature_nr];
}
--
1.9.1
[toc] | [next] | [standalone]
| From | Dave Hansen <dave.hansen@linux.intel.com> |
|---|---|
| Date | 2016-05-10 01:40 +0200 |
| Subject | Re: [PATCH v5 11/13] x86/xsaves: Add WARN_ON_FPU() when a disabled xstate component offset is requested for a compacted format |
| Message-ID | <rx2Wm-7n5-1@gated-at.bofh.it> |
| In reply to | #1397398 |
On 05/09/2016 01:46 PM, Yu-cheng Yu wrote:
> Add a warning in case a disabled (not existing) xstate component offset
> is requested.
...
> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> index 350814c..2e6dbfe 100644
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -756,6 +756,7 @@ void *__raw_xsave_addr(struct xregs_state *xsave, int xstate_feature_mask)
> {
> int feature_nr = fls64(xstate_feature_mask) - 1;
>
> + WARN_ON_FPU(using_compacted_format() && !xfeature_enabled(feature_nr));
> return (void *)xsave + xstate_comp_offsets[feature_nr];
> }
Why the using_compacted_format()? Shouldn't this be an error, regardless.
Also, what is xstate_comp_offsets[feature_nr] in this case? Isn't it
-1? Should we be returning NULL along with WARN()ing?
[toc] | [prev] | [next] | [standalone]
| From | Yu-cheng Yu <yu-cheng.yu@intel.com> |
|---|---|
| Date | 2016-05-10 01:50 +0200 |
| Subject | Re: [PATCH v5 11/13] x86/xsaves: Add WARN_ON_FPU() when a disabled xstate component offset is requested for a compacted format |
| Message-ID | <rx362-7sX-19@gated-at.bofh.it> |
| In reply to | #1397507 |
On Mon, May 09, 2016 at 04:31:18PM -0700, Dave Hansen wrote:
> On 05/09/2016 01:46 PM, Yu-cheng Yu wrote:
> > Add a warning in case a disabled (not existing) xstate component offset
> > is requested.
> ...
> > diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> > index 350814c..2e6dbfe 100644
> > --- a/arch/x86/kernel/fpu/xstate.c
> > +++ b/arch/x86/kernel/fpu/xstate.c
> > @@ -756,6 +756,7 @@ void *__raw_xsave_addr(struct xregs_state *xsave, int xstate_feature_mask)
> > {
> > int feature_nr = fls64(xstate_feature_mask) - 1;
> >
> > + WARN_ON_FPU(using_compacted_format() && !xfeature_enabled(feature_nr));
> > return (void *)xsave + xstate_comp_offsets[feature_nr];
> > }
>
> Why the using_compacted_format()? Shouldn't this be an error, regardless.
If the kernel is not using compacted format, I can get a component offset, no?
>
> Also, what is xstate_comp_offsets[feature_nr] in this case? Isn't it
> -1? Should we be returning NULL along with WARN()ing?
NULL makes sense. I will change it.
[toc] | [prev] | [next] | [standalone]
| From | Dave Hansen <dave.hansen@linux.intel.com> |
|---|---|
| Date | 2016-05-10 02:00 +0200 |
| Subject | Re: [PATCH v5 11/13] x86/xsaves: Add WARN_ON_FPU() when a disabled xstate component offset is requested for a compacted format |
| Message-ID | <rx3fJ-7Ae-17@gated-at.bofh.it> |
| In reply to | #1397517 |
On 05/09/2016 04:44 PM, Yu-cheng Yu wrote:
> On Mon, May 09, 2016 at 04:31:18PM -0700, Dave Hansen wrote:
>> On 05/09/2016 01:46 PM, Yu-cheng Yu wrote:
>>> Add a warning in case a disabled (not existing) xstate component offset
>>> is requested.
>> ...
>>> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
>>> index 350814c..2e6dbfe 100644
>>> --- a/arch/x86/kernel/fpu/xstate.c
>>> +++ b/arch/x86/kernel/fpu/xstate.c
>>> @@ -756,6 +756,7 @@ void *__raw_xsave_addr(struct xregs_state *xsave, int xstate_feature_mask)
>>> {
>>> int feature_nr = fls64(xstate_feature_mask) - 1;
>>>
>>> + WARN_ON_FPU(using_compacted_format() && !xfeature_enabled(feature_nr));
>>> return (void *)xsave + xstate_comp_offsets[feature_nr];
>>> }
>>
>> Why the using_compacted_format()? Shouldn't this be an error, regardless.
>
> If the kernel is not using compacted format, I can get a component offset, no?
You can get it, but why would you? Let's say you were trying to get the
MPX contents. You'd either be guaranteed to be getting 0's or
uninitialized garbage (if we didn't zero it carefully).
The garbage could be kernel data (if we didn't zero carefully). So it
just seems dangerous to allow this for no apparent benefit.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web