From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 759EC3112BA for ; Fri, 16 Jan 2026 16:47:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768582039; cv=none; b=BqJ9A7m7sM7CmD1tOZdrynwHIwo05LhNoTpWzXPpPqrPzcrlTc9pURHVFWULAgZ7CMdgYKZM0SJnD+hVzu0ONcQIDsOJPPF50ellZb2KrgOlQWS6UwKljpQFEwrBE3yRPbHrzgJJCcsIAjYmOJtnEnEl/lE5JJ2ifOkmkndT3tc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768582039; c=relaxed/simple; bh=+Q5MJCj4TVd4LpveiwsjRWBEpJtCsPIHTEKopKSlucI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GPIrdpYxJYfer+WX9cuq7H/3QAjAcHykU26UEwaY2a/bzV57TldfmMaUpR3+LB0WTyhuaShhnv9kcebgjJoN8Z2n+ECuDRnsK+k/s+Z0Zq8yJ4Vvwqenz2kC9RhoEZRIC55nTgevhAckvA7+7g17XhnvEBSShwdBaEUtp3qCHYc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=jrtc27.com; spf=pass smtp.mailfrom=jrtc27.com; dkim=pass (2048-bit key) header.d=jrtc27.com header.i=@jrtc27.com header.b=WPtDGPHr; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=jrtc27.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=jrtc27.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=jrtc27.com header.i=@jrtc27.com header.b="WPtDGPHr" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-47f5c2283b6so14440705e9.1 for ; Fri, 16 Jan 2026 08:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jrtc27.com; s=gmail.jrtc27.user; t=1768582037; x=1769186837; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=kJzgUKOJB6oCUo0JSuCqlChu8wca/s3XgI3abK0Mh6I=; b=WPtDGPHr3jwkYBgL7DEwh5KiVuzmiqU1JR/yHeVw6iJDr5bJcFt2WBz/IvsDv6t9gV wQRgWVAdpndKN5GwVOC4SD6LJvSrrCO3i20TGkUr8e18OlcmSspBgLWYJkjgisoT9qZb oDVESTUyfa6fZj7DIdwFsmLM0Qky9wFebsIXcbJ2TIXbJmixEIuOJu62PK8bBHIHO3t/ 6o6iRct81O58wfUtDnsJcOcitRMrxbEkUwe3Fs3te8cDjPJdwCMQE+Nts0mbfeaP/6H+ r0jY7YbCQYGqzwLPlEZT8GaU8mrkAFYoN+D3B6iJLPa63SG/2NaenLq731/UJVkRAeLX tLug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768582037; x=1769186837; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kJzgUKOJB6oCUo0JSuCqlChu8wca/s3XgI3abK0Mh6I=; b=bEed4TS6XFaNtTr9p6WySN3CKZC/vSxKwJLvnnSavzmm5BHg6Dze/ukPgMxpV1/AP/ J7tHsMdtFL0lzx8rOtBqnSLobiKUb1Au8dBgbTGTl0AzAlyr/f2sN8nsvhkQSPaVS3yK uPZdpLQHgkEKN66EmPcf4txX7281dVH0yDWhnBiL2tBZo082PE8KCpL/HgRVBudIUAVZ xb+oVOez5vcch9kENjA8ftV/6Z3yuoE/YjmEMvqqxV77f2Cbdfa6RZIijy687E5H/XZ6 pP5XXfGt9ZreKdex3y5YJBHhTOps9HvMH906dJInv3owK/mUu3cpcXT8qHmMxP2iSm2I azWg== X-Forwarded-Encrypted: i=1; AJvYcCWDTZAubX3d+yx1VF/+7z93NR5wPXrvAxzjdgjoDr8sLy2FafjBLSekSPTywtJb9jF7ThcTpLcTX5kd6OM=@vger.kernel.org X-Gm-Message-State: AOJu0YwnYY8tiJvJelvoeE+u8Dz6Pe3Qv1Rwvr7EQB3kdEPBjSbksWNF myCpGiIt+SR+z0+eHz3lS7xqwmF2qPqCMYJDKQjLuFPjmVLw4JcLZp9ph/aHx9u8rXM= X-Gm-Gg: AY/fxX67a0WEdFzvinDO16d8QQsWnrqcNzfIkmGk+zdYBbCmwZDupKv0HkozXgCQBG4 bq5MN2WA6iZjYjqeIyH/a/e06OYH6Ulr09o4s8cBI3De6O2/o9v/qVDQBiqox+Bk50zWSpmxalu FLWoMBP3q++afHQ862y9ZqxsFsNCQGla2FBI3h8UhYuOc7jE9l4i0UDB6romaVeWZru8rqm7HiX 6Shrl6qu7Yb+6z+z9liQHyaPpSvn6pi1ZLp8xU6Jqw8HuaVb29YXjIg1JogCk78U3jB7LMNC+qD Lmp76qabwjZgnxaisga9/mxLQR48TI3xFg4qfAfm9CbCMKuFo18x+3+70hP8DgY3o8hfW5njsDb M6UyBH4lnKF1fFIbMjn6wGcJiZouyuHIHUJIFCNvYUp09ogNpPEpx6P5yBlS52oO9bkoV7aLZTY PWGv9pvAUOe8qKlgsHg/yu5HGB1kkqHG017sF3gzlULvBS71rQvo5Zj1yZHnz3G37XoJ2fx6Wau FSI9Jml6YE= X-Received: by 2002:a05:600c:8718:b0:477:76c2:49c9 with SMTP id 5b1f17b1804b1-4801e2fb9e5mr46263395e9.2.1768582036182; Fri, 16 Jan 2026 08:47:16 -0800 (PST) Received: from Jessicas-MacBook-Pro.localdomain (nat-184-7.net.cam.ac.uk. [131.111.184.7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801fe2c04bsm19443975e9.8.2026.01.16.08.47.15 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 16 Jan 2026 08:47:15 -0800 (PST) Received: by Jessicas-MacBook-Pro.localdomain (Postfix, from userid 501) id ABF0710FE3389; Fri, 16 Jan 2026 16:47:14 +0000 (GMT) Date: Fri, 16 Jan 2026 16:47:14 +0000 From: Jessica Clarke To: Ludwig Rydberg Cc: davem@davemloft.net, andreas@gaisler.com, brauner@kernel.org, shuah@kernel.org, sparclinux@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, arnd@arndb.de, glaubitz@physik.fu-berlin.de, geert@linux-m68k.org, schuster.simon@siemens-energy.com Subject: Re: [PATCH 2/3] sparc: Add architecture support for clone3 Message-ID: References: <20260116153051.21678-1-ludwig.rydberg@gaisler.com> <20260116153051.21678-3-ludwig.rydberg@gaisler.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260116153051.21678-3-ludwig.rydberg@gaisler.com> On Fri, Jan 16, 2026 at 04:30:50PM +0100, Ludwig Rydberg wrote: > Add support for the clone3 system call to the SPARC architectures. > > The implementation follows the pattern of the original clone syscall. > However, instead of explicitly calling kernel_clone, the clone3 > handler calls the generic sys_clone3 handler in kernel/fork. > In case no stack is provided, the parents stack is reused. > > The return call conventions for clone on SPARC are kept for clone3: > Parent --> %o0 == child's pid, %o1 == 0 > Child --> %o0 == parent's pid, %o1 == 1 One of the benefits of having a new clone3 is that the interface can be made the same across all architectures*, unlike clone, which both passes the arguments in different orders for different architectures and, in the case of SPARC, has this weird return convention inherited from the SunOS syscall interface. Is there a good reason to deviate for clone3 too and keep this annoying oddity going, that requires special-casing SPARC when other architectures can just syscall(__NR_clone3, ...)? Jessica * Even Itanium's clone2 could have been subsumed by it, as clone3 passes the stack base and size rather than the desired stack pointer