From mboxrd@z Thu Jan 1 00:00:00 1970 From: Colin Cross Subject: Re: MT_HIGH_VECTOR mapping set read-only creating illegal access Date: Tue, 19 Apr 2011 20:26:27 -0700 Message-ID: References: <4DA4F170.4020009@codeaurora.org> <4DAE0E07.9030806@codeaurora.org> <4DAE3A8E.1000903@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from smtp-out.google.com ([74.125.121.67]:31523 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751111Ab1DTD0b convert rfc822-to-8bit (ORCPT ); Tue, 19 Apr 2011 23:26:31 -0400 Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p3K3QTBZ021961 for ; Tue, 19 Apr 2011 20:26:29 -0700 Received: from yxt33 (yxt33.prod.google.com [10.190.5.225]) by wpaz24.hot.corp.google.com with ESMTP id p3K3QSUq017269 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 19 Apr 2011 20:26:28 -0700 Received: by yxt33 with SMTP id 33so142566yxt.14 for ; Tue, 19 Apr 2011 20:26:28 -0700 (PDT) In-Reply-To: Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Nicolas Pitre Cc: Michael Bohan , linux-arm-msm@vger.kernel.org, Russell King - ARM Linux , linux-arm-kernel@lists.infradead.org On Tue, Apr 19, 2011 at 8:01 PM, Nicolas Pitre wrote= : > On Tue, 19 Apr 2011, Michael Bohan wrote: > >> On 4/19/2011 5:21 PM, Nicolas Pitre wrote: >> > Are you saying that your user space libc was reading at 0xffff0ff0 >> > directly? =A0I hope not, because if you did so, you clearly abused= the >> > interface and the contract between user space and the kernel. =A0H= ere's >> > what I wrote in the comment right above the related code: >> > >> > =A0 * These are segment of kernel provided user code reachable fro= m user space >> > =A0 * at a fixed address in kernel memory. =A0This is used to prov= ide user space >> > =A0 * with some operations which require kernel help because of un= implemented >> > =A0 * native feature and/or instructions in many ARM CPUs. The ide= a is for >> > =A0 * this code to be executed directly in user mode for best effi= ciency but >> > =A0 * which is too intimate with the kernel counter part to be lef= t to user >> > =A0 * libraries. =A0In fact this code might even differ from one C= PU to another >> > =A0 * depending on the available =A0instruction set and restrictio= ns like on >> > =A0 * SMP systems. =A0In other words, the kernel reserves the righ= t to change >> > =A0 * this code as needed without warning. Only the entry points a= nd their >> > =A0 * results are guaranteed to be stable. >> > >> > This has been there since April 29th 2005 i.e. 6 years ago. >> >> Yes, unfortunately Android appears to do this as an 'optimization' i= n the case >> of dynamically linked execs. That is, it skips the helper code all t= ogether. > > You should find the persons responsible for this aberration and flame > them with extreme prejudice! =A0As if this could make any measurable > difference on any benchmark... > > Either you have the hw reg for TLS and may use it directly, or you us= e > the provided helper dammit! =A0I think I'll just move the implementat= ion > private 0xffff0ff0 location around just to make sure it breaks any us= er > code that wrongly started to abuse this interface. > I believe the original implementation used the helper, and then it was modified to skip the helper due to a measured performance impact. Something to do with cache pressure and a specific vendor GL library that heavily used get_tls(), I think, but it was before my time. It is already fixed on the Android userspace side by defining ARCH_ARM_HAVE_TLS_REGISTER, which will prevent libc from ever accessing the private location, and we have dropped the hacks from our recent kernel trees.