[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yt9dqzwds690.fsf@linux.ibm.com>
Date: Thu, 11 Sep 2025 11:11:55 +0200
From: Sven Schnelle <svens@...ux.ibm.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
Michael Jeanson
<mjeanson@...icios.com>, Jens Axboe <axboe@...nel.dk>,
Heiko Carstens
<hca@...ux.ibm.com>,
Christian Borntraeger <borntraeger@...ux.ibm.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Peter Zijlstra
<peterz@...radead.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Boqun
Feng <boqun.feng@...il.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Sean
Christopherson <seanjc@...gle.com>, Wei Liu <wei.liu@...nel.org>,
Dexuan
Cui <decui@...rosoft.com>, x86@...nel.org,
Arnd Bergmann
<arnd@...db.de>, Huacai Chen <chenhuacai@...nel.org>,
Paul Walmsley
<paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>
Subject: Re: [patch V4 33/36] s390: Use generic TIF bits
Thomas Gleixner <tglx@...utronix.de> writes:
> No point in defining generic items and the upcoming RSEQ optimizations are
> only available with this _and_ the generic entry infrastructure, which is
> already used by s390. So no further action required here.
>
> This leaves a comment about the AUDIT/TRACE/SECCOMP bits which are handled
> by SYSCALL_WORK in the generic code, so they seem redundant, but that's a
> problem for the s390 wizards to think about.
>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> Cc: Heiko Carstens <hca@...ux.ibm.com>
> Cc: Christian Borntraeger <borntraeger@...ux.ibm.com>
> Cc: Sven Schnelle <svens@...ux.ibm.com>
>
> --- a/arch/s390/include/asm/thread_info.h
> +++ b/arch/s390/include/asm/thread_info.h
> @@ -56,43 +56,35 @@ void arch_setup_new_exec(void);
> [..]
> +/* These could move over to SYSCALL_WORK bits, no? */
> #define TIF_SYSCALL_TRACE 24 /* syscall trace active */
> #define TIF_SYSCALL_AUDIT 25 /* syscall auditing active */
> #define TIF_SECCOMP 26 /* secure computing */
> #define TIF_SYSCALL_TRACEPOINT 27 /* syscall tracepoint instrumentation */
Looks like these flags are a leftover of the conversion to generic
entry and are no longer used. I'll send a patch on top of your patchset
which remove them.
Thanks!
Sven
Powered by blists - more mailing lists