Received: by 10.213.65.68 with SMTP id h4csp233115imn; Tue, 20 Mar 2018 01:59:52 -0700 (PDT) X-Google-Smtp-Source: AG47ELvKkOv5BgHk9hLva7XPKlCP4z0Q4wz1aK3kBZ5Y7Kie781YCqGvNz8lHpJ693G04EPiufrK X-Received: by 2002:a17:902:788e:: with SMTP id q14-v6mr16146035pll.396.1521536392532; Tue, 20 Mar 2018 01:59:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521536392; cv=none; d=google.com; s=arc-20160816; b=gG65+MuHq8HUabl466tngm5Dc8DlXwpBHKgX9QNQ6hsaGVcPApWvRg2v+Wm4feZPaa WJbaYml1NYKo2x3vxCS9oa01ykBSwUvU0IFqsem5lQZLFJdhUve4qUkRJp33J990MnnE OAP9SMIAhvLi1vHH5JmkgjPEc2q9xKbvmMBJEJ+rOvHT2wEBvhckr6/lphhoHoDQm70h 6zrv4UQCORYashsQAn0ZxTNaYj8TYSAqiZtmpHZzuRFY6toCb4ISlNL17fxQz/eG/WgQ Lsai1lTSoWUDJN3S+7c07YKudH+tk9Zqr6p2Knwx1mJ4WONXjWmptU+cf5ep+uzpZ9Gs 1R5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=0O/l4hbelllj7ZWhGxJkKQUd40J0eK1vyvwP5qzKi5Y=; b=FTXwrMIizNaXAwr3j3oTIYswlQOqOX9Kkn+6Xoo9AIwYENz/i4W+4P+vxMj/NHs5IP Y7B77/n/DLeJk9eYKn+8QYTHEV0whAPeZEbMqN/Nu7rWRebkOPpg2bvS8W5fHMTsP56N L05d0ZX5edo2TkfXWj+G1btKphidsz6gxlwaStVWEzq4gSxkNLx/+GpVhfvoydwSQ3sy /GAFadzB7hq7cW2bHngYNDKl7CZlTCK6NOKBeGw/EbYTuCYf9euh1mC8vSIgwaLlV6jO Z57yCFg23UBEZOe2s6nifHzb6RL5ARWdbYBw1v+xyA8C9oVvlvN2KCLvm5vkBPkgOPyU onlQ== 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 w130si986652pfd.280.2018.03.20.01.59.35; Tue, 20 Mar 2018 01:59:52 -0700 (PDT) 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 S1752347AbeCTI5E (ORCPT + 99 others); Tue, 20 Mar 2018 04:57:04 -0400 Received: from isilmar-4.linta.de ([136.243.71.142]:34472 "EHLO isilmar-4.linta.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751790AbeCTI5B (ORCPT ); Tue, 20 Mar 2018 04:57:01 -0400 Received: from light.dominikbrodowski.net (isilmar.linta [10.0.0.1]) by isilmar-4.linta.de (Postfix) with ESMTPS id AA3962008FF; Tue, 20 Mar 2018 08:56:59 +0000 (UTC) Received: by light.dominikbrodowski.net (Postfix, from userid 1000) id 85DF620B3D; Tue, 20 Mar 2018 09:56:32 +0100 (CET) Date: Tue, 20 Mar 2018 09:56:32 +0100 From: Dominik Brodowski To: Al Viro Cc: Ingo Molnar , Linus Torvalds , Linux Kernel Mailing List , Arnd Bergmann , linux-arch , Ralf Baechle , James Hogan , linux-mips , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , ppc-dev , Martin Schwidefsky , Heiko Carstens , linux-s390 , "David S . Miller" , sparclinux@vger.kernel.org, Ingo Molnar , Jiri Slaby , the arch/x86 maintainers Subject: Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation Message-ID: <20180320085632.GB30383@light.dominikbrodowski.net> References: <20180318161056.5377-1-linux@dominikbrodowski.net> <20180318161056.5377-5-linux@dominikbrodowski.net> <20180318174014.GR30522@ZenIV.linux.org.uk> <20180318181848.GU30522@ZenIV.linux.org.uk> <20180319042300.GW30522@ZenIV.linux.org.uk> <20180319092920.tbh2xwkruegshzqe@gmail.com> <20180319232342.GX30522@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180319232342.GX30522@ZenIV.linux.org.uk> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 19, 2018 at 11:23:42PM +0000, Al Viro wrote: > static inline long C_S_moron(int, loff_t, size_t); > long compat_SyS_moron(long a0, long a1, long a2, long a3, long a4, long a5, long a6) > { > return C_S_moron((__force int)a0, > (__force loff_t)(((u64)a2 << 32)|a1), > (__force size_t)a3); > } > static inline long C_S_moron(int fd, loff_t offset, size_t count) > { > whatever body you had for it > } > > That - from > COMPAT_SYSCALL_DEFINE3(moron, int, fd, loff_t, offset, size_t, count) > { > whatever body you had for it > } > > We can use similar machinery for SYSCALL_DEFINE itself, so that > SyS_moron() would be defined with (long, long, long, long, long, long) > as arguments and not (long, long long, long) as we have now. That would be great, as it would allow to use a struct pt_regs * based syscall calling convention on i386 as well, and not only on x86-64, right? > It's not impossible to do. It won't be pretty, but that use of local > enums allows to avoid unbearably long expansions. > > Benefits: > * all SyS... wrappers (i.e. the thing that really ought to > go into syscall tables) have the same type. > * we could have SYSCALL_DEFINE produce a trivial compat > wrapper, have explicit COMPAT_SYSCALL_DEFINE discard that thing > and populate the compat syscall table *entirely* with compat_SyS_..., > letting the linker sort it out. That way we don't need to keep > track of what can use native and what needs compat in each compat > table on biarch. > * s390 compat wrappers would disappear with that approach. > * we could even stop generating sys_... aliases - if > syscall table is generated by slapping SyS_... or compat_SyS_... > on the name given there, we don't need to _have_ those sys_... > things at all. All SyS_... would have the same type, so the pile > in syscalls.h would not be needed - we could generate the externs > at the same time we generate the syscall table. > > And yes, it's a high-squick approach. I know and I'm not saying > it's a good idea. OTOH, to quote the motto of philosophers and > shell game operators, "there's something in it"... ... and getting rid of all in-kernel calls to sys_*() is needed as groundwork for that. So I'll continue to do that "mindless" conversion first. On top of that, three things (which are mostly orthogonal to each other) can be done: 1) ptregs system call conversion for x86-64 Original implementation by Linus exists; needs a bit of tweaking but should be doable soon. Need to double-check it does the right thing for IA32_EMULATION, though. 2) re-work initramfs etc. code to not use in-kernel equivalents of syscalls, but operate on the VFS level instead. 3) re-work SYSCALL_DEFINEx() / COMPAT_SYSCALL_DEFINEx() based on your suggestions. Does that sound sensible? Thanks, Dominik