From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from vmicros1.altlinux.org (vmicros1.altlinux.org [194.107.17.57]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6445E18D622 for ; Tue, 28 Jan 2025 16:10:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=194.107.17.57 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738080608; cv=none; b=gGuGsQofdUsQVGcXuPhN1hOagGU0ilnIgGC2E/PVr1yK0Sa/s3pepHgdv2Ef2XWeuB+sPE2ELo5BmLyqNb8DYHqO5YTeyheGcsoP/lgDZQwAwGRbdtFud7ss4k4ddxSTN5w0jUS5kP8qdeWQvd6qUZ8LVWFwApVE7D8aB9AaCnY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738080608; c=relaxed/simple; bh=NakPCtZdTvNYacPUxqwTYODCa2FfQkDNsaHmlDV1qS8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IUuiC1teCyVztINrcpI03g8ZMQZOF1ysAOqEyz9EgRUVSFEed1+7i4R3KMsTQSMENd5U5LeNfKeVTquI+RWuiVDtDYE2tWQfeuyTTiIAVBT2O/CdEz0tk6d0T7wjwK4McNCF+VxyUKr3ykqAGTmauqCcEkXFRZpk1tWH1ybn9Ys= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=strace.io; spf=pass smtp.mailfrom=altlinux.org; arc=none smtp.client-ip=194.107.17.57 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=strace.io Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=altlinux.org Received: from mua.local.altlinux.org (mua.local.altlinux.org [192.168.1.14]) by vmicros1.altlinux.org (Postfix) with ESMTP id 61DF872C8CC; Tue, 28 Jan 2025 19:10:05 +0300 (MSK) Received: by mua.local.altlinux.org (Postfix, from userid 508) id 530D37CCB3A; Tue, 28 Jan 2025 18:10:05 +0200 (IST) Date: Tue, 28 Jan 2025 18:10:05 +0200 From: "Dmitry V. Levin" To: Christophe Leroy Cc: Michael Ellerman , Alexey Gladkov , Eugene Syromyatnikov , Oleg Nesterov , Madhavan Srinivasan , Nicholas Piggin , Naveen N Rao , linuxppc-dev@lists.ozlabs.org, strace-devel@lists.strace.io, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] powerpc: properly negate error in syscall_set_return_value() in sc case Message-ID: <20250128161005.GC11869@strace.io> References: <20250127181322.GA1373@strace.io> <20250128155201.GA11869@strace.io> 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Jan 28, 2025 at 05:00:31PM +0100, Christophe Leroy wrote: > Le 28/01/2025 à 16:52, Dmitry V. Levin a écrit : > > On Tue, Jan 28, 2025 at 03:59:29PM +0100, Christophe Leroy wrote: > >> Le 27/01/2025 à 19:13, Dmitry V. Levin a écrit : > >>> According to the Power Architecture Linux system call ABI documented in > >>> [1], when the syscall is made with the sc instruction, both a value and an > >>> error condition are returned, where r3 register contains the return value, > >>> and cr0.SO bit specifies the error condition. When cr0.SO is clear, the > >>> syscall succeeded and r3 is the return value. When cr0.SO is set, the > >>> syscall failed and r3 is the error value. This syscall return semantics > >>> was implemented from the very beginning of Power Architecture on Linux, > >>> and syscall tracers and debuggers like strace that read or modify syscall > >>> return information also rely on this ABI. > >> > >> I see a quite similar ABI on microblaze, mips, nios2 and sparc. Do they > >> behave all the same ? > > > > Yes, also on alpha. I don't think microblaze should be in this list, > > though. > > Microblaze has > > static inline void syscall_set_return_value(struct task_struct *task, > struct pt_regs *regs, > int error, long val) > { > if (error) > regs->r3 = -error; > else > regs->r3 = val; > } > > So it has a positive error setting allthough it has no flag to tell it > is an error. Wondering how it works at the end. It's a bug, but given that microblaze doesn't enable CONFIG_HAVE_ARCH_TRACEHOOK, most likely this function is unused there. > Alpha I'm not sure, I see nothing obvious in include/asm/ptrace.h or > include/asm/syscall.h Alpha doesn't enable CONFIG_HAVE_ARCH_TRACEHOOK, it just lacks the necessary interfaces, but it uses a3 register for this purpose, see arch/alpha/kernel/entry.S for details. -- ldv