Received: by 10.213.65.68 with SMTP id h4csp1023929imn; Sun, 18 Mar 2018 11:20:58 -0700 (PDT) X-Google-Smtp-Source: AG47ELvcGOo8URZR40g/hXfB7vuGwYyTIryAdIDy8uXFnYLzVrBaosHU/rgsJU7TER8CZuuEtTN7 X-Received: by 10.101.76.207 with SMTP id n15mr7191847pgt.313.1521397258342; Sun, 18 Mar 2018 11:20:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521397258; cv=none; d=google.com; s=arc-20160816; b=IDIFmpgT8YJwc3N9V1idLV2TNHNkGif+Y3M/ySaxVeE1/5LpmCmRICa+J3O0sVxc3V b4jNJ83p/xQfqEAJQqu1auc3cOMQtqcPHtFwPU18Iq2j14eWW0C1pfIoVirRZmZI5vlf d9uPRUpaMKGI4meF1XHWLDIuWUFreV5/1Yw1cq+VdIOB0zrFpMh2/vHWU+6AqF1S8/0O e7BTAW+TpvafXyNXWY4ZrGrywY0rOLl6A614j5Gr1s7DaUrzzLzXSgrQSS6P+o8qR9aS nps4MiL5Ohz1AJ+MNj+tE/ESad6amoslfCAb6hglka2E5nx3jfSUIg59om20SwOfAaHh MZpw== 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=IxTM6S3HPVUlBzRiqKmrF1qqpa+FRwVNBiUgDBEkwGc=; b=SfSRddvBnkVxFZujxgn3eO9koYp7ngznH+rwxqsfdlzLGiSt1H3H7e8Obq+zA7gXak hp4tbqFhP3Ol35UHJd1bfy8dClvpANlYbuN/d6/vslgzaj2KZ6shQ8xVhGSlZVRPcUMC 9gZg3F0VKqscs0BnOJdLbvN6P5K9rTziupHPWAZb09/gwZ2YE+4xv4bPnLZAIIXbwkJr BQKvCcjD8ZeKBY0K4jsfvN7ZnUNfzaMizqpK10fkuaxNzmPBok5FRtsgqPQdszqAAqqa 6Oh/6t855ZtXJxsfCWsceV10edhVGiCND0fADuK4AiDHXRLmOp+gv4Fw23UvsrVUAe4C cAUg== 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 g1si8513742pge.636.2018.03.18.11.20.31; Sun, 18 Mar 2018 11:20:58 -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 S1754088AbeCRSS4 (ORCPT + 99 others); Sun, 18 Mar 2018 14:18:56 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:41370 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750766AbeCRSSy (ORCPT ); Sun, 18 Mar 2018 14:18:54 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1exctM-000830-BM; Sun, 18 Mar 2018 18:18:48 +0000 Date: Sun, 18 Mar 2018 18:18:48 +0000 From: Al Viro To: Linus Torvalds Cc: Dominik Brodowski , 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: <20180318181848.GU30522@ZenIV.linux.org.uk> References: <20180318161056.5377-1-linux@dominikbrodowski.net> <20180318161056.5377-5-linux@dominikbrodowski.net> <20180318174014.GR30522@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 18, 2018 at 11:06:42AM -0700, Linus Torvalds wrote: > and then we can do > > COMPAT_SYSCALL_DEFINE5(readahead, int, fd, > COMPAT_ARG_64BIT_ODD(off), compat_size_t, count) > { > return do_readahead(fd, off_lo + ((u64)off_hi << 64), count); > } > > which at least looks reasonably legible, and has *zero* ifdef's anywhere. It's a bit more complicated, but... > I do *not* want to see those disgusting __ARCH_WANT_LE_COMPAT_SYS > things and crazy #ifdef's in code. Absolutely. Those piles of ifdefs are unreadable garbage. > So either let the architectures do their own trivial wrappers > entirely, or do something clean like the above. Do *not* do > #ifdef'fery at the system call declaration time. > > Also note that the "ODD" arguments may not be the ones that need > padding. I could easily see a system call argument numbering scheme > like > > r0 - system call number > r1 - first argument > r2 - second argument > ... > > and then it's the *EVEN* 64-bit arguments that would need the padding > (because they are actually odd in the register numbers). The above > COMPAT_ARG_64BIT[_ODD]() model allows for that too. > > Of course, if some architecture then has some other arbitrary rules (I > could see register pairing rules that aren't the usual "even register" > ones), then such an architecture would really have to have its own > wrapper, but the above at least would handle the simple cases, and > doesn't look disgusting to use. I'd done some digging in that area, will find the notes and post. Basically, we can even avoid the odd/even annotations and have COMPAT_SYSCALL_DEFINE... sort it out. It's a bit more hairy than I would like at this stage in the cycle, though. I'll see if it can be done without too much PITA. However, there still are genuinely speci^Wfucked in head cases - see e.g. this sad story: commit ab8a261ba5e2dd9206da640de5870cc31d568a7c Author: Helge Deller Date: Thu Jul 10 18:07:17 2014 +0200 parisc: fix fanotify_mark() syscall on 32bit compat kernel Those certainly ought to stay in arch/*