From: Petr Vandrovec <petr@vandrovec.name>
To: Andi Kleen <ak@suse.de>
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: Sun, 12 Aug 2007 03:42:47 -0700 [thread overview]
Message-ID: <46BEE427.3020904@vandrovec.name> (raw)
In-Reply-To: <200708121209.40995.ak@suse.de>
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:
Commit: 3dab307e527f2a9bbb4f9d00240374bb93d1945f
Author: Chuck Ebbert <cebbert@redhat.com> Fri, 10 Aug 2007 22:31:11 +0200
which as far as I can tell really *is* after your fix. I'm quite sure
that I did not hit any BUG_ON() or anything like that - when patching
got to memcpy alternative, it entered text_poke(), and instead of
returning to caller it returned to BIOS :-(
> (although
>
> Linus, I would prefer if you reverted
> b8d3f2448b8f4ba24f301e23585547ba1acc1f04
> again -- it should really not be needed with
> ab144f5ec64c42218a555ec1dbde6b60cf2982d6
>
> And I really dislike Petr's patch because while it might work
> today (I'm not 100% sure it actually works to only replace
> 2 bytes) if we change memcpy ever it'll likely cause strange
> problems again.
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
function, but for this (and other x86-64 alternatives) it makes no sense
to replace whole function with nops if first instruction in alternative
is jump - then you need to only put that jump in place.
Petr
next prev parent reply other threads:[~2007-08-12 10:49 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 [this message]
2007-08-12 13:55 ` Andi Kleen
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=46BEE427.3020904@vandrovec.name \
--to=petr@vandrovec.name \
--cc=ak@suse.de \
--cc=discuss@x86-64.org \
--cc=linux-kernel@vger.kernel.org \
--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.