From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20118 invoked by alias); 6 Dec 2005 01:40:54 -0000 Received: (qmail 20108 invoked by uid 22791); 6 Dec 2005 01:40:54 -0000 X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_00,DNS_FROM_RFC_POST X-Spam-Check-By: sourceware.org Received: from fmr21.intel.com (HELO scsfmr001.sc.intel.com) (143.183.121.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Dec 2005 01:40:52 +0000 Received: from scsfmr100.sc.intel.com (scsfmr100.sc.intel.com [10.3.253.9]) by scsfmr001.sc.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id jB61ehJb016730; Tue, 6 Dec 2005 01:40:43 GMT Received: from scsmsxvs040.sc.intel.com (scsmsxvs040.sc.intel.com [10.3.90.8]) by scsfmr100.sc.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id jB5IpRm0010201; Mon, 5 Dec 2005 18:51:32 GMT Received: from scsmsx332.amr.corp.intel.com ([10.3.90.6]) by scsmsxvs040.sc.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005120517404219235 ; Mon, 05 Dec 2005 17:40:42 -0800 Received: from scsmsx403.amr.corp.intel.com ([10.3.90.18]) by scsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 17:40:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Bug translator/1276] support more timer varieties Date: Tue, 06 Dec 2005 01:40:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Bug translator/1276] support more timer varieties Thread-Index: AcX6Af4mnT3jOQHGTX+eUtvnu2zW2wAA0obA From: "Stone, Joshua I" To: "Roland McGrath" , "Frank Ch. Eigler" Cc: X-OriginalArrivalTime: 06 Dec 2005 01:40:42.0522 (UTC) FILETIME=[11CB6FA0:01C5FA06] X-Scanned-By: MIMEDefang 2.52 on 10.3.253.9 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: 2005-q4/txt/msg00346.txt.bz2 Roland McGrath wrote: > What this really means is that "current" always works, it's just not > always useful to think about that task. i.e., in an interrupt > handler, the interrupt has nothing necessarily to do with the task > that was current at the time of the interrupt. I'm fairly sure that > "current" never yields garbage, or even a task that isn't exactly the > one that was on the CPU running process-mode code last. That is my understanding as well... the pointer is always valid, it just doesn't pertain to the interrupt itself. Frank Ch. Eigler wrote: > If it doesn't scare you off, then let's have a volunteer try disarming > some of those in_interrupt() conditionals (maybe replacing them with a > quick NULL or other simple pointer validity check), and write a few > stress tests (probes in uncomfortable spots for "current" usage). I'll volunteer for this (though others are welcome as well). Have any suggested probe points that are particularly uncomfortable? Josh