* 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 j
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 the
* 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', somet
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 the
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 fragi
* 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
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 ---
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;
>
> -
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 +++
12 matches
Mail list logo