Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp484779imu; Tue, 11 Dec 2018 02:30:47 -0800 (PST) X-Google-Smtp-Source: AFSGD/U4UvUj03klaGEYg9oDUp9iBFKGU0F0TA3o1pYsLSjfNoNKbjMdBXclmSB2RxkZCTJj3aX8 X-Received: by 2002:a63:a30a:: with SMTP id s10mr13085352pge.234.1544524247287; Tue, 11 Dec 2018 02:30:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544524247; cv=none; d=google.com; s=arc-20160816; b=ShoSkhBW0TBWzElH/Qnos5mi+ZUnCYuWq5vgUSLkJ2qdDByJjNXTr0OlvdpOF5C73e 4+D+IMWBbeoIrcxP+eXmJ3SBLfhBbZHSNL7OhLWcn+uocHcGIpBJWox89Bk/mC7lYkEd dLGB9QD3n7P15rJn+sk5tNJW1comYp2sbKRtR7/7BhItyvQ5GM75flybq4FF9GRKKHwn 4CMSTp+1K/thtDOKitIb20/cQZYxy/ENHUosWCVYVCeyTbMDxdUqvpWebqQK5Pqb31hJ Y4PC9+EuSza3H1sNg4tIUkqUOF6Mo8BUIBbAH38SUTNd81f+MDzAx35OBs+EEbRMNR8Y bIhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:autocrypt:openpgp:from:references:to:subject; bh=ycD179ki9ndS3JlWNJGjK/H/YLCxzyX+r+msJMPO9SM=; b=SxhAfjngopfEJ2jSTfe8Oakpta7t6NmSqZCU/+7WkUOA1bwdhYwv/zwNe8zp8wBajy bPZMDto3ihtOWfB4iyB+I/7PVyq6lZRYwF2qDGW08tk2GOhGCLZ8bNFtmCN5gghjn4RX hwNvB4a9EhVxK7Mlg9UMcme7eb0jsafaiwT1THX26TKvGZXsM2qCu97YeZDYoMYj9f9z 44izxPIeUztVie+3rq3wzanxJxNZ+/Ykg7iHB2XO+iijslOtvoe5HnPFeDfD5cfx+FIj QTRHVmCEG9iyEQI78iXzBSCiEWadPYg0ZROWqu+H+XvjfUmqCIUZXkreyPT9ZSM7+kAs w0dA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l124si2253830pfl.284.2018.12.11.02.30.32; Tue, 11 Dec 2018 02:30:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726272AbeLKK3n (ORCPT + 99 others); Tue, 11 Dec 2018 05:29:43 -0500 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]:60727 "EHLO outpost1.zedat.fu-berlin.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726114AbeLKK3m (ORCPT ); Tue, 11 Dec 2018 05:29:42 -0500 Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1gWfHv-000yHy-0f>; Tue, 11 Dec 2018 11:29:15 +0100 Received: from suse-laptop.physik.fu-berlin.de ([160.45.32.140]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-SHA:128) (envelope-from ) id <1gWfHu-000Zgt-Ln>; Tue, 11 Dec 2018 11:29:14 +0100 Subject: Re: Can we drop upstream Linux x32 support? To: Andy Lutomirski , X86 ML , LKML , Linux API , "H. Peter Anvin" , Peter Zijlstra , Borislav Petkov , Florian Weimer , Mike Frysinger , "H. J. Lu" , Rich Felker , x32@buildd.debian.org, Arnd Bergmann , Will Deacon , Catalin Marinas , Linus Torvalds References: From: John Paul Adrian Glaubitz Openpgp: preference=signencrypt Autocrypt: addr=glaubitz@physik.fu-berlin.de; keydata= xsFNBE3JE9wBEADMrYGNfz3oz6XLw9XcWvuIxIlPWoTyw9BxTicfGAv0d87wngs9U+d52t/R EggPePf34gb7/k8FBY1IgyxnZEB5NxUb1WtW0M3GUxpPx6gBZqOm7SK1ZW3oSORw+T7Aezl3 Zq4Nr4Nptqx7fnLpXfRDs5iYO/GX8WuL8fkGS/gIXtxKewd0LkTlb6jq9KKq8qn8/BN5YEKq JlM7jsENyA5PIe2npN3MjEg6p+qFrmrzJRuFjjdf5vvGfzskrXCAKGlNjMMA4TgZvugOFmBI /iSyV0IOaj0uKhes0ZNX+lQFrOB4j6I5fTBy7L/T3W/pCWo3wVkknNYa8TDYT73oIZ7Aimv+ k7OzRfnxsSOAZT8Re1Yt8mvzr6FHVFjr/VdyTtO5JgQZ6LEmvo4Ro+2ByBmCHORCQ0NJhD1U 3avjGfvfslG999W0WEZLTeaGkBAN1yG/1bgGAytQQkD9NsVXqBy7S3LVv9bB844ysW5Aj1nv tgIz14E2WL8rbpfjJMXi7B5ha6Lxf3rFOgxpr6ZoEn+bGG4hmrO+/ReA4SerfMqwSTnjZsZv xMJsx2B9c8DaZE8GsA4I6lsihbJmXhw8i7Cta8Dx418wtEbXhL6m/UEk60O7QD1VBgGqDMnJ DFSlvKa9D+tZde/kHSNmQmLLzxtDbNgBgmR0jUlmxirijnm8bwARAQABzVRKb2huIFBhdWwg QWRyaWFuIEdsYXViaXR6IChGcmVpZSBVbml2ZXJzaXRhZXQgQmVybGluKSA8Z2xhdWJpdHpA cGh5c2lrLmZ1LWJlcmxpbi5kZT7CwZEEEwEIADsCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgEC F4AWIQRi/4p1hOApVpVGAAZ0Jjs39bX5EwUCWhQoUgIZAQAKCRB0Jjs39bX5Ez/ID/98r9c4 WUSgOHVPSMVcOVziMOi+zPWfF1OhOXW+atpTM4LSSp66196xOlDFHOdNNmO6kxckXAX9ptvp Bc0mRxa7OrC168fKzqR7P75eTsJnVaOu+uI/vvgsbUIosYdkkekCxDAbYCUwmzNotIspnFbx iSPMNrpw7Ud/yQkS9TDYeXnrZDhBp7p5+naWCD/yMvh7yVCA4Ea8+xDVoX+kjv6EHJrwVupO pMa39cGs2rKYZbWTazcflKH+bXG3FHBrwh9XRjA6A1CTeC/zTVNgGF6wvw/qT2x9tS7WeeZ1 jvBCJub2cb07qIfuvxXiGcYGr+W4z9GuLCiWsMmoff/Gmo1aeMZDRYKLAZLGlEr6zkYh1Abt iz0YLqIYVbZAnf8dCjmYhuwPq77IeqSjqUqI2Cb0oOOlwRKVWDlqAeo0Bh8DrvZvBAojJf4H nQZ/pSz0yaRed/0FAmkVfV+1yR6BtRXhkRF6NCmguSITC96IzE26C6n5DBb43MR7Ga/mof4M UufnKADNG4qz57CBwENHyx6ftWJeWZNdRZq10o0NXuCJZf/iulHCWS/hFOM5ygfONq1Vsj2Z DSWvVpSLj+Ufd2QnmsnrCr1ZGcl72OC24AmqFWJY+IyReHWpuABEVZVeVDQooJ0K4yqucmrF R7HyH7oZGgR0CgYHCI+9yhrXHrQpyM7BTQRNyRQuARAArCaWhVbMXw9iHmMH0BN/TuSmeKtV h/+QOT5C5Uw+XJ3A+OHr9rB+SpndJEcDIhv70gLrpEuloXhZI9VYazfTv6lrkCZObXq/NgDQ Mnu+9E/E/PE9irqnZZOMWpurQRh41MibRii0iSr+AH2IhRL6CN2egZID6f93Cdu7US53ZqIx bXoguqGB2CK115bcnsswMW9YiVegFA5J9dAMsCI9/6M8li+CSYICi9gq0LdpODdsVfaxmo4+ xYFdXoDN33b8Yyzhbh/I5gtVIRpfL+Yjfk8xAsfz78wzifSDckSB3NGPAXvs6HxKc50bvf+P 6t2tLpmB/KrpozlZazq16iktY97QulyEY9JWCiEgDs6EKb4wTx+lUe4yS9eo95cBV+YlL+BX kJSAMyxgSOy35BeBaeUSIrYqfHpbNn6/nidwDhg/nxyJs8mPlBvHiCLwotje2AhtYndDEhGQ KEtEaMQEhDi9MsCGHe+00QegCv3FRveHwzGphY1YlRItLjF4TcFz1SsHn30e7uLTDe/pUMZU Kd1xU73WWr0NlWG1g49ITyaBpwdv/cs/RQ5laYYeivnag81TcPCDbTm7zXiwo53aLQOZj4u3 gSQvAUhgYTQUstMdkOMOn0PSIpyVAq3zrEFEYf7bNSTcdGrgwCuCBe4DgI3Vu4LOoAeI428t 2dj1K1EAEQEAAcLBXwQYAQgACQUCTckULgIbDAAKCRB0Jjs39bX5E683EAC1huywL4BlxTj7 FTm7FiKd5/KEH5/oaxLQN26mn8yRkP/L3xwiqXxdd0hnrPyUe8mUOrSg7KLMul+pSRxPgaHA xt1I1hQZ30cJ1j/SkDIV2ImSf75Yzz5v72fPiYLq9+H3qKZwrgof9yM/s0bfsSX/GWyFatvo Koo+TgrE0rmtQw82vv7/cbDAYceQm1bRB8Nr8agPyGXYcjohAj7NJcra4hnu1wUw3yD05p/B Rntv7NvPWV3Oo7DKCWIS4RpEd6I6E+tN3GCePqROeK1nDv+FJWLkyvwLigfNaCLro6/292YK VMdBISNYN4s6IGPrXGGvoDwo9RVo6kBhlYEfg6+2eaPCwq40IVfKbYNwLLB2MR2ssL4yzmDo OR3rQFDPj+QcDvH4/0gCQ+qRpYATIegS8zU5xQ8nPL8lba9YNejaOMzw8RB80g+2oPOJ3Wzx oMsmw8taUmd9TIw/bJ2VO1HniiJUGUXCqoeg8homvBOQ0PmWAWIwjC6nf6CIuIM4Egu2I5Kl jEF9ImTPcYZpw5vhdyPwBdXW2lSjV3EAqknWujRgcsm84nycuJnImwJptR481EWmtuH6ysj5 YhRVGbQPfdsjVUQfZdRdkEv4CZ90pdscBi1nRqcqANtzC+WQFwekDzk2lGqNRDg56s+q0KtY scOkTAZQGVpD/8AaLH4v1w== Message-ID: <70bb54b2-8ed3-b5ee-c02d-6ef66c4f27eb@physik.fu-berlin.de> Date: Tue, 11 Dec 2018 11:29:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: 160.45.32.140 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello! I'm Debian's principal maintainer of the x32 port. On 12/11/18 2:23 AM, Andy Lutomirski wrote: > 1. It's not entirely clear that it has users. As far as I know, it's > supported on Gentoo and Debian, and the Debian popcon graph for x32 > has been falling off dramatically. I don't think that any enterprise > distro has ever supported x32. There are definitely some users of this port. I don't know the actual number, but I hear from users from time to time. As for the popcon curve, I wouldn't say it has dropped dramatically as it was never high in the first place. > https://popcon.debian.org/stat/sub-x32.png It seems that the highest number of recorded users was 18 and it's now down to 7. Keep in mind though that popcon participation is opt-in, so the actual number of users should be higher. According to popcon, there are also only 172331 Debian installations on x86_64: > https://popcon.debian.org/ As for the enterprise support, this seems to be correct. I don't know of any enterprise distribution with x32 support either. > 2. The way that system calls work is very strange. Most syscalls on > x32 enter through their *native* (i.e. not COMPAT_SYSCALL_DEFINE) > entry point, and this is intentional. For example, adjtimex() uses > the native entry, not the compat entry, because x32's struct timex > matches the x86_64 layout. But a handful of syscalls have separate > entry points -- these are the syscalls starting at 512. These enter > through the COMPAT_SYSCALL_DEFINE entry points. > > The x32 syscalls that are *not* in the 512 range violate all semblance > of kernel syscall convention. In the syscall handlers, > in_compat_syscall() returns true, but the COMPAT_SYSCALL_DEFINE entry > is not invoked. This is nutty and risks breaking things when people > refactor their syscall implementations. And no one tests these > things. Similarly, if someone calls any of the syscalls below 512 but > sets bit 31 in RAX, then the native entry will be called with > in_compat_set(). > > Conversely, if you call a syscall in the 512 range with bit 31 > *clear*, then the compat entry is set with in_compat_syscall() > *clear*. This is also nutty. I can't say anything about the syscall interface. However, what I do know is that the weird combination of a 32-bit userland with a 64-bit kernel interface is sometimes causing issues. For example, application code usually expects things like time_t to be 32-bit on a 32-bit system. However, this isn't the case for x32 which is why code fails to build. Additionally, x32 support in many applications is either rudimentary or broken. For example, while LLVM has support for x32, the backend isn't really stable on this target meaning that compilers like clang or Rust are partially broken or crash. I'm not sure whether anyone is interested in fixing this. It's also that the performance benefits of x32 are often eaten up by the fact that none of the scripted languages that I know of provide a JIT that supports x32. Thus, things like Javascript are either unsupported or slow on x32. > I propose that we make CONFIG_X86_X32 depend on BROKEN for a release > or two and then remove all the code if no one complains. If anyone > wants to re-add it, IMO they're welcome to do so, but they need to do > it in a way that is maintainable. I'm not terribly opposed to this change. I'm usually for keeping support for things that people are using, but the maintenance is a huge burden to upstream projects, I'm fine with letting it go. There are other architectures in the kernel like Alpha, HPPA, M68K, PowerPC, SH and SPARC that I care much more about than x32. If x32 is eventually to be removed, we should also take care of removing x32 support from userland code. From the top of my head, this would at least concern: * OpenJDK * LLVM * gcc * glibc * Rust * binutils I can take care of these once I know about the decision regarding the kernel. Usually, it's a matter of grepping the commit history for "x32" and revert the corresponding commits. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913