Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932092AbWIVSxQ (ORCPT ); Fri, 22 Sep 2006 14:53:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932113AbWIVSxQ (ORCPT ); Fri, 22 Sep 2006 14:53:16 -0400 Received: from gprs189-60.eurotel.cz ([160.218.189.60]:62479 "EHLO spitz.ucw.cz") by vger.kernel.org with ESMTP id S932092AbWIVSxL (ORCPT ); Fri, 22 Sep 2006 14:53:11 -0400 Date: Fri, 22 Sep 2006 12:33:29 +0000 From: Pavel Machek To: Richard J Moore Cc: prasanna@in.ibm.com, Andrew Morton , Alan Cox , Mathieu Desnoyers , "Frank Ch. Eigler" , Greg Kroah-Hartman , Christoph Hellwig , Jes Sorensen , Paul Mundt , linux-kernel , ltt-dev@shafik.org, Martin Bligh , Michel Dagenais , Ingo Molnar , systemtap@sources.redhat.com, systemtap-owner@sourceware.org, Thomas Gleixner , William Cohen , Tom Zanussi Subject: Re: [PATCH] Linux Kernel Markers Message-ID: <20060922123329.GC4055@ucw.cz> References: <20060920010852.GA7469@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1512 Lines: 39 Hi! > > > > Very good idea.. However, overwriting the second instruction > > with a jump could > > > > be dangerous on preemptible and SMP kernels, because we never > > know if a thread > > > > has an IP in any of its contexts that would return exactly at > > the middle of the > > > > jump. > > > > > > No: on x86 it is the *same* case for all of these even writing an int3. > > > One byte or a megabyte, > > > > > > You MUST ensure that every CPU executes a serializing instruction > before > > > it hits code that was modified by another processor. Otherwise you get > > > CPU errata and the CPU produces results which vendors like to describe > > > as "undefined". > > > > Are you referring to Intel erratum "unsynchronized cross-modifying code" > > - where it refers to the practice of modifying code on one processor > > where another has prefetched the unmodified version of the code. > > In the special case of replacing an opcode with int3 that erratum doesn't > apply. I know that's not in the manuals but it has been confirmed by the > Intel microarchitecture group. And it's not reasonable to it to be any > other way. What about replacing int3 with old instruction (i.e. marker being deleted)? Pavel -- Thanks for all the (sleeping) penguins. - 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/