linux-kernel - Re: [PATCH 16/19] context_tracking: Convert state to atomic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 11 Mar 2022 16:24:26 +0100
From:   Frederic Weisbecker <frederic@...nel.org>
To:     nicolas saenz julienne <nsaenz@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Phil Auld <pauld@...hat.com>,
        Alex Belits <abelits@...vell.com>,
        Xiongfeng Wang <wangxiongfeng2@...wei.com>,
        Neeraj Upadhyay <quic_neeraju@...cinc.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Yu Liao <liaoyu15@...wei.com>,
        Boqun Feng <boqun.feng@...il.com>,
        "Paul E . McKenney" <paulmck@...nel.org>,
        Marcelo Tosatti <mtosatti@...hat.com>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Uladzislau Rezki <uladzislau.rezki@...y.com>,
        Joel Fernandes <joel@...lfernandes.org>
Subject: Re: [PATCH 16/19] context_tracking: Convert state to atomic_t

On Wed, Mar 09, 2022 at 06:17:02PM +0100, nicolas saenz julienne wrote:
> On Wed, 2022-03-02 at 16:48 +0100, Frederic Weisbecker wrote:
> > Context tracking's state and dynticks counter are going to be merged
> > in a single field so that both updates can happen atomically and at the
> > same time. Prepare for that with converting the state into an atomic_t.
> > 
> > Signed-off-by: Frederic Weisbecker <frederic@...nel.org>
> > Cc: Paul E. McKenney <paulmck@...nel.org>
> > Cc: Peter Zijlstra <peterz@...radead.org>
> > Cc: Thomas Gleixner <tglx@...utronix.de>
> > Cc: Neeraj Upadhyay <quic_neeraju@...cinc.com>
> > Cc: Uladzislau Rezki <uladzislau.rezki@...y.com>
> > Cc: Joel Fernandes <joel@...lfernandes.org>
> > Cc: Boqun Feng <boqun.feng@...il.com>
> > Cc: Nicolas Saenz Julienne <nsaenz@...nel.org>
> > Cc: Marcelo Tosatti <mtosatti@...hat.com>
> > Cc: Xiongfeng Wang <wangxiongfeng2@...wei.com>
> > Cc: Yu Liao<liaoyu15@...wei.com>
> > Cc: Phil Auld <pauld@...hat.com>
> > Cc: Paul Gortmaker<paul.gortmaker@...driver.com>
> > Cc: Alex Belits <abelits@...vell.com>
> > ---
> >  static __always_inline bool context_tracking_in_user(void)
> >  {
> > -	return __this_cpu_read(context_tracking.state) == CONTEXT_USER;
> > +	return __ct_state() == CONTEXT_USER;
> >  }
> 
> I was wondering whether it'd make more sense to use ct_state() for extra safety
> vs preemption, but it turns out the function isn't being used at all.
> 
> I figure it'd be better to remove it altogether and leave ct_state() as the
> goto function for this sort of checks.

Ah even better!

> 
> >  #else
> >  static inline bool context_tracking_in_user(void) { return false; }
> > diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
> > index de247e758767..69db43548768 100644
> > --- a/kernel/context_tracking.c
> > +++ b/kernel/context_tracking.c
> > @@ -337,6 +337,7 @@ static __always_inline void context_tracking_recursion_exit(void)
> >   */
> >  void noinstr __ct_user_enter(enum ctx_state state)
> >  {
> > +	struct context_tracking *ct = this_cpu_ptr(&context_tracking);
> 
> I wonder if there is any value to having __ct_state() take 'struct
> context_tracking *ct' as an argument to avoid a redundant this_cpu_ptr()...
> 
> >  	lockdep_assert_irqs_disabled();
> >  
> >  	/* Kernel threads aren't supposed to go to userspace */
> > @@ -345,8 +346,8 @@ void noinstr __ct_user_enter(enum ctx_state state)
> >  	if (!context_tracking_recursion_enter())
> >  		return;
> >  
> > -	if ( __this_cpu_read(context_tracking.state) != state) {
> > -		if (__this_cpu_read(context_tracking.active)) {
> > +	if (__ct_state() != state) {
> 
> ...here (and in __ct_user_exit()).

Hmm, I'll check that.

Thanks!