From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Glaser Subject: Re: Can we drop upstream Linux x32 support? Date: Tue, 11 Dec 2018 23:35:36 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: Content-Language: de-DE-1901, en-GB Sender: linux-kernel-owner@vger.kernel.org To: Andy Lutomirski Cc: Linus Torvalds , 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 List-Id: linux-api@vger.kernel.org Andy Lutomirski dixit: >What happens if someone adds a struct like: > >struct nasty_on_x32 { > __kernel_long_t a; > void * __user b; >}; > >On x86_64, that's two 8-byte fields. On x86_32, it's two four-byte >fields. On x32, it's an 8-byte field and a 4-byte field. Now what? Yes, that’s indeed ugly. I understand. But don’t we already have this problem with architectures which support multiple ABIs at the same time? An amd64 kernel with i386 userspace comes to mind, or the multiple MIPS ABIs. >I'm sure we could have some magic gcc plugin or other nifty tool that >gives us: > >copy_from_user(struct struct_name, kernel_ptr, user_ptr); Something like that might be useful. Generate call stubs, which then call the syscall implementation with the actual user-space struct contents as arguments. Hm, that might be too generic to be useful. Generate macros that can read from or write specific structures to userspace? I think something like this could solve other more general problems as well, so it might be “nice to have anyway”. Of course it’s work, and I’m not involved enough in Linux kernel programming to be able to usefully help with it (doing too much elsewhere already). >actually do this work. Instead we get ad hoc fixes for each syscall, >along the lines of preadv64v2(), which get done when somebody notices Yes, that’s absolutely ugly and ridiculous and all kinds of bad. On the other hand, from my current experience, someone (Arnd?) noticed all the currently existing baddies for x32 already and fixed them. New syscalls are indeed an issue, but perhaps something generating copyinout stubs could help. This might allow other architectures that could do with a new ABI but have until now feared the overhead as well. (IIRC, m68k could do with a new ABI that reserves a register for TLS, but Geert would know. At the same time, time_t and off_t could be bumped to 64 bit. Something like that. If changing sizes of types shared between kernel and user spaces is not something feared…) Thanks for considering, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)