From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 903863128CC for ; Sun, 3 May 2026 22:38:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777847938; cv=none; b=GNTOxUHbWTVoPz4zPc/XeZZfU6aVecofPxU6evxklCVQ+0Ca7db+be0+zy1j9meL1IhskocOnevGJdQFWxtE90TFeDqFxWKI0jt5WcD7cq0nVOxKNP+8jRFKhEe7Ye1YeEQwCnckbqRXIWFl7xlu6YN4VfPjsMfjZ3jjnCW3YXk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777847938; c=relaxed/simple; bh=ZFF6BMj7VZNJLJ7+zyVLvucgl5zxw131Jj00n7biB8Q=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pUFTuaVUuXIcsOyDH0XmXY+AJojwoN4XK94ns5fcBmaTEJgktTyKJvJ/SSvpjy6B1zBpXqbkHHt/Y4FPhz1ZJG4RwiRFjyWfkEv+BJaoc0KII/AW4/LlQBBzfRz0WjCEDwU5qWPZvreYZYyUmbieEKdiVHmrOIY0C3KownYHbqU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jH2Bg6WY; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jH2Bg6WY" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-44985f4ab0fso1422736f8f.0 for ; Sun, 03 May 2026 15:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777847935; x=1778452735; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=jvUbJ8C3wcjpQAloc69WhAtL6XSDT7g1+fJ4sQMt8k0=; b=jH2Bg6WYyiuKb2BIod4JDKbYxwoaDdhq3XhMpJo/WPLvQGFUB9XRN5svQkpQAjMCUB RDdHDVsY2cOFlYU1dLwlubtKI7+A2e+hb1JYGjtgSn83Ke8zezPc5vXfEzbnNP5pNy4n Mr1ufTIUZehMJ7R0c5zgAfmIrKHUxSFAgzNEd1+DablKgAxAKbdw02gYZdSDxWn0d0aG gw5HkxqknbHZ5LoqQbGa1HAELLzFuZYjjVUMSEUt/8ihsfDeAVxr3cPsm6PorZxlre+G ZDoO6hH9CPfm0eOd7D4gPwucxQ4QNlzKQv2WcNtt1j4gpJrzp87xJP5y0Vs+EWpqn1T3 UBfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777847935; x=1778452735; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=jvUbJ8C3wcjpQAloc69WhAtL6XSDT7g1+fJ4sQMt8k0=; b=OVzudgJBZphcvkFFM8lPVW457rfE6B1MXSFfSb4A9F8i76nL8aPIkSMtLJWVOn+xNn cvtcC7bf7LiDitpEm4X3NhbyfLJwN8z+FXba54yG4HS2PP2la756X6PN+Ms65tgQNWPk S3DOgPs4CitHnMoLkTcdTN5BOcW+ekKGOk6WNB6zGSQI3qKvOld1DyIkiQiSruLB/K1t Hg2u4qNk786wLeWchu77iDD2nhs5iEpPvdAc0HmBG5dz8urCdVOsy24g9VMlNidSVXEe GwmsofjvLKXUG1GO/OXdbSVHl11KBjSuA2K8JJO7czB32oSIFYnErjKWr57uFrR9JuCV hpNw== X-Forwarded-Encrypted: i=1; AFNElJ+V/VRz7GlDyXjFwupR1s2dXWVs4MMOehCd8OSUu1DWCBO+MspOF6q4jbozinGCLtFfEZI52ss21zt2txY=@vger.kernel.org X-Gm-Message-State: AOJu0YyLg27TZXMWSQQf/E2UIBWvM4Q+FQs4moCgVW2zHNNR1BRGXhvQ awCDH5lGXxUJ7ngq+tHp9UR3TFr6mTXwk6pLMeEZaqx+CEv7bckwOCKSY9N8RqUn X-Gm-Gg: AeBDieu/ZU80Eu3ASH683cgnZrVAHVIDlncXdtoo3aY6VHn/4cgmoalfSrxKhctDkb9 am+3RI5DRaIdGaB79I7N8IX0baVzFscgiDRRKaxgkmBfnQkIFC+TnyurqI0HLMQCZZN6A3uHaPL AK863HA1i2MFxxvLIgMy66Zyqr7xuJthl6dxQxL0FPuhR2n9heKzlEe8bXwy1wuF49FaaJzCuF0 KCV4seap+ll6NO3pNpzKNijIxSHEh7kEnpJak6Yh7EvPoGtRo1ukVtmWAEorjfoedlehsCGW8Ek +Lmw47iKRSbrtRKnlckWA4eMbcSlw3tgVrO9VLiCk66Y3e8ZwtysHY3QmYpj/5lX9r3e6yV8NAz WKzw4fXMmOwWmyMKFALAr99ldtxQLjKHSR6koX0pztBGhiF1icO/5kzooZ5gdQX/cm7FCmLUdME yqYhrgRoPKqi7raJy9t08A3tJW71ma6yYPsqV6BXmflA3T+Qp2X8ZFMXFnq02Q6HfsZaMPqEtqr 30= X-Received: by 2002:a5d:5d0b:0:b0:449:c1e8:7655 with SMTP id ffacd0b85a97d-44bb64ea9f3mr12426630f8f.27.1777847934649; Sun, 03 May 2026 15:38:54 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-44a9879ef45sm22171986f8f.32.2026.05.03.15.38.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 May 2026 15:38:54 -0700 (PDT) Date: Sun, 3 May 2026 23:38:52 +0100 From: David Laight To: Thomas =?UTF-8?B?V2Vpw59zY2h1aA==?= Cc: Willy Tarreau , Daniel Palmer , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/2] tools/nolibc: fcntl: Add fallocate() Message-ID: <20260503233852.3f950b63@pumpkin> In-Reply-To: References: <20260430164125.1106350-1-daniel@thingy.jp> <20260430164125.1106350-2-daniel@thingy.jp> <20260501091831.7abc39f1@pumpkin> <20260502222607.4ab68291@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 3 May 2026 18:28:39 +0200 Thomas Wei=C3=9Fschuh wrote: > On 2026-05-02 22:26:07+0100, David Laight wrote: > > On Sat, 2 May 2026 05:00:06 +0200 > > Willy Tarreau wrote: > > =20 > > > On Fri, May 01, 2026 at 09:18:31AM +0100, David Laight wrote: =20 > > > > On Fri, 1 May 2026 01:41:24 +0900 > > > > Daniel Palmer wrote: =20 >=20 > (...) ... > > Looking again, the code is trying to copy what the compiler generates > > when it passes a 64bit quantity on stack or in 2 registers. > > So f(a, b, c, d) is traditionally 'push d; push c; push b, push a; call= f'. > > With the normal 'stack grows down' this gives (in increasing addresses): > > return address > > a > > b > > c > > d > > If 'b,c' is replaced by a 64bit value then you want the stack memory > > to contain the correct representation of a 64bit value. > > So for LE you need to pass the low part before the high part. =20 >=20 > Most architectures should use registers and not the stack. Indeed, but the registers are picked as though they are caching on-stack lo= cations. So the way the stack would look is relevant. >=20 > > But there is one architecture (parisc) where the stack goes the other w= ay. > > It is BE (I believe), but would need the LE argument order. > >=20 > > I think all the conditionals could be moved out of the fallocate code. > > I'm not sure of the exact pre-processor conditionals but something like: > >=20 > > #if (__BITS_PER_LONG =3D=3D 64) || defined(x86_x32) || defined(mips_n32) > > #define __NOLIBC_ARG64(x) (x) > > #else > > /* The on-stack data has to be in the natural order for a 64bit value. = */ > > #if (__BYTE_ORDER__ =3D=3D __ORDER_LITTLE_ENDIAN_) ^ defined(STACK_GROW= S_UP) > > #define __NOLIBC_ARG64(x) ((int)(x)), ((int)((long long)(x) >> 32)) > > #else > > #define __NOLIBC_ARG64(x) ((int)((long long)(x) >> 32)), ((int)(x)) > > #endif > > #endif =20 >=20 > I highly dislike macros like these which may expand to either a single > or multiple arguments. > Also this logic looks much more complicated than what Daniel proposed. I'm not sure the casts are needed. The implicit casts from the function calls may mean that it is enough to use (x) and (x) >> 32. I really didn't like the expansions Daniel proposed in sys_fallocate() itse= lf. Neither the fallocate code nor the header file really said what was going o= n. You had to read both together and then read between the lines so see why it was necessary at all.=20 > > Then (if I've got it right): > > static __attribute__((unused)) > > int _sys_fallocate(int fd, int mode, off_t offset, off_t size) > > { > > return _syscall(__NR_fallocate, fd, mode, __NOLIBC_ARG64(offset), > > __NOLIBC_ARG64(size)); > > } =20 >=20 > We intentionally use __nolibc_syscallX() inside nolibc proper over > _syscall()/syscall() to have the arity of the syscall written out. In this case the number of arguments varies - so that wouldn't work. But I can see why it would normally be better. >=20 > > There is the other problem that arm32 (and maybe others) requires the 6= 4bit > > variable be aligned in the stack frame. > > So f(int a, long long b) is effectively f(int a, int pad, long long b). > > (This usually causes grief with lseek().) > > So a pad might be needed for some system calls on some 32bit architectu= res. > > This could be done with something that expands to '' or '0,'. =20 >=20 > I don't see why we have to worry about variable alignment or stack > direction at all. That's the compilers job. Except you do because you are trying to match what the compiler would generate for a 64bit argument by passing two 32bit values. I'm pretty sure that the normal syscall interface just passes the registers that contain arguments over from user space to kernel space and then calls the kernel function (ie without any regard for the types of the parameters). This is normally fine except for lseek() and mmap() - they may have an interface that re-orders the arguments. > We do have both lseek() and > parisc32 nowadays and both work fine. Also with Daniel's series on top. > Am I missing something? godbolt doesn't have a parisc32 compiler - so I couldn't check. But I think if you compare the code for calls to f1(int, int, int, int), f2(int, long long, int) and f3(int, int long long) for f1(1,2,3,4), f2(1, 2ull<<32 | 3, 4) and f3(1, 2, 3ull<<32 | 4) against another BE system the 64bit constants will overlay different 32bit ones. David >=20 >=20 > Thomas