Received: by 10.213.65.68 with SMTP id h4csp1018805imn; Sun, 18 Mar 2018 11:08:55 -0700 (PDT) X-Google-Smtp-Source: AG47ELuKli9NzjWed+z7ba3/Egb86Skuwf/mgzPQgUaGXW7W6dtspXdx7CwMxW4dqPHeYGhObrmV X-Received: by 2002:a17:902:9a05:: with SMTP id v5-v6mr9604325plp.69.1521396535533; Sun, 18 Mar 2018 11:08:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521396535; cv=none; d=google.com; s=arc-20160816; b=rrwB/ftQOY9DAQ6VLVUXzRLnQ3kPjY2Ae+jCcS2S2Gm7jS/AIBZzEP9Bx/kHJijA3c 1kH6sBV7QwFPxUkBDsIaGLndKJJ5BYm/H8FVWEPQ8JsNdOKVo5ZvH3acp80d2WI7+s0l 98+8OSJ08VKDNZQMmzMGIBbcBsiagXem3zSVi94FnUUY1c+3iYr369wSjJ/6AoNqOnrP osjwDDvt3C5SZok/OJtcYzpVANMVgdu4DFJCi75mlH5iUt3BJvAXexheURS+Q8Dx0Qjq nD5BI5hSd66n8zrT3qtWO39ZoKOwoPOrZdc6PCpO8LSN/3OW6xsEcVvFkI9dcIEOam1L KmTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=R2mdIDiX0O2X6zQ+Um6PJojTvpx92Iclh0EKvgLNrzU=; b=Nehp7Gu76Z40myCdZC+2gHms7xf7wyVf9pvDryhAnzcra09vKqLfhHqIyLrjLGrGu4 +tzz4moPGCjxCjaj4toJ8HJwABPO6Mk4va+D6U3aSgMFGl56bsWJq5QW+HuEe/aijpDF MKFBjji13GX6uqrSaP7W/lsp1O5z7TmTWGXY77WTlGwjxqBVvNktbQgcjrswunaqB91a U2Sz5fJWCYF5O25OSNaJx4Ea1AhcTs4D58Cc3yixh7NwpbzRVxFs2cC/0Fnd+OKlXKFp 4QhylDbwlqdXVlcW+rmwNIYeNvqug8amGM1fopcwfqFB5Pas9fhsHiB/MDh9+D6H9qBF yX8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=SDtniej/; dkim=fail header.i=@linux-foundation.org header.s=google header.b=Rol8Koll; 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 c12-v6si10406059pll.498.2018.03.18.11.08.41; Sun, 18 Mar 2018 11:08:55 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=SDtniej/; dkim=fail header.i=@linux-foundation.org header.s=google header.b=Rol8Koll; 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 S1754513AbeCRSGt (ORCPT + 99 others); Sun, 18 Mar 2018 14:06:49 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:38934 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754205AbeCRSGo (ORCPT ); Sun, 18 Mar 2018 14:06:44 -0400 Received: by mail-it0-f65.google.com with SMTP id e98-v6so7592671itd.4; Sun, 18 Mar 2018 11:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=R2mdIDiX0O2X6zQ+Um6PJojTvpx92Iclh0EKvgLNrzU=; b=SDtniej/3DA7LpMnIKoa2mQ8ZKUaGmXYhpliZ+vFBILa/jNXsUqX6GvEUSsuW2ya89 //tHLhKU/IGkWP9/SkPeOh3WuQLDFqrwADSLX/oixD/4PppDsTuINWdway3fPgbtaIaR o+sb1XyKWTnwwjmvbHdAnaRmiVmgKw21sj4yiBGC+pq1rIghzXkPOJHQ4cx3NNW8QQAp PWEhv1BGJrIx1akJQtF7FawI/lfQex7kJS40GY6Due3bTZH69yDd/Yn4pWStuftY4Oo/ K6n8/Mx+8yrWbpcQ9AUUJIEUI5dUB2WHn3vkK/tmDYGISjkW4IsrAHgvH0vJ0WS3wDNb SHMg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=R2mdIDiX0O2X6zQ+Um6PJojTvpx92Iclh0EKvgLNrzU=; b=Rol8KollVeYUA390Tmo6JcYiDqqKI4NB3IRSsPIkWAm+dKzKS9G19DGD9Mh+X8nk0R SYwj2eD1oGDyHqt101xlleWlzTHPO44DBWN89suQVs+Za23sRZ8TD4Hdiox7fD0ym1XJ xhXY8TrQ85lw1O/Nwatdr2h7qjhWNkyEdvBVs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=R2mdIDiX0O2X6zQ+Um6PJojTvpx92Iclh0EKvgLNrzU=; b=nk1+oI0e9g0DFW609QwQwwR1rMZ515EcXlKj+GooDBsI4BYd+cZFc6GVMFoiSyzD+J 9n90in5VEKgCkMF8EQL1sJwGNZR7ba73+fMU1jztq9lH+ca+0LimtwZEzYzNE6QIuWfb SCtW2uWehd2FwgyxfkMJuibyrXCz7vKLAmu3FAm5nKq7zqvrm6qlxiwJK3/V/PmqGAxy UQcoZ+eJPumA29rv5muyGxZp0DnwvF6KZ6K19t9zVTyozp28zBtO+32JhZNc1a7Sp4nE Dhc6gcmi5REGB5GIO2NYBgRDhGvAAVg6pwLMlXL2O2yR3IIm08SuWnTBRfEi3HzErLCD AoXg== X-Gm-Message-State: AElRT7HBw7/77+nTzisUjmM3S1GgB1XTn7Jjnv6xrGK1X/qxC61ALTns 5StobKO69bX0uvrdcoX2dhfQJEXTx9aOV+Y3C+XD197c X-Received: by 2002:a24:9985:: with SMTP id a127-v6mr3780976ite.108.1521396403072; Sun, 18 Mar 2018 11:06:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.95.15 with HTTP; Sun, 18 Mar 2018 11:06:42 -0700 (PDT) In-Reply-To: <20180318174014.GR30522@ZenIV.linux.org.uk> References: <20180318161056.5377-1-linux@dominikbrodowski.net> <20180318161056.5377-5-linux@dominikbrodowski.net> <20180318174014.GR30522@ZenIV.linux.org.uk> From: Linus Torvalds Date: Sun, 18 Mar 2018 11:06:42 -0700 X-Google-Sender-Auth: MuT1J1o-KOERyus1oFemTYP053A Message-ID: Subject: Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation To: Al Viro 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" Content-Type: text/plain; charset="UTF-8" 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 10:40 AM, Al Viro wrote: > > *UGH* > > static inline compat_to_u64(u32 w0, u32 w1) > { > #ifdef __BIG_ENDIAN > return ((u64)w0 << 32) | w1; > #else > return ((u64)w1 << 32) | w0; > #endif > } > > in compat.h, then this turns into > > #ifdef __ARCH_WANT_COMPAT_SYS_WITH_PADDING > COMPAT_SYSCALL_DEFINE5(readahead, int, fd, unsigned int, padding, > u32, off0, u32 off1, > compat_size_t, count) > #else > COMPAT_SYSCALL_DEFINE4(readahead, int, fd, > u32, off0, u32 off1, > compat_size_t, count) > #endif No. This is still too ugly to live. What *may* be acceptable is if architectures defined something like this: x86: /* Little endian registers - low bits first, no padding for odd register numbers necessary */ #define COMPAT_ARG_64BIT(x) unsigned int x##_lo, unsigned int x##_hi #define COMPAT_ARG_64BIT_ODD(x) COMPAT_ARG_64BIT(x) ppc BE: /* Big-endian registers - high bits first, odd argument pairs padded up to the next even register */ #define COMPAT_ARG_64BIT(x) unsigned int x##_hi, unsigned int x##_lo #define COMPAT_ARG_64BIT_ODD(x) unsigned int x##_padding, COMPAT_ARG_64BIT(x) 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. I do *not* want to see those disgusting __ARCH_WANT_LE_COMPAT_SYS things and crazy #ifdef's in code. 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. Linus PS. It is possible that we should then add a #define COMPAT_ARG_64BIT_VAL(x) (x_##lo + ((u64)x_##hi << 32)) and then do COMPAT_SYSCALL_DEFINE5(readahead, int, fd, COMPAT_ARG_64BIT_ODD(off), compat_size_t, count) { return do_readahead(fd, COMPAT_ARG_64BIT_VAL(off), count); } because then we could perhaps generate the *non*compat system calls this way too, just using #define COMPAT_ARG_64BIT(x) unsigned long x #define COMPAT_ARG_64BIT_VAL(x) (x) instead (there might also be a "compat" mode that actually has access to 64-bit registers, like x32 does, but I suspect it would have other issues).