public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Luca Barbieri <ldb@ldb.ods.org>
To: Pavel Machek <pavel@suse.cz>
Cc: Linux-Kernel ML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [PATCH 1 / ...] i386 dynamic fixup/self modifying code
Date: 30 Aug 2002 00:57:35 +0200	[thread overview]
Message-ID: <1030661855.1490.98.camel@ldb> (raw)
In-Reply-To: <20020828121129.A35@toy.ucw.cz>

[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]

> > This patch implements a system that modifies the kernel code at runtime
> > depending on CPU features and SMPness.
> 
> Nice!
> > This patch requires the is_smp() patch I posted earlier and also
> > requires the new CPU selection code and the code that actually uses
> > both.
> > This code already exists, but needs a few adjustments so it may not
> > arrive immediately.
> > 
> > The code is invoked in the following ways:
> >         * Undefined exception handler: this is used to replace
> >           unsupported instructions with supported ones. Used for invlpg
> >           -> flushall, prefetchnta -> prefetch -> nop, *fence -> lock
> >           addl 0, (%esp), movntq -> movq
> >         * Int3 handler: this is used when a 1 byte opcode is desired.
> >           This is controlled by a config option so that debuggers and
> >           kprobe won't break. Used for lock/nop and APIC write
> 
> Why not do *everything* using int3 handler? It should simplify your code.
Because kdb, kgdb and kprobe want to use int3 so it must be used only if
the config option is enabled.

> Hooking on 'unknown instruction' should not be really neccessary if you
> replace all invlpgs (etc) with 0xcc...
It's better: first, if it is supported we have no faults.
Second, in some cases (e.g. movntq) it's not possible without adding
extra padding when using int xx (and int3 can't be used for the reason
above).

> > Unfortunately with this patch executing invalid code will cause the
> > processor to enter an infinite exception loop rather than panic. Fixing
> > this is not trivial for SMP+preempt so it's not done at the moment.
> 
> Using 0xcc for everything should fix that, right?
Not possible. See above.

This could be fixed by checking whether the opcode is not one generated
or recognized by the dynamic fixup code, assuming that nothing else can
change the code.
However, this fails to detect "impossible" cases like cpus that should
understand prefetches but that don't.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2002-08-29 22:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-28  3:41 [PATCH 1 / ...] i386 dynamic fixup/self modifying code Luca Barbieri
2002-08-28 12:11 ` Pavel Machek
2002-08-29 22:57   ` Luca Barbieri [this message]
2002-08-29 23:19   ` Alan Cox
2002-08-29 23:22     ` Pavel Machek
2002-08-30  0:05       ` David S. Miller
2002-08-30  0:21         ` Luca Barbieri
2002-08-29 23:29     ` Luca Barbieri
2002-08-29 23:32       ` Alan Cox
2002-08-30  0:10         ` Luca Barbieri
2002-08-30 11:17           ` Alan Cox
2002-09-03 21:31             ` Jamie Lokier
2002-09-03 21:35       ` Jamie Lokier
2002-08-30  0:08     ` David S. Miller
2002-08-28 15:53 ` Mikael Pettersson
2002-08-28 16:16   ` Luca Barbieri
2002-08-28 19:48     ` Mikael Pettersson

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=1030661855.1490.98.camel@ldb \
    --to=ldb@ldb.ods.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    --cc=torvalds@transmeta.com \
    /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