From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5282 invoked by alias); 10 Jun 2016 17:07:58 -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 5271 invoked by uid 89); 10 Jun 2016 17:07:58 -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 autolearn=ham version=3.3.2 spammy=death, protect X-HELO: mail-pf0-f173.google.com Received: from mail-pf0-f173.google.com (HELO mail-pf0-f173.google.com) (209.85.192.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 10 Jun 2016 17:07:56 +0000 Received: by mail-pf0-f173.google.com with SMTP id c2so25294518pfa.2 for ; Fri, 10 Jun 2016 10:07:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=XdAbS+9kn6rTRvfmW8QoBzbbwAA9nQ4l73c0XCr6rkg=; b=WtpsHRj9du+QCDCRF26/ifwSbaRF/22h8xcmQ15kHpPUsdeMFFAfJatZSlXyfzTeyU Jny5xGEACN/OZ5bfFC/AJi9KEfDz7Kbw9eQ7OedB6TCWc73slwlqwT2AkO4n39nWTiEe OHTYPbAgaFwR9yOzs/GNw7IgmiQpuyatJtj4MC+u9s0Gk3j59eUvqdOzmNMNzcpz4f2/ +Uh2XZMti7QvE3oOHb5Mon9hojKfM/rDN9VxCXtZYXW6KjT3u+0EfiXlBNskljstI1G5 PXIAg1RiNzltve812+Xd2LbSsL9lil1SOp9xr1iXjzGpMIQ5FwiCFUxhUPUZIzZKn6qz Ki9A== X-Gm-Message-State: ALyK8tKHTprBXswvzNUjAzFPQ9P+sNUWcaE9iogeFb7Dj1O8KDl6mtqoxa7BRM9v6oWIPx3E X-Received: by 10.98.108.3 with SMTP id h3mr3263568pfc.15.1465578474867; Fri, 10 Jun 2016 10:07:54 -0700 (PDT) Received: from localhost ([182.69.195.5]) by smtp.gmail.com with ESMTPSA id o64sm18950255pfb.76.2016.06.10.10.07.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 10:07:54 -0700 (PDT) Date: Fri, 10 Jun 2016 17:07:00 -0000 From: Pratyush Anand To: David Long Cc: William Cohen , systemtap@sourceware.org, Mark Brown Subject: Re: exercising current aarch64 kprobe support with systemtap Message-ID: <20160610170751.GB15590@dhcppc6> References: <599229e0-49ad-1c8e-1055-81e38692e5ec@redhat.com> <575A54D6.2070801@linaro.org> <20160610134251.GA15590@dhcppc6> <575ACCB5.90507@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <575ACCB5.90507@linaro.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-IsSubscribed: yes X-SW-Source: 2016-q2/txt/msg00214.txt.bz2 On 10/06/2016:10:20:37 AM, David Long 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. > > > > I had considered the assembler routine case but my take on it is that all of > this is just a best effort heuristic attempt to prevent someone from > kprobe'ing a kernel to death. I don't hold out any hope for making this > bullet-proof. The mode of failure for the atomic sequence is the safer > choice (rejecting probe registration) so I'm not that worried about the rare > case of this happening. Probing inline data doesn't seem like something we > can protect from, although we now do blacklist some more data sections. Sure, I agree that we go with what you have suggested. I was just thinking if we can take it with GCC people to improve it further in future. > > > Can GCC provide some compiler option where .word values are located into a > > specific area? > > > > You can't just go moving the effect of .word directives into a new > location/section. As likely as not that data (which could be an actual > instruction) needs to be exactly where they were put in the source. Yes, yes, I meant then compiler will have to modify the offset in instruction using .word data as well, and offcourse offset has limited range, so .word can be placed only in those limited regions. I do not have any idea about GCC implementation, so I do not say that this could be the best way of identifying .word instructions. ~Pratyush