Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1179864 > unrolled thread

Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN

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.

Contents

  Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN Thomas Gleixner <tglx@linutronix.de> - 2015-07-08 16:10 +0200
    Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN Ingo Molnar <mingo@kernel.org> - 2015-07-08 16:10 +0200
    Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN Pavel Machek <pavel@ucw.cz> - 2015-07-09 11:10 +0200

#1179864 — Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN

On Tue, 7 Jul 2015, Arjan van de Ven wrote:

> On 7/7/2015 6:25 PM, Andy Lutomirski wrote:
> > VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is
> > in use.  The code is a big undocumented mess, it's a real PITA to
> > test, and it looks like a big chunk of vm86_32.c is dead code.  It
> > also plays awful games with the entry asm.
> > 
> > No one should be using it anyway.  Use DOSBOX or KVM instead.
> > 
> > Mark it BROKEN.  I want to remove some (obviously incorrect) exit
> > asm that it depends on, and I don't want to figure out how to run
> > severely obsolete programs just to test something that no one uses
> > for anything other than exploits anyway.
> > 
> 
> while it is never great to deprecate features, in this case I am not sure
> there is another choice unless someone steps up to seriously revamp this code.
> (and look at it from a PREEMPT, NO_HZ etc etc angle)

Aside of being broken in so many aspects it's even more obsolete than
386 support, we should just remove it right away.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1179865

* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Tue, 7 Jul 2015, Arjan van de Ven wrote:
> 
> > On 7/7/2015 6:25 PM, Andy Lutomirski wrote:
> > > VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is
> > > in use.  The code is a big undocumented mess, it's a real PITA to
> > > test, and it looks like a big chunk of vm86_32.c is dead code.  It
> > > also plays awful games with the entry asm.
> > > 
> > > No one should be using it anyway.  Use DOSBOX or KVM instead.
> > > 
> > > Mark it BROKEN.  I want to remove some (obviously incorrect) exit
> > > asm that it depends on, and I don't want to figure out how to run
> > > severely obsolete programs just to test something that no one uses
> > > for anything other than exploits anyway.
> > > 
> > 
> > while it is never great to deprecate features, in this case I am not sure
> > there is another choice unless someone steps up to seriously revamp this code.
> > (and look at it from a PREEMPT, NO_HZ etc etc angle)
> 
> Aside of being broken in so many aspects it's even more obsolete than
> 386 support, we should just remove it right away.

Yes - marking is BROKEN essentially makes it impossible to build it without 
changing the kernel source, so the next patch(es) could remove it.

But the 'marking BROKEN' patch will be much easier to backport, so I'd like to 
keep it separate.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1180575

On Wed 2015-07-08 16:00:48, Thomas Gleixner wrote:
> On Tue, 7 Jul 2015, Arjan van de Ven wrote:
> 
> > On 7/7/2015 6:25 PM, Andy Lutomirski wrote:
> > > VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is
> > > in use.  The code is a big undocumented mess, it's a real PITA to
> > > test, and it looks like a big chunk of vm86_32.c is dead code.  It
> > > also plays awful games with the entry asm.
> > > 
> > > No one should be using it anyway.  Use DOSBOX or KVM instead.
> > > 
> > > Mark it BROKEN.  I want to remove some (obviously incorrect) exit
> > > asm that it depends on, and I don't want to figure out how to run
> > > severely obsolete programs just to test something that no one uses
> > > for anything other than exploits anyway.
> > > 
> > 
> > while it is never great to deprecate features, in this case I am not sure
> > there is another choice unless someone steps up to seriously revamp this code.
> > (and look at it from a PREEMPT, NO_HZ etc etc angle)
> 
> Aside of being broken in so many aspects it's even more obsolete than
> 386 support, we should just remove it right away.

Bad news for you:

vbetool-0.5/lrmi.c:#include <asm/vm86.h>
vbetool-0.5/lrmi.c:#include <sys/vm86.h>
vbetool-0.5/lrmi.c:#include <machine/vm86.h>
vbetool-0.5/lrmi.c:	    struct vm86_struct vm;
vbetool-0.5/lrmi.c:	    	   struct vm86_init_args init;
...
vbetool-0.5/lrmi.c:lrmi_vm86(struct vm86_struct *vm)
vbetool-0.5/lrmi.c:#define lrmi_vm86 vm86
vbetool-0.5/lrmi.c:	   fputs("vm86() failed\n", stderr);
vbetool-0.5/lrmi.c:run_vm86(void)
vbetool-0.5/lrmi.c:		vret = lrmi_vm86(&context.vm);
vbetool-0.5/lrmi.c:vm86_callback(int sig, int code, struct sigcontext
*sc)
vbetool-0.5/lrmi.c:vm86_callback(int sig, int code, struct sigcontext
*sc)
vbetool-0.5/lrmi.c:run_vm86(void)
vbetool-0.5/lrmi.c:		fprintf(stderr, "run_vm86: callback
already installed\n");

vbetool depends on it, and s2ram depends on vbetool. When we get
proper kernel drivers, this one will be solved, but it is not "more
obsolete than 386".

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web