* Linus Torvalds wrote:
> On Wed, Aug 5, 2015 at 10:48 AM, Ingo Molnar wrote:
> >>
> >> Some of these field names are visible to userspace and can't change.
> >
> > That's a misconception: bits in the uapi headers can be renamed just fine.
>
> I disagree. If it causes pain for user space, we
* Linus Torvalds torva...@linux-foundation.org wrote:
On Wed, Aug 5, 2015 at 10:48 AM, Ingo Molnar mi...@kernel.org wrote:
Some of these field names are visible to userspace and can't change.
That's a misconception: bits in the uapi headers can be renamed just fine.
I disagree. If it
On Wed, Aug 5, 2015 at 10:48 AM, Ingo Molnar wrote:
>>
>> Some of these field names are visible to userspace and can't change.
>
> That's a misconception: bits in the uapi headers can be renamed just fine.
I disagree. If it causes pain for user space, we just shouldn't do it.
Some people copy
* Brian Gerst wrote:
> > Btw., the variable names here are crazy. I had to look twice to realize
> > that
> > we have 'v86' and 'vm86' which are two different things.
> >
> > Also, vm86plus_struct variables and fields are named wildly inconsistently:
> > sometimes it's 'vm86.vm86_info',
* Brian Gerst brge...@gmail.com wrote:
Btw., the variable names here are crazy. I had to look twice to realize
that
we have 'v86' and 'vm86' which are two different things.
Also, vm86plus_struct variables and fields are named wildly inconsistently:
sometimes it's 'vm86.vm86_info',
On Wed, Aug 5, 2015 at 10:48 AM, Ingo Molnar mi...@kernel.org wrote:
Some of these field names are visible to userspace and can't change.
That's a misconception: bits in the uapi headers can be renamed just fine.
I disagree. If it causes pain for user space, we just shouldn't do it.
Some
On Tue, Jul 21, 2015 at 3:11 AM, Ingo Molnar wrote:
>
> * Brian Gerst wrote:
>
>> --- a/arch/x86/kernel/process.c
>> +++ b/arch/x86/kernel/process.c
>> @@ -110,6 +110,13 @@ void exit_thread(void)
>> kfree(bp);
>> }
>>
>> +#ifdef CONFIG_VM86
>> + if (t->vm86) {
>> +
* Brian Gerst wrote:
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -110,6 +110,13 @@ void exit_thread(void)
> kfree(bp);
> }
>
> +#ifdef CONFIG_VM86
> + if (t->vm86) {
> + kfree(t->vm86);
> + t->vm86 = NULL;
> + }
* Andy Lutomirski wrote:
> On Mon, Jul 20, 2015 at 11:28 PM, Ingo Molnar wrote:
> >
> > * Brian Gerst wrote:
> >
> >> Allocate a separate structure for the vm86 fields.
> >
> > Why is this allocated dynamically? This structure is not very large, and a
> > hole in thread_struct isn't that big
* Ingo Molnar wrote:
> * Brian Gerst wrote:
>
> > Allocate a separate structure for the vm86 fields.
>
> Why is this allocated dynamically? This structure is not very large, and a
> hole
> in thread_struct isn't that big of an issue - compared to additional
> fragility
> introduced by
On Mon, Jul 20, 2015 at 11:28 PM, Ingo Molnar wrote:
>
> * Brian Gerst wrote:
>
>> Allocate a separate structure for the vm86 fields.
>
> Why is this allocated dynamically? This structure is not very large, and a
> hole in
> thread_struct isn't that big of an issue - compared to additional
* Brian Gerst wrote:
> Allocate a separate structure for the vm86 fields.
Why is this allocated dynamically? This structure is not very large, and a hole
in
thread_struct isn't that big of an issue - compared to additional fragility
introduced by the (mostly untested by normal apps) dynamic
On Tue, Jul 21, 2015 at 3:11 AM, Ingo Molnar mi...@kernel.org wrote:
* Brian Gerst brge...@gmail.com wrote:
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -110,6 +110,13 @@ void exit_thread(void)
kfree(bp);
}
+#ifdef CONFIG_VM86
+ if (t-vm86)
* Brian Gerst brge...@gmail.com wrote:
Allocate a separate structure for the vm86 fields.
Why is this allocated dynamically? This structure is not very large, and a hole
in
thread_struct isn't that big of an issue - compared to additional fragility
introduced by the (mostly untested by
* Andy Lutomirski l...@amacapital.net wrote:
On Mon, Jul 20, 2015 at 11:28 PM, Ingo Molnar mi...@kernel.org wrote:
* Brian Gerst brge...@gmail.com wrote:
Allocate a separate structure for the vm86 fields.
Why is this allocated dynamically? This structure is not very large, and a
* Ingo Molnar mi...@kernel.org wrote:
* Brian Gerst brge...@gmail.com wrote:
Allocate a separate structure for the vm86 fields.
Why is this allocated dynamically? This structure is not very large, and a
hole
in thread_struct isn't that big of an issue - compared to additional
* Brian Gerst brge...@gmail.com wrote:
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -110,6 +110,13 @@ void exit_thread(void)
kfree(bp);
}
+#ifdef CONFIG_VM86
+ if (t-vm86) {
+ kfree(t-vm86);
+ t-vm86 = NULL;
+
On Mon, Jul 20, 2015 at 11:28 PM, Ingo Molnar mi...@kernel.org wrote:
* Brian Gerst brge...@gmail.com wrote:
Allocate a separate structure for the vm86 fields.
Why is this allocated dynamically? This structure is not very large, and a
hole in
thread_struct isn't that big of an issue -
Allocate a separate structure for the vm86 fields.
Signed-off-by: Brian Gerst
---
arch/x86/include/asm/processor.h | 9 ++--
arch/x86/include/asm/vm86.h | 8 +++
arch/x86/kernel/process.c| 7 ++
arch/x86/kernel/vm86_32.c| 47
Allocate a separate structure for the vm86 fields.
Signed-off-by: Brian Gerst brge...@gmail.com
---
arch/x86/include/asm/processor.h | 9 ++--
arch/x86/include/asm/vm86.h | 8 +++
arch/x86/kernel/process.c| 7 ++
arch/x86/kernel/vm86_32.c| 47
On Thu, Jul 16, 2015 at 4:46 AM, Brian Gerst wrote:
> Allocate a separate structure for the vm86 fields.
>
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -315,12 +315,12 @@ check_v8086_mode(struct pt_regs *regs, unsigned long
> address,
> {
> unsigned long bit;
>
> -
On Thu, Jul 16, 2015 at 4:46 AM, Brian Gerst brge...@gmail.com wrote:
Allocate a separate structure for the vm86 fields.
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -315,12 +315,12 @@ check_v8086_mode(struct pt_regs *regs, unsigned long
address,
{
unsigned long bit;
Allocate a separate structure for the vm86 fields.
Signed-off-by: Brian Gerst
---
arch/x86/include/asm/processor.h | 12 ++
arch/x86/include/asm/vm86.h | 11 +
arch/x86/kernel/process.c| 7 ++
arch/x86/kernel/vm86_32.c| 51
Allocate a separate structure for the vm86 fields.
Signed-off-by: Brian Gerst brge...@gmail.com
---
arch/x86/include/asm/processor.h | 12 ++
arch/x86/include/asm/vm86.h | 11 +
arch/x86/kernel/process.c| 7 ++
arch/x86/kernel/vm86_32.c| 51
24 matches
Mail list logo
