From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16484 invoked by alias); 7 Jul 2016 18:47:14 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 16473 invoked by uid 89); 7 Jul 2016 18:47:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 07 Jul 2016 18:47:13 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 00CC93B75E; Thu, 7 Jul 2016 18:47:12 +0000 (UTC) Received: from t540p.usersys.redhat.com ([10.15.1.231]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u67IlBCv030835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jul 2016 14:47:11 -0400 Subject: Re: SystemTap for Android - patchset To: Alexander Lochmann , Josh Stone , systemtap@sourceware.org References: <56e0c7f4-d317-f76b-5156-3569a6097b62@tu-dortmund.de> <577CF9A2.7050008@tu-dortmund.de> From: David Smith Message-ID: <822425cc-666c-c5dc-04bf-51898919a3b9@redhat.com> Date: Thu, 07 Jul 2016 18:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <577CF9A2.7050008@tu-dortmund.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-q3/txt/msg00022.txt.bz2 On 07/06/2016 07:29 AM, Alexander Lochmann wrote: > So. Let me start. > First of all, I extracted the patches properly, and attached the files. > (Btw, I found a third bug. :) ) > FYI, I just fixed the bugs for the kernel versions I'm dealing with, > because I don't know which other versions are affected as well. The problem you are trying to fix in your patch "[PATCH 1/3] Definition of cputime_to_usecs in Linux kernel 3.0 is broken" is interesting. I don't think you've got quite the right solution. Testing for a kernel version here works for you, but really isn't a general solution - depending on arch there could be a kernel in that range with a reasonable cputime_to_usecs(). ==== diff --git a/tapset/linux/task_time.stp b/tapset/linux/task_time.stp index f86f984..f3c276c 100644 --- a/tapset/linux/task_time.stp +++ b/tapset/linux/task_time.stp @@ -27,8 +27,12 @@ * Yet note some kernels (RHEL6) may already have both... */ #if defined(cputime_to_usecs) #if !defined(cputime_to_msecs) +#if LINUX_VERSION_CODE <= KERNEL_VERSION(3,0,200) && LINUX_VERSION_CODE >= KERNEL_VERSION(3,0,0) +#define cputime_to_msecs(__ct) _stp_div64(NULL, ({cputime_to_usecs(__ct)}), 1000ULL) +#else #define cputime_to_msecs(__ct) _stp_div64(NULL, cputime_to_usecs(__ct), 1000ULL) #endif +#endif /* Kernels before 2.6.37 have cputime_to_msecs, but not usecs. */ #elif defined(cputime_to_msecs) ==== I've got a couple of thoughts here: - I wonder if we just couldn't always use your workaround (along with a comment about why we're doing that). - Here's an untested workaround idea that might work for all kernels: #define cputime_to_msecs(__ct) \ ({ \ unsigned long __usecs = cputime_to_usecs(__ct); \ _stp_div64(NULL, __usecs, 1000ULL); \ }) -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)