From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13372 invoked by alias); 27 Jun 2006 15:23:04 -0000 Received: (qmail 13364 invoked by uid 22791); 27 Jun 2006 15:23:03 -0000 X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 27 Jun 2006 15:23:01 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.6/8.13.6) with ESMTP id k5RFMwWT081636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 27 Jun 2006 15:22:58 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k5RFPTu9067824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Jun 2006 17:25:29 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5RFMwQc006711 for ; Tue, 27 Jun 2006 17:22:58 +0200 Received: from dyn-9-152-216-78.boeblingen.de.ibm.com (dyn-9-152-216-78.boeblingen.de.ibm.com [9.152.216.78]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5RFMvYq006704; Tue, 27 Jun 2006 17:22:57 +0200 Subject: Re: [PATCH] kprobes for s390 architecture From: Martin Schwidefsky Reply-To: schwidefsky@de.ibm.com To: Heiko Carstens Cc: Michael Grundy , Jan Glauber , linux-kernel@vger.kernel.org, systemtap@sources.redhat.com In-Reply-To: <20060624113641.GB10403@osiris.ibm.com> References: <20060623150344.GL9446@osiris.boeblingen.de.ibm.com> <20060623222106.GA25410@osiris.ibm.com> <20060624113641.GB10403@osiris.ibm.com> Content-Type: text/plain Organization: IBM Corporation Date: Tue, 27 Jun 2006 18:53:00 -0000 Message-Id: <1151421789.5390.65.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q2/txt/msg00701.txt.bz2 On Sat, 2006-06-24 at 13:36 +0200, Heiko Carstens wrote: > > At least this is something that could work... completely untested and might > > have some problems that I didn't think of ;) > > > > struct capture_data { > > atomic_t cpus; > > atomic_t done; > > }; > > > > void capture_wait(void *data) > > { > > struct capture_data *cap = data; > > > > atomic_inc(&cap->cpus); > > while(!atomic_read(&cap->done)) > > cpu_relax(); > > atomic_dec(&cap->cpus); > > } > > > > void replace_instr(int *a) > > { > > struct capture_data cap; > > > > preempt_disable(); > > atomic_set(&cap.cpus, 0); > > atomic_set(&cap.done, 0); > > smp_call_function(capture_wait, (void *)&cap, 0, 0); > > while (atomic_read(&cap.cpus) != num_online_cpus() - 1) > > cpu_relax(); > > *a = 0x42; > > atomic_inc(&cap.done); > > while (atomic_read(&cap.cpus)) > > cpu_relax(); > > preempt_enable(); > > } > > Forget this crap. It can easily cause deadlocks with more than two cpus. It is not that bad. Instead of preempt_disable/preempt_enable we need a spinlock. Then only one cpu can do this particular smp_call_function which will "stop" all other cpus until cap->done has been set. > Just do a compare and swap operation on the instruction you want to replace, > then do an smp_call_function() with the wait parameter set to 1 and passing > a pointer to a function that does nothing but return. Not good enough. An instruction can be fetched multiple times for a single execution (see the other mail). So you have a half executed instruction, the cache line is invalidated, a new instruction is written and the cache line is recreated to finished the half executed instruction. That can easiliy happen on millicoded instructions. > The cs/csg instruction will make sure that your cpu has exclusive access > to the memory region in question and will invalidate the cache lines on all > other cpus. That the cache line is invalidated does not mean that you are safe.. > With the following smp_call_function() you can make sure that all other > cpus discard everything they have prefetched. Hence there is only a small > window between the cs/csg and the return of smp_call_function() where you > do not know if other cpus are executing the old or the new instruction. The serialization is indeed done by the smp_call_function(). No need to have a "bcr 15,0" in the called function, the lpsw at the end of the interrupt already does the serialization. -- blue skies, Martin. Martin Schwidefsky Linux for zSeries Development & Services IBM Deutschland Entwicklung GmbH "Reality continues to ruin my life." - Calvin.