All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Petr Vandrovec <petr@vandrovec.name>
Cc: discuss@x86-64.org, torvalds@linux-foundation.org,
	linux-kernel@vger.kernel.org
Subject: Re: Please remove ab144f5ec64c42218a555ec1dbde6b60cf2982d6 was Re: [discuss] [PATCH] Fix triplefault on x86-64 bootup
Date: 12 Aug 2007 15:55:50 +0200	[thread overview]
Message-ID: <p731we8kgbd.fsf@bingen.suse.de> (raw)
In-Reply-To: <46BEE427.3020904@vandrovec.name>

Petr Vandrovec <petr@vandrovec.name> writes:

> Andi Kleen wrote:
> > On Sunday 12 August 2007 10:12, Petr Vandrovec wrote:
> >> Hello,
> >>   after I upgraded kernel on my box to current git, only thing it did
> >> was rebooting in a loop.  After some digging I found that it is silly
> >> to apply alternative to memcpy by using that every same memcpy...
> >> Sorry if it is known bug, I do not see it reported in my LKML mailbox...
> > Ok Linus already applied your patch. Even though it's a really bad
> > fragile hack, not better than the old bug.
> > Petr are you double sure you really tested with
> > ab144f5ec64c42218a555ec1dbde6b60cf2982d6
> > already applied? I bet not -- it is the symptom exactly fixed by this patch
> 
> I'm quite sure that this patch is in my tree, as I have that "u8
> *instr = a->instr;" in apply_alternatives, and it seems that this one
> was added by checkin you mention...  My tree was synced up to:

Can you double check? I have a hard time believing it.

> It does not actually change two bytes - it changes two bytes now
> because alternative is two bytes long - it makes no sense to replace
> whole function with NOPs - it is necessary when you fall through that

It saves the jump. Admittedly not a big advantage.

-Andi

  reply	other threads:[~2007-08-12 13:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-12  8:12 [PATCH] Fix triplefault on x86-64 bootup Petr Vandrovec
2007-08-12  8:40 ` Linus Torvalds
2007-08-12  8:59   ` Linus Torvalds
2007-08-12 10:01     ` Andi Kleen
2007-08-12  9:59   ` Andi Kleen
2007-08-12 17:56     ` Linus Torvalds
2007-08-12  9:57 ` [discuss] " Andi Kleen
2007-08-12 10:09 ` Please remove ab144f5ec64c42218a555ec1dbde6b60cf2982d6 was " Andi Kleen
2007-08-12 10:42   ` Petr Vandrovec
2007-08-12 13:55     ` Andi Kleen [this message]
2007-08-12 13:46       ` Paolo Ornati
2007-08-12 17:57       ` Linus Torvalds
2007-08-12 10:46 ` Alexey Dobriyan
2007-08-12 13:53   ` Andi Kleen
2007-08-12 13:12     ` Alexey Dobriyan

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=p731we8kgbd.fsf@bingen.suse.de \
    --to=andi@firstfloor.org \
    --cc=discuss@x86-64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=petr@vandrovec.name \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.