From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) by sourceware.org (Postfix) with ESMTPS id A14A13858D39 for ; Sat, 11 Dec 2021 22:30:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A14A13858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=arndb.de Received: from mail-wr1-f41.google.com ([209.85.221.41]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.97]) with ESMTPSA (Nemesis) id 1N1cvQ-1mY9m20PIe-0123Z2 for ; Sat, 11 Dec 2021 23:30:22 +0100 Received: by mail-wr1-f41.google.com with SMTP id d24so21017667wra.0 for ; Sat, 11 Dec 2021 14:30:22 -0800 (PST) X-Gm-Message-State: AOAM531H0fbayPtEOrp/55uNdbtOv1h88cXUTL5q8gTFb+5WJpxfldt2 2lW/tdNSsemXAiUL0opSlqS6HCFzook+h20FbXw= X-Google-Smtp-Source: ABdhPJw0vXXc5qJWBHb76Yl3jO/k125t0NNrCRcelZ9TQOHFk7mNeOyxY4Glgspw3l8E6V3Rc7ebLWafNd/N0UxzF6E= X-Received: by 2002:a5d:6902:: with SMTP id t2mr22179013wru.317.1639261821728; Sat, 11 Dec 2021 14:30:21 -0800 (PST) MIME-Version: 1.0 References: <20211210110233.1401640-1-adhemerval.zanella@linaro.org> <87mtl879ch.fsf@oldenburg.str.redhat.com> <20211211000844.GB7074@brightrain.aerifal.cx> <49f9e2d0-3252-78a6-0395-8901d82772fe@cs.ucla.edu> <20211211144906.GC7074@brightrain.aerifal.cx> In-Reply-To: <20211211144906.GC7074@brightrain.aerifal.cx> From: Arnd Bergmann Date: Sat, 11 Dec 2021 23:30:05 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] linux: Use 'long int' for timespec tv_nsec on x32 (BZ #16437) To: Rich Felker Cc: Arnd Bergmann , Paul Eggert , GNU C Library development , Andy Lutomirski Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:gbAAf8+tragFJE+jyLuSpNhv/PXVQaRIU6a3k6T5C0paoHmnjrI jEy8ZXh3vLtWVHQt536ng9wm+cslp24wzNMeluoy9Z7jNfYfJmandWOyUYcsGFcX96WfgRL qDyqiafb8fm++dixuncf//eXDjbXmDc73yFBsfkkV6l3z762xZHxU2dlTaSDFdPq2yCEYu3 GNwJvAD5yL4jKqv+UEmSg== X-UI-Out-Filterresults: notjunk:1;V03:K0:Jc1mEGByC9I=:CBKBw18Z/2AF/PtODxl73D hHjBqZfBqrSuan1O2yvYKu0vLdWRYPJVP9CkZneA/OFJejVUMnslTddg/4mow0/2ixmBEs9ot xe8UeNUi6PgA0CYIM36b3UFDE43NyG4OWIW2j2H0RL7OrHhbEjdp0XCd+nFQ2HN/CSGpb23i0 hc1aKvfjJgtafJ6z/iNO9/tDiMmC7W9siJ6Y3I7q9tEpUjYS8RAG5Evv4Uwuu2KyT1cLzHXAS HCFji3Sid7CraFvOxql7JMEGb0HEMKmz+IQZLfWWFnUte9lawZFn5XBdNtvOIRAD4YEIgnw7t Vm79urqRG4v9w0wbH986rSevBea7vEy6uDWW54V470Qo/G5gmsPBsWhE87S5vLPsO+jjBUgSm AUdsar3V+lGlZqNCHraZTHjKi99tgCKOG61/r4wPGyiEvR5BAFSxPm5iACJrkooX2j7JfE2lu yZ1WZgQus8/s2XHPyAuTLXY0+NYRUVnBs54k+3E7fRdM00RvOdQBnhIhpXLaUGBJe1EJt5E8v Y8G66vwo7iAdWet/bB+hySWZrC4EualEcljXlJktyDLsGxPjNCjx1OCcmcZY2kXTTcLTAudcM Fy48tOL0vSuetNIjaoJO69nvdFWz8z+BaKRkYbczrinrX9pYmc+mf9Lha9wygu/+p+flICev5 0ns9g10kcdhiJ9JCuJ/K6QByK6mY9U+gRJ53bQVfPBKfC5o/y8Y0zYVwmkoEBeR4YLZI= X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2021 22:30:26 -0000 On Sat, Dec 11, 2021 at 3:49 PM Rich Felker wrote: > > I know this would make things easier for kernel folks, but I'd really > like to avoid removal and especially avoid being part of the impetus > for removal. I suspect a large portion of real-world x32 users are > musl users, and musl's x32 port has never had the problem this thread > is about. Do you know of actual users, or products shipping with x32 musl? My assumption was that there are not really, and that it would just be an easy way to end a pointless email discussion ;-) > If there is renewed desire for removal, could we look at doing it in a > way that enables moving support to userspace? That might actually > already be possible with the framework that was added for intercepting > syscalls (for wine) and binfmt_misc. There is some ongoing debate on doing foreign-architecture system calls, which would work here, but I don't think this is happening soon. There isn't much code that is involved in x32 support in the kernel, but it is in rather tricky places: - ELF loader is separate, but can probably be done as a binfmt-misc loader the way that qemu-user does it without too much trouble - address space limitation is something we should really have in the kernel, as there are several use cases for that, this is mainly a question of defining a new syscall or other ABI to set it from user space - most system calls are either the normal x86-64 version or the x86-32 version for x32, so this is a question of calling the right one. I think that x86 still allows calling either one - not sure about signal handling, the kernel currently does it differently for x32 tasks, and my assumption was that the reason is that this can't be easily emulated in libc on top of x86-64 signals. - the hardest part are the ioctl (and similar syscalls) with arguments that are incompatible between x86-32 and x32, which usually happens because of misaligned 'long long' having different padding. x32 ioctl is compatible with most other architectures here, so this requires the generalized ioctl syscall that lets user space pick between more ABIs. Arnd