linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Brian Gerst <brgerst@gmail.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 4/7] x86/vm86: Move vm86 fields out of thread_struct
Date: Tue, 21 Jul 2015 09:11:51 +0200	[thread overview]
Message-ID: <20150721071151.GA8367@gmail.com> (raw)
In-Reply-To: <1437354550-25858-5-git-send-email-brgerst@gmail.com>


* Brian Gerst <brgerst@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;
> +	}
> +#endif

This should be a helper:

	vm86__free(t->vm86)

or so.

> diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
> index e6c2b47..dce0a1c 100644
> --- a/arch/x86/kernel/vm86_32.c
> +++ b/arch/x86/kernel/vm86_32.c

> @@ -242,9 +244,16 @@ static long do_sys_vm86(struct vm86plus_struct __user *v86, bool plus,
>  {
>  	struct tss_struct *tss;
>  	struct task_struct *tsk = current;
> +	struct kernel_vm86_info *vm86 = tsk->thread.vm86;
>  	unsigned long err = 0;
>  
> -	if (tsk->thread.saved_sp0)
> +	if (!vm86)
> +	{

Non-standard style.

> +		if (!(vm86 = kzalloc(sizeof(*vm86), GFP_KERNEL)))
> +			return -ENOMEM;
> +		tsk->thread.vm86 = vm86;
> +	}
> +	if (vm86->saved_sp0)
>  		return -EPERM;


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', sometimes it's 'v86', sometimes 'user'. Ugh.

Other fields have naming inconsistencies as well: for example we have 
thread.vm86->vm86plus.vm86dbg_active. 'vm86' is repeated _three_ times in that 
name, for no good reason.

So please clean up the naming to make this all easier to read. Only the highest 
level field should have 'vm86' in it - all subsequent fields will inherit that 
name one way or another.

At a quick glance I'd do the following renames:

struct kernel_vm86_info *vm86;		=> struct vm86 *vm86;

  - it's obviously 'information' so the _info is superfluous.

  - and it's obviously embedded in a kernel structure, so the kernel_ is 
    superfluous as well.

Then let's look at other fields of the main structure:

struct kernel_vm86_info {
        struct vm86plus_struct __user *vm86_info;
        struct pt_regs regs32;
        unsigned long v86flags;
        unsigned long v86mask;
        unsigned long saved_sp0;

        unsigned long flags;
        unsigned long screen_bitmap;
        unsigned long cpu_type;
        struct revectored_struct int_revectored;
        struct revectored_struct int21_revectored;
        struct vm86plus_info_struct vm86plus;
};

 - Why is there a vm86.flags and a vm86.v86flags field? What's the difference 
   and can we eliminate the confusion factor?

 - The fields flags..vm86plus seems to be an as-is copy of 'struct 
   vm86plus_struct'. Could this be organized in a smarter fashion?.

 - 'struct vm86_regs' appears to be an as-is copy of 32-bit pt_regs, plus:

        unsigned short es, __esh;
        unsigned short ds, __dsh;
        unsigned short fs, __fsh;
        unsigned short gs, __gsh;

    Instead of a slightly different structure copying pt_regs, why not express it 
    as:

    struct vm86_regs {
        struct pt_regs regs;

        unsigned short es, __esh;
        unsigned short ds, __dsh;
        unsigned short fs, __fsh;
        unsigned short gs, __gsh;
    };

    ?

 - There's a number of 'long' fields which are always 32-bit, which is pretty 
   confusing even if it's only ever built on 32-bit kerenls, can we use
   u8/u16/u32/u64 for ABI components instead?

Thanks,

	Ingo

  parent reply	other threads:[~2015-07-21  7:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-20  1:09 [PATCH v3] x86: vm86 cleanups Brian Gerst
2015-07-20  1:09 ` [PATCH 1/7] x86/vm86: Clean up saved_fs/gs Brian Gerst
2015-07-21  9:38   ` [tip:x86/asm] x86/entry/vm86: " tip-bot for Brian Gerst
2015-07-20  1:09 ` [PATCH 2/7] x86/vm86: Preserve orig_ax Brian Gerst
2015-07-21  9:39   ` [tip:x86/asm] x86/entry/vm86: Preserve 'orig_ax' tip-bot for Brian Gerst
2015-07-20  1:09 ` [PATCH 3/7] x86/vm86: Move userspace accesses to do_sys_vm86() Brian Gerst
2015-07-21  9:39   ` [tip:x86/asm] x86/entry/vm86: " tip-bot for Brian Gerst
2015-07-20  1:09 ` [PATCH 4/7] x86/vm86: Move vm86 fields out of thread_struct Brian Gerst
2015-07-21  6:28   ` Ingo Molnar
2015-07-21  6:30     ` Andy Lutomirski
2015-07-21  6:35       ` Ingo Molnar
2015-07-21  6:31     ` Ingo Molnar
2015-07-21  7:11   ` Ingo Molnar [this message]
2015-07-21 15:30     ` Brian Gerst
2015-08-05  8:48       ` Ingo Molnar
2015-08-05  8:53         ` Linus Torvalds
2015-08-23 11:51           ` Ingo Molnar
2015-07-20  1:09 ` [PATCH 5/7] x86/vm86: Move fields from kernel_vm86_struct Brian Gerst
2015-07-20  1:09 ` [PATCH 6/7] x86/vm86: Eliminate kernel_vm86_struct Brian Gerst
2015-07-20  1:09 ` [PATCH 7/7] x86/vm86: Use the normal pt_regs area for vm86 Brian Gerst
  -- strict thread matches above, loose matches on Subject: below --
2015-07-16 11:46 [PATCH v2] x86: vm86 cleanups Brian Gerst
2015-07-16 11:46 ` [PATCH 4/7] x86/vm86: Move vm86 fields out of thread_struct Brian Gerst
2015-07-17 19:01   ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150721071151.GA8367@gmail.com \
    --to=mingo@kernel.org \
    --cc=brgerst@gmail.com \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).