From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout11.his.huawei.com (canpmsgout11.his.huawei.com [113.46.200.226]) (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 E0AEE38550E for ; Thu, 25 Jun 2026 11:41:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.226 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782387696; cv=none; b=baTjXivh+zr2YBFFRysC/eNSroqUZpc7+BMQ6p+VgCPwfTRKavJgBRX9JY6JLFBJyPnRKMfv4Sv+ixCNhvE6ShPuAfyAp2C5DPovhRRqrmBj7v6iRlig7fXFvZQ56MChf6hXZlQ6vFCpte7ER5IKIqgOBzndYg+4JwoYdgVEaWc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782387696; c=relaxed/simple; bh=8FzOf9cAm8tNpvlLHnw82zH9nXwdvvrOCUqUXSeFDkU=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=eG0ejGPIbAodjB3oiVxlpaoqi2sAhOxfTB62xGAl7+K9fqhYiVd79j//2Go+ZfmE4XIjHGBcIkv/2oNjHKPR04+PT+llZMnFaH5ipBXLnjKCjmJKNi32wJ902Iq2C/ItU+3PduJo4wDvPgR9adjt5e9S4yAHxM/T5CmVkclSORE= 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=qzfReAgw; arc=none smtp.client-ip=113.46.200.226 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="qzfReAgw" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=SkWLmHbkx4otCWQO/Zs78Zixwt8poz7bHe/5QgJLMeE=; b=qzfReAgw0Yn+ib4NL6VZtl8ONzWYH0xtu9N6ZNGXRVUjxJ9lkuWCWthhARvq9FjgRwDqIFOBu nrvLtajkpIytfGJisK4Ni6cxjdScAhkQ2jCcKHKlxIyHnX0Fo4VRZ84dqOU2v/OUqhp8lHHf+tI XawJwYJ0FzxBeswpxWftfYY= Received: from mail.maildlp.com (unknown [172.19.163.127]) by canpmsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4gmGqj3G3VzKmT0; Thu, 25 Jun 2026 19:32:17 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 00630402AB; Thu, 25 Jun 2026 19:41:26 +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; Thu, 25 Jun 2026 19:41:24 +0800 Message-ID: Date: Thu, 25 Jun 2026 19:41:23 +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 v15 08/11] arm64/ptrace: Define and use _TIF_SYSCALL_EXIT_WORK To: Ada Couprie Diaz CC: , , , , , , , , , , , , , , , , , , , , , , References: <20260511092103.1974980-1-ruanjinjie@huawei.com> <20260511092103.1974980-9-ruanjinjie@huawei.com> <073a55f2-54ff-4770-8457-bef164261a87@arm.com> From: Jinjie Ruan In-Reply-To: <073a55f2-54ff-4770-8457-bef164261a87@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) On 6/24/2026 10:53 PM, Ada Couprie Diaz wrote: > On 11/05/2026 10:21, Jinjie Ruan wrote: >> Introduce _TIF_SYSCALL_EXIT_WORK to filter out entry-only flags >> during the syscall exit path. This aligns arm64 with the generic >> entry framework's SYSCALL_WORK_EXIT semantics. >> >> [Rationale] >> The current syscall exit path uses _TIF_SYSCALL_WORK to decide whether >> to invoke syscall_exit_work(). However, _TIF_SYSCALL_WORK includes >> flags that are only relevant during syscall entry: >> >> 1. _TIF_SECCOMP: Seccomp filtering (__secure_computing) only runs >>    on entry. There is no seccomp callback for syscall exit. >> >> 2. _TIF_SYSCALL_EMU: In PTRACE_SYSEMU mode, the syscall is >>    intercepted and skipped on entry. Since the syscall is never >>    executed, reporting a syscall exit stop is unnecessary. >> >> [Changes] >> - Define _TIF_SYSCALL_EXIT_WORK: A new mask containing only flags >>    requiring exit processing: _TIF_SYSCALL_TRACE, _TIF_SYSCALL_AUDIT, >>    and _TIF_SYSCALL_TRACEPOINT. >> >> - Update exit path: Use _TIF_SYSCALL_EXIT_WORK in >>    syscall_exit_to_user_mode_work() to avoid redundant calls to >>    audit and ptrace reporting when only entry-flags are set. >> >> - Cleanup: Remove the has_syscall_work() helper as it is no longer >>    needed. Direct flag comparison is now used to distinguish between >>    entry and exit work requirements. >> >> [Impact] >> audit_syscall_exit() and report_syscall_exit() will no longer be >> triggered for seccomp-only or emu-only syscalls. This matches the >> generic entry behavior and improves efficiency by skipping unnecessary >> exit processing. >> >> Cc: Mark Rutland >> Cc: Will Deacon >> Cc: Catalin Marinas >> Reviewed-by: Linus Walleij >> Reviewed-by: Yeoreum Yun >> Signed-off-by: Jinjie Ruan >> --- > > Reviewed-by: Ada Couprie Diaz > > Definitely not related to this series, but it feels like this brings us > quite close to being able to switch to generic TIF flags as well : > only TIF_FOREIGN_PSTATE and TIF_MTE_ASYNC_FAULT > would need to be moved to the upper 16 bits, > with TIF_RESTORE_SIGMASK and TIF_MEMDIE freeing two slots there. > > Not sure how important the bit number changes would be and if any > of the extra generic bits require any arch support (TIF_POLLING_NRFLAG, > TIF_USER_RETURN_NOTIFY, TIF_RSEQ, TIF_HRTIMER_REARM)... > > But again, just thinking out loud ! Hi Ada, You have incredible foresight! You are absolutely right that this series lays the perfect groundwork for switching arm64 to generic TIF flags (HAVE_GENERIC_TIF_BITS). I am happy to share that I have already implemented exactly what you described—including migrating the architecture-specific flags to the upper 16 bits and enabling the generic TIF infrastructure—in a separate, dedicated patch series. You can find the implementation and discussion here: https://lore.kernel.org/all/20260320104222.1381274-1-ruanjinjie@huawei.com/ Since that series directly builds on top of the cleanups and infrastructure introduced here, I plan to actively push it forward right after we get this core generic entry conversion landed. Thanks again for looking so far ahead and validating the direction! Best regards, Jinjie > Thanks, > Ada > >