From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout10.his.huawei.com (canpmsgout10.his.huawei.com [113.46.200.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 666E03D093B for ; Tue, 21 Jul 2026 09:30:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.225 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784626247; cv=none; b=c1liW+JPZtCZePX5id70Ln2uC3G+kh/vosDEAqcX9cpp5gSK8Zp5OfW/DgnQQ9FROKPX//M/F4eGEasrBGH0fdgrdVz1LW1KqkVr499LQBpA0Eu15LXVkftOiJgCVehTmmQplgjIvMGGPnx6DYu+WtK8uoINlmBV6C2dFDFvwaU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784626247; c=relaxed/simple; bh=lrQDft2eXmx8NMhfwejv6V/wPsDrVdSJluKMhnTI3Qs=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=Z8EKHMi59UI/67paY6I0VZgrbzNW6h0sTToLa+H8UBKcSFSbw7fPyqVGSB2rekxuyJx1k3o5C2eMATG7v8qgGtj/uCSGUp9a64yXnnU06sZDZ3Fx4NJgqTLsdhfkU9HsLn6hkimA5gIFd8XWpbnJW3EWxLZzrbkmm+bCwpuV/Qs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=d/waB1qO; arc=none smtp.client-ip=113.46.200.225 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="d/waB1qO" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=cJbsqN6wqYrtfAxvXkhAoP2bYCz03A4sparHJIC38dE=; b=d/waB1qOowvCbjjPKalGiMhNHDsFZrHvKEHZlV/nJrLXOgmgPkC7nDlJRnAO16DkaldMP9gWd aletERf6DHgMUR4iKCXmqmCq/Cr6ZvibLW7dIaJRLDqN5VbVvp+15UOKCURwB7wjglTTNp+8f+o lWBEFP3d2ypJVutMKNnzRNM= Received: from mail.maildlp.com (unknown [172.19.163.15]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4h4Bhc42Lcz1K9cD; Tue, 21 Jul 2026 17:21:20 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 63DA840578; Tue, 21 Jul 2026 17:30:41 +0800 (CST) Received: from [10.67.109.254] (10.67.109.254) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 21 Jul 2026 17:30:39 +0800 Message-ID: Date: Tue, 21 Jul 2026 17:30:38 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v17 11/15] arm64: syscall: Simplify el0_svc_common() syscall exit path To: Linus Walleij CC: , , , , , , , , , , , , , , , , , , , , , References: <20260721081858.1169276-1-ruanjinjie@huawei.com> <20260721081858.1169276-12-ruanjinjie@huawei.com> From: Jinjie Ruan In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To dggpemf500011.china.huawei.com (7.185.36.131) On 7/21/2026 4:51 PM, Linus Walleij wrote: > On Tue, Jul 21, 2026 at 10:19 AM Jinjie Ruan wrote: > >> Remove the redundant nested conditional check within the system call >> exit path of el0_svc_common() to streamline the exit sequence. >> >> When entering this fast-path block, CONFIG_DEBUG_RSEQ is guaranteed to be >> disabled so the call of rseq_syscall() is a no-op. > > Please explain why this is guaranteed. Yes, there is a little unclear. The expression "!IS_ENABLED(CONFIG_DEBUG_RSEQ)" evaluates to true only when CONFIG_DEBUG_RSEQ is not set; with the guarantee that it is disabled, the condition is always satisfied. > >> Under this constraint, >> the code logic inside the block becomes completely identical to what >> the arm64_syscall_exit_to_user_mode_work() helper already does. Replace >> that nested logic with a direct invocation of the helper, eliminating >> redundant code. >> >> Before: >> >> | if (... && !IS_ENABLED(CONFIG_DEBUG_RSEQ)) { >> | flags = read_thread_flags(); >> | if (unlikely(flags & _TIF_SYSCALL_EXIT_WORK) || flags & _TIF_SINGLESTEP) >> | arm64_syscall_exit_to_user_mode_work(regs); >> | return; >> | } >> | trace_exit: >> | arm64_syscall_exit_to_user_mode_work(regs); >> >> After simplify: >> >> | if (... && !IS_ENABLED(CONFIG_DEBUG_RSEQ)) { >> | arm64_syscall_exit_to_user_mode_work(regs); >> | return; >> | } >> | trace_exit: >> | arm64_syscall_exit_to_user_mode_work(regs); >> >> Furthermore, Since both the conditional fast-path and the fallback >> slow-path now uniformly invoke arm64_syscall_exit_to_user_mode_work(), >> this explicit conditional branch is entirely redundant regardless of >> whether the evaluation is true or false. Removing it collapses >> the duplicated logic into a single, unconditional path. >> >> No functional changes. >> >> Cc: Mark Rutland >> Cc: Will Deacon >> Cc: Catalin Marinas >> Cc: Ada Couprie Diaz >> Signed-off-by: Jinjie Ruan > > After looking at it for a while I conclude you are right, provided > the reasoning about !CONFIG_DEBUG_RSEQ holds. So with > that explained: > Reviewed-by: Linus Walleij > > Yours, > Linus Walleij