From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98484 invoked by alias); 10 Jun 2016 14:37:55 -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 98475 invoked by uid 89); 10 Jun 2016 14:37:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:ecfb1fd, H*f:sk:ecfb1fd, H*MI:sk:ecfb1fd X-HELO: mail-qk0-f180.google.com Received: from mail-qk0-f180.google.com (HELO mail-qk0-f180.google.com) (209.85.220.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 10 Jun 2016 14:37:44 +0000 Received: by mail-qk0-f180.google.com with SMTP id s186so38174426qkc.1 for ; Fri, 10 Jun 2016 07:37:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=teSaaKInZXD6Y1nBxSVlyc1OKB+XJYIFxf+dPM124Yc=; b=Nk7Bq4ECSasb8tzbfavf/qqLEqo5JMRw0hCLXpYjGa3qKbeOvgwC+nzt9ZxG3mKtMj 2JRu1URFNtI/3RxrZraoQo5kEzdgsZIcYMUvG2f5EG4uC6u8R88Cnu3s/nfFamasw1c0 iIH+cURRKfnkI9pwdeHoTJhS8Na9u9Ff6sUYMvp7TSN15G4aDivn+dQaM/LSQ1UjMQ3F NEJVdxf+uuZ6/krZfAbzjDOJI/WzXfwiXDEJypq8sh9WIRbclMM1jYHNRuhYi1t7DbYa cbKW4E2OTcROXuAHMrXka9X82Umjh9Jj9lTt0ZpnLIQOA/qY+WuQ/lLfR66uFk/2/TzT 1odA== X-Gm-Message-State: ALyK8tKGZcSXajSMnKaa7vQtruOmrXzFdLEOM7Cb/S7CC5R0Oexhwj3x23ARdgRpKF2Vo/N/ X-Received: by 10.55.154.72 with SMTP id c69mr2321596qke.47.1465569461862; Fri, 10 Jun 2016 07:37:41 -0700 (PDT) Received: from [192.168.0.113] (c-24-147-75-190.hsd1.nh.comcast.net. [24.147.75.190]) by smtp.googlemail.com with ESMTPSA id p91sm2701927qgp.10.2016.06.10.07.37.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 07:37:41 -0700 (PDT) Subject: Re: exercising current aarch64 kprobe support with systemtap To: William Cohen , Pratyush Anand References: <599229e0-49ad-1c8e-1055-81e38692e5ec@redhat.com> <575A54D6.2070801@linaro.org> <20160610134251.GA15590@dhcppc6> Cc: systemtap@sourceware.org, Mark Brown From: David Long Message-ID: <575AD0B4.8020601@linaro.org> Date: Fri, 10 Jun 2016 14:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-q2/txt/msg00211.txt.bz2 On 06/10/2016 10:03 AM, William Cohen wrote: > On 06/10/2016 09:42 AM, Pratyush Anand wrote: >> On 10/06/2016:01:49:10 AM, David Long wrote: >>> Attached are incremental diffs I hope will fix the latest systemtap >>> failures, without abandoning atomic sequence checking. I'm trying to avoid >>> the hex constants but I don't think the insn.c functions help in this case. >> >> It will save us from current problem by checking "stp x29,x30,[sp,...]" >> instruction and returning false if matches. However, we will have to find some >> way to recognize .word instructions. >> >> * An assembly function may not start with "stp x29,x30,[sp,...]", e.g. >> __dma_map_area(), _cpu_resume etc. However, it could be least likely that a >> .word instruction exists before start of assembly function and that too >> contains a word value which could be misleading. >> >> * But major issue is, what if someone instruments a kprobe at an address which >> contains .word values. Instruction will never hit, so probe function will not >> be called, but when real code reads that .word value, it reads a wrong value. >> >> Can GCC provide some compiler option where .word values are located into a >> specific area? >> >> ~Pratyush > > Hi Dave and Pratyush, > > Expecting the instruction to the stp x29, x30, [sp,...] would be pretty fragile. The compiler might not generate that for some very simple function or with certain types of optimization. If the compiler could generate a sentinel word before the start of each function that might be a more robust solution. Maybe something like a breakpoint instruction or something that clearly would not be in an atomic region. > I think this is still a reasonable improvement. The case of both heuristics failing together has to be pretty rare and the result is to make the safer choice. I'm looking at what gcc might provide to help. I made need to talk to a compiler expert though, I've always found the gcc option list a bit overwhelming. > -Will >> >>> >>> -dl >>> >> >>> diff --git a/arch/arm64/kernel/kprobes-arm64.c b/arch/arm64/kernel/kprobes-arm64.c >>> index 28b9c5b..36b4ea5 100644 >>> --- a/arch/arm64/kernel/kprobes-arm64.c >>> +++ b/arch/arm64/kernel/kprobes-arm64.c >>> @@ -127,7 +127,9 @@ is_probed_address_atomic(kprobe_opcode_t *scan_start, kprobe_opcode_t *scan_end) >>> * atomic region starts from exclusive load and ends with >>> * exclusive store. >>> */ >>> - if (aarch64_insn_is_store_ex(le32_to_cpu(*scan_start))) >>> + if ((le32_to_cpu(*scan_start) & 0xffc07fff) == 0xa9807bfd) >>> + return false; >>> + else if (aarch64_insn_is_store_ex(le32_to_cpu(*scan_start))) >>> return false; >>> else if (aarch64_insn_is_load_ex(le32_to_cpu(*scan_start))) >>> return true; >> >