From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23027 invoked by alias); 28 Nov 2011 11:20:45 -0000 Received: (qmail 23014 invoked by uid 22791); 28 Nov 2011 11:20:43 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Nov 2011 11:20:26 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pASBK70L023834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Nov 2011 06:20:08 -0500 Received: from springer.wildebeest.org (ovpn-116-26.ams2.redhat.com [10.36.116.26]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pASBK6Ul012254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Nov 2011 06:20:07 -0500 Received: by springer.wildebeest.org (Postfix, from userid 500) id 598414465A; Mon, 28 Nov 2011 12:20:06 +0100 (CET) Subject: Re: s390x help needed - kernel read faults From: Mark Wielaard To: David Smith Cc: Heiko Carstens , Ananth N Mavinakayanahalli , Systemtap List In-Reply-To: <1322272226.4539.24.camel@springer.wildebeest.org> References: <4E9C76F7.6010802@redhat.com> <20111018052305.GA22831@in.ibm.com> <20111018081753.GA2578@osiris.boeblingen.de.ibm.com> <4E9D8577.9030705@redhat.com> <20111028124058.GA2475@osiris.boeblingen.de.ibm.com> <4EAAF791.1060109@redhat.com> <20111031102934.GA4768@osiris.boeblingen.de.ibm.com> <4EB80147.8050303@redhat.com> <20111107171736.GA11606@hermans.wildebeest.org> <1322272226.4539.24.camel@springer.wildebeest.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Nov 2011 11:20:00 -0000 Message-ID: <1322479205.19629.17.camel@springer.wildebeest.org> Mime-Version: 1.0 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 X-SW-Source: 2011-q4/txt/msg00226.txt.bz2 On Sat, 2011-11-26 at 02:50 +0100, Mark Wielaard wrote: > So I split our deref and store_deref into uderef/kderef and > store_u/kderef that are now used when user or kernel addresses are > accessed. For most architectures these are equal. But for s390x I > replaced our custom accessor functions with with standard s390 kernel > __get_user() and __put_user() functions and then wrap those in get_fs() > set_fs() calls to switch between user/kernel space addresses. See below. >=20 > Tested against 2.6.18 (rhel5) and 2.6.32 (rhel6) kernels. It improves > the make installcheck results a lot. >=20 > There is still some work to do for the user space dwarf unwinder. This has been fixed, the unwinder now also splits its user/kernel address view completely. There was also a generic bug in the vma tracker that could in theory hit on any architecture. There is still an issue with PIE executables on s390x that I haven't tracked down yet. But excluding PIE executables both user and kernel backtracing and symbol tracking seems to be on par with other architectures now. Cheers, Mark commit 3c6dd54efb6de5b4d55e073c8d5884440aece135 Author: Mark Wielaard Date: Sat Nov 26 22:21:22 2011 +0100 Pass through user flag into all of unwinder. =20=20=20=20 runtime/unwind.c relied on passing of struct task being not NULL to see whether to access user space. In practice tsk was always either NULL or current. And not all bits of the unwinder checked it. Now we just pass a user flag and push it down to every function that needs it. commit bde342310dd6b1a7e247a0dc40089b25f045552a Author: Mark Wielaard Date: Mon Nov 28 12:06:39 2011 +0100 _stp_vma_mmap_cb: Really mean that we are only interested in the first load. =20=20=20=20 There was a chance our test for whether this was the first load of the whole module that is executable could miss a second load, which would override the original start address. Fix that by explicitly checking whether we already registered this module or not.