From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30489 invoked by alias); 28 Jul 2005 18:33:46 -0000 Mailing-List: contact systemtap-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sources.redhat.com Received: (qmail 30471 invoked by uid 22791); 28 Jul 2005 18:33:40 -0000 Date: Thu, 28 Jul 2005 18:33:00 -0000 From: Mathieu Desnoyers To: Keshavamurthy Anil S Cc: Karim Yaghmour , Masami Hiramatsu , Masami Hiramatsu , Roland McGrath , Richard J Moore , SystemTAP , sugita@sdl.hitachi.co.jp, Satoshi Oshima , michel.dagenais@polymtl.ca Subject: Re: Hitachi djprobe mechanism Message-ID: <20050728183234.GC18093@Krystal> References: <44BDAFB888F59F408FAE3CC35AB4704101E506F6@orsmsx409> <42E83895.6070602@opersys.com> <42E83CEC.8040702@opersys.com> <42E90600.3040709@opersys.com> <20050728173515.GB18093@Krystal> <20050728110717.A30199@unix-os.sc.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <20050728110717.A30199@unix-os.sc.intel.com> X-Editor: vi X-Info: http://krystal.dyndns.org:8080 X-Operating-System: Linux/2.4.30-grsec (i686) X-Uptime: 14:12:18 up 41 days, 12:22, 4 users, load average: 0.03, 0.05, 0.07 User-Agent: Mutt/1.5.9i X-SW-Source: 2005-q3/txt/msg00149.txt.bz2 * Keshavamurthy Anil S (anil.s.keshavamurthy@intel.com) wrote: > Your suggestion has several limitations, the moment you replace cli with int3, > some thread on some cpu might hit this int3 which needs to be handled > and not only that, after this is handled this thread might starts to execute > nop instruction which is right after int3 and at which point in time this > thread might be prempted. Again we end up in the same situation as before. > > Also checking that no other CPU has interrupt disabled using an IPI involves > tight spining in the IPI callback handler which is prone to deadlock. > The goal of this int3 is indeed that, if another thread on another CPU falls into it, the int3 handler will change its own return address to fall into the push instruction, right after the nops. For the IPI : - the on_each_cpu should be called from a context where no spinlock is held. The context from which it is called could be protected by a flag which would cause any concurrent processor to fail if they try to follow the same "code alteration" function. - the IPI handler does not need to spin at all. It just returns. It only has to inform us about when interrupt disabled zone has ended. As this zone will not be reentered due to the int3 instruction, everything is fine. Or did I miss something ? Mathieu OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68