From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11754 invoked by alias); 7 Nov 2011 16:03:42 -0000 Received: (qmail 11744 invoked by uid 22791); 7 Nov 2011 16:03:40 -0000 X-SWARE-Spam-Status: No, hits=-6.9 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, 07 Nov 2011 16:03:26 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pA7G3K5C020237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2011 11:03:20 -0500 Received: from t510.usersys.redhat.com (dhcp-10-15-1-97.hsv.redhat.com [10.15.1.97]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id pA7G3JHK030337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Nov 2011 11:03:19 -0500 Message-ID: <4EB80147.8050303@redhat.com> Date: Mon, 07 Nov 2011 16:03:00 -0000 From: David Smith User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: Heiko Carstens CC: Ananth N Mavinakayanahalli , Systemtap List Subject: Re: s390x help needed - kernel read faults 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> In-Reply-To: <20111031102934.GA4768@osiris.boeblingen.de.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00153.txt.bz2 On 10/31/2011 05:29 AM, Heiko Carstens wrote: >>> You can avoid that by using the probe_kernel_write() function which will >>> bybass the write protection (on s390). >> >> I don't doubt writes are broken. While writes will need to work, I'd >> guess 85%-90% of the time we will call this code to do reads (deref()), >> not writes (store_deref()). So, I'd like to initially focus on reads. >> >>> Also in the current code I do not see how address spaces are switched, so >>> it looks to me like all operations are always done in the kernel address >>> space. >>> >>> I didn't see however the tricky part you mentioned (user space vs kernel >>> space). How does the code distinguish if an operation has to be done on >>> the kernel space address range or user space address range? >> >> Sigh. That's the thing - we don't distinguish. The assumption was made >> that calling a function to access user memory would also work for kernel >> memory. > > Sure it does, _if_ you call set_fs(KERNEL_DS) in advance of any of uaccess > functions. Of course you know that already. > > What I don't understand is, why you do not use the set_fs() mechanism and > the in-kernel uaccess functions. Instead you provide your own functions. > > Looking alone at the address that needs to be read or written to it's simply > impossible to tell if it's a user space or kernel space address. Just must > specify it. > In addition all the different address space layouts on s390 will make your > life much more difficult. Hence.. use the in-kernel functions, everything > else will break again. Sorry for not responding sooner. I'm not sure why we provided our own functions, that decision was made a long time ago. If we can't look at the address and know whether it is a user space or kernel space address, then I don't see much choice than to break up our memory accesses and require the callers to know whether they are accessing kernel space or user space. Thanks for the advice. -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)