From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7058 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.comp.lib.glibc.alpha,gmane.linux.kernel,gmane.linux.ports.arm.kernel,gmane.linux.lib.musl.general Subject: Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64 Date: Mon, 16 Feb 2015 12:51:35 -0500 Message-ID: <20150216175135.GB23507@brightrain.aerifal.cx> References: <20141002155217.GH32147@e104818-lin.cambridge.arm.com> <1383502854.512344.1423688575473.JavaMail.open-xchange@oxbaltgw09.schlund.de> <20150211213758.GN23507@brightrain.aerifal.cx> <95765022.dfzNYZrNVS@wuerfel> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1424109113 16813 80.91.229.3 (16 Feb 2015 17:51:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Feb 2015 17:51:53 +0000 (UTC) Cc: "libc-alpha@sourceware.org" , "pinskia@gmail.com" , Marcus Shawcroft , "linux-kernel@vger.kernel.org" , Szabolcs Nagy , Andrew Pinski , "linux-arm-kernel@lists.infradead.org" , musl@lists.openwall.com To: Arnd Bergmann Original-X-From: libc-alpha-return-57027-glibc-alpha=m.gmane.org@sourceware.org Mon Feb 16 18:51:52 2015 Return-path: Envelope-to: glibc-alpha@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YNPpn-0006xU-4s for glibc-alpha@plane.gmane.org; Mon, 16 Feb 2015 18:51:51 +0100 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=E2lX iTkMZukBoxI5vAzSJz1zFHsR4GF4Tuq8EdABNNFXSPE4qo/Z5/9yAZcHR8LwbZde W6l6PNLjgMlbF3LcuZXH0zyBteXRRWUQGOYAzOLe0PNr8pY8MOt88BXQ7aiKU9KM 1MIfBzlUBbU4o6KEqasook9IT02bXu4bRk0JJ5s= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=otdLyD8j8Y eKOM7N6uNV5SEjau0=; b=Ys/ZPKLwgBphn9LfyJsFtrvi7QsJnstZCdQSajYIis CI71oLNtrhgXTs2fSkZILnE0e3q9HyZoJKH/SWQK7ga5rfFnJtIcFPVU/ji5uqdW J9ldQzV5KJsP6WTyB//lx6ZpX/OUzjLnj8Cj3M9qw/s22/rZX8GJ/O6rZwTdezos M= Original-Received: (qmail 7324 invoked by alias); 16 Feb 2015 17:51:47 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Original-Received: (qmail 7312 invoked by uid 89); 16 Feb 2015 17:51:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 X-HELO: brightrain.aerifal.cx Content-Disposition: inline In-Reply-To: <95765022.dfzNYZrNVS@wuerfel> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.comp.lib.glibc.alpha:49319 gmane.linux.kernel:1888897 gmane.linux.ports.arm.kernel:393609 gmane.linux.lib.musl.general:7058 Archived-At: On Mon, Feb 16, 2015 at 06:20:18PM +0100, Arnd Bergmann wrote: > > Would it really be that hard to do: > > > > if (ILP32_on_64_process) tv_nsec = (int)tv_nsec; > > > > or similar? That's all that's needed. > > > > > In some cases, there may also be a measurable performance penalty > > > in interpreting a user space data structure manually over copying > > > it (including the timespec values) in one chunk. > > > > I don't think the above would be measurable. > > It depends: Copying the structure first and then doing the conversion > in kernel space on the specific members as you do in the example > should indeed have a trivial performance impact. However, it is also > the hardest for driver writers to get right, and it's better not to > trust them with corner cases like this. > > To make it more readable, we would probably introduce a helper function > that copies the timespec from user space memory to kernel space and > then does all the checks and conversions as required. However, doing > separate copies can (depending on the architecture) have a noticeable > impact. An example for this would be architectures that require setting > up a page table entry for the user space page in order to access the > data and then destroy it again afterwards, with the correct TLB flushes. > > We can do something like this for the old-style compat handlers that > use 32-bit time_t, but I'd prefer not to have it in the fast path for > the native 64-bit time_t on 64-bit architectures. I know this isn't the place to discuss large architectural kernel changes, but it would be really nice if the kernel had proper abstract knowledge, at syscall entry time, what regions of memory from userspace the syscall is going to need and a way of marshalling them all together as prep for enterring the code that implements the syscalls, and if conversion between different ABIs could take place mostly automatically at this layer. Perhaps this kind of thing is an idea that could be kept open for the future. I suspect the combinatorics of different legacy interfaces are going to continue getting worse, and it would be much nicer to have the support factored out of the actual syscall implementations. > > Generally I would think the kernel knows the model the process is > > using, but if not, all you need is separate ioctl numbers for > > userspace to use depending on which definition it's using. > > I've checked now, and indeed the kernel knows for ilp32 x86 and arm, since > it uses a different ELF interpreter. I thought it might be running the > ilp32 binaries as ELF64, but it does not. This would result in lots of problems like argv[], auxv[], envp[], etc. being in the wrong format. > I would like to avoid separate ioctl command numbers, but we have to > do it for 64-bit time_t on the original 32-bit architectures in the > cases where the size is not already encoded in the command number. Indeed, I don't see any way around that. Rich