From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9586 invoked by alias); 23 Jun 2006 16:04:06 -0000 Received: (qmail 9575 invoked by uid 22791); 23 Jun 2006 16:04:02 -0000 X-Spam-Status: No, hits=-0.9 required=5.0 tests=ADDRESS_IN_SUBJECT,BAYES_00,DATE_IN_FUTURE_06_12,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e2.ny.us.ibm.com (HELO e2.ny.us.ibm.com) (32.97.182.142) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 23 Jun 2006 16:04:01 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5NG3xma023906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 23 Jun 2006 12:03:59 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k5NG3uS2257990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Jun 2006 12:03:59 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5NG3u2a009261 for ; Fri, 23 Jun 2006 12:03:56 -0400 Received: from d01ml065.pok.ibm.com (d01ml065.pok.ibm.com [9.56.229.34]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5NG3usp009254; Fri, 23 Jun 2006 12:03:56 -0400 In-Reply-To: <20060623150344.GL9446@osiris.boeblingen.de.ibm.com> Subject: Re: [heiko.carstens@de.ibm.com: Re: [PATCH] kprobes for s390 architecture] To: Heiko Carstens Cc: Jan Glauber , Martin Schwidefsky , linux-kernel@vger.kernel.org, systemtap@sources.redhat.com X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 Message-ID: From: Michael Grundy Date: Fri, 23 Jun 2006 16:04:00 -0000 X-MIMETrack: Serialize by Router on D01ML065/01/M/IBM(Release 7.0.1 HF4|May 16, 2006) at 06/23/2006 12:03:55 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-IsSubscribed: yes 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/msg00681.txt.bz2 Heiko Carstens wrote on 06/23/2006 08:03:44 AM: > This won't solve anything. What Martin probably meant is something like a poor > man's stop_machine_run() implemented by using smp_call_function(). This way > you synchronize all cpus and when all cpus are in a known state, you change > the instruction in question and make sure that serialization happens before > cpus leave the handler again... Except for the cpu that called > smp_call_function() you get the serialization for free, since the last > instruction of the handler is always an lpsw/lpswe instruction. > > Otherwise there is still the possibility that a different cpu is fetching the > instruction concurrently while you change it. This doesn't sound very good, > especially if you take this paragraph of the Principles of Operation into > account (p.5-89 of SA22-7832-04): > > "It is possible, if another CPU or a channel program concurrently modifies > the instruction, for one CPU to recognize the changes to some but not all bit > positions of an instruction." (link to doc for anyone following along at home: http://publibz.boulder.ibm.com/epubs/pdf/a2278324.pdf) On the same page it says "All copies of a prefetched instruction are discarded when: * A serializing function is performed" Would something like this in a smp_call_function do it? : bcr 15,0 if (*p->addr != breakpoint_instruction) *p->addr = breakpoint_instruction; Alternatively, if we did a compare and swap on that location (serializing instruction) would that be acceptable? Thanks Michael ========================================= If at first you don't succeed, call in an air strike. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14118 invoked by alias); 24 Jun 2006 03:02:38 -0000 Received: (qmail 14102 invoked by uid 22791); 24 Jun 2006 03:02:37 -0000 X-Spam-Status: No, hits=-1.2 required=5.0 tests=ADDRESS_IN_SUBJECT,AWL,BAYES_00,DATE_IN_PAST_03_06,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mga07.intel.com (HELO azsmga101.ch.intel.com) (143.182.124.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 24 Jun 2006 03:02:35 +0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 23 Jun 2006 20:02:33 -0700 Received: from scsmsx331.sc.intel.com (HELO scsmsx331.amr.corp.intel.com) ([10.3.90.4]) by azsmga001.ch.intel.com with ESMTP; 23 Jun 2006 20:02:32 -0700 X-IronPort-AV: i="4.06,170,1149490800"; d="scan'208"; a="56738554:sNHT18282950" Received: from scsmsx413.amr.corp.intel.com ([10.3.90.32]) by scsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Jun 2006 20:02:28 -0700 Received: from mail pickup service by scsmsx413.amr.corp.intel.com with Microsoft SMTPSVC; Fri, 23 Jun 2006 19:48:11 -0700 Received: from scsmsx411.amr.corp.intel.com ([10.3.90.30]) by scsmsx413.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 09:13:18 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by scsmsx411.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 09:08:26 -0700 Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 09:08:25 -0700 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 09:08:25 -0700 Received: from fmsmga101.fm.intel.com ([10.1.193.65]) by fmsmga001.fm.intel.com with ESMTP; 23 Jun 2006 09:08:21 -0700 Received: from vger.kernel.org ([209.132.176.167]) by fmsmga101.fm.intel.com with ESMTP; 23 Jun 2006 09:07:53 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,169,1149490800"; d="scan'208"; a="345923:sNHT26439426" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751719AbWFWQEB (ORCPT ); Fri, 23 Jun 2006 12:04:01 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751724AbWFWQEB (ORCPT ); Fri, 23 Jun 2006 12:04:01 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.145]:15241 "EHLO e5.ny.us.ibm.com") by vger.kernel.org with ESMTP id S1751719AbWFWQD7 (ORCPT ); Fri, 23 Jun 2006 12:03:59 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5NG3vKa000649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 23 Jun 2006 12:03:57 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k5NG3vsE272856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Jun 2006 12:03:57 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5NG3u2c009261 for ; Fri, 23 Jun 2006 12:03:56 -0400 Received: from d01ml065.pok.ibm.com (d01ml065.pok.ibm.com [9.56.229.34]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5NG3usp009254; Fri, 23 Jun 2006 12:03:56 -0400 In-Reply-To: <20060623150344.GL9446@osiris.boeblingen.de.ibm.com> Subject: Re: [heiko.carstens@de.ibm.com: Re: [PATCH] kprobes for s390 architecture] To: Heiko Carstens Cc: Jan Glauber , Martin Schwidefsky , linux-kernel@vger.kernel.org, systemtap@sources.redhat.com X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 Message-ID: From: Michael Grundy Date: Sat, 24 Jun 2006 11:37:00 -0000 X-MIMETrack: Serialize by Router on D01ML065/01/M/IBM(Release 7.0.1 HF4|May 16, 2006) at 06/23/2006 12:03:55 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Mailing-List: linux-kernel@vger.kernel.org X-OriginalArrivalTime: 23 Jun 2006 16:08:25.0630 (UTC) FILETIME=[420783E0:01C696DF] X-IsSubscribed: yes 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/msg00683.txt.bz2 Message-ID: <20060624113700.Sa-_p20yqiSt2TivlTJC19gpiUjIldj4cumRFAxxk6s@z> Heiko Carstens wrote on 06/23/2006 08:03:44 AM: > This won't solve anything. What Martin probably meant is something like a poor > man's stop_machine_run() implemented by using smp_call_function(). This way > you synchronize all cpus and when all cpus are in a known state, you change > the instruction in question and make sure that serialization happens before > cpus leave the handler again... Except for the cpu that called > smp_call_function() you get the serialization for free, since the last > instruction of the handler is always an lpsw/lpswe instruction. > > Otherwise there is still the possibility that a different cpu is fetching the > instruction concurrently while you change it. This doesn't sound very good, > especially if you take this paragraph of the Principles of Operation into > account (p.5-89 of SA22-7832-04): > > "It is possible, if another CPU or a channel program concurrently modifies > the instruction, for one CPU to recognize the changes to some but not all bit > positions of an instruction." (link to doc for anyone following along at home: http://publibz.boulder.ibm.com/epubs/pdf/a2278324.pdf) On the same page it says "All copies of a prefetched instruction are discarded when: * A serializing function is performed" Would something like this in a smp_call_function do it? : bcr 15,0 if (*p->addr != breakpoint_instruction) *p->addr = breakpoint_instruction; Alternatively, if we did a compare and swap on that location (serializing instruction) would that be acceptable? Thanks Michael ========================================= If at first you don't succeed, call in an air strike. - 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/