Re: [bug report] rcu: Kill rnp->ofl_seq and use only rcu_state.ofl_lock for exclusion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 08, 2024 at 07:33:38AM -0700, Paul E. McKenney wrote:
> On Wed, May 08, 2024 at 03:29:12PM +0300, Dan Carpenter wrote:
> > Hello David Woodhouse,
> > 
> > Commit 82980b1622d9 ("rcu: Kill rnp->ofl_seq and use only
> > rcu_state.ofl_lock for exclusion") from Feb 16, 2021 (linux-next),
> > leads to the following Smatch static checker warning:
> > 
> > 	kernel/rcu/tree.c:1844 rcu_gp_init()
> > 	warn: mixing irq and irqsave
> 
> There are actually cases where this does make sense, one example being
> where some called function (for example, rcu_report_qs_rnp() below)
> needs a flags argument.
> 

I only found one false positive which was kind of related to that in
__run_hrtimer().

  1643  
  1644  static void __run_hrtimer(struct hrtimer_cpu_base *cpu_base,
  1645                            struct hrtimer_clock_base *base,
  1646                            struct hrtimer *timer, ktime_t *now,
  1647                            unsigned long flags) __must_hold(&cpu_base->lock)
                                                ^^^^^

  1648  {
....

  1678          /*
  1679           * The timer is marked as running in the CPU base, so it is
  1680           * protected against migration to a different CPU even if the lock
  1681           * is dropped.
  1682           */
  1683          raw_spin_unlock_irqrestore(&cpu_base->lock, flags);
                                                            ^^^^^
We potentially enable IRQs.

  1684          trace_hrtimer_expire_entry(timer, now);
  1685          expires_in_hardirq = lockdep_hrtimer_enter(timer);
  1686  
  1687          restart = fn(timer);
  1688  
  1689          lockdep_hrtimer_exit(expires_in_hardirq);
  1690          trace_hrtimer_expire_exit(timer);
  1691          raw_spin_lock_irq(&cpu_base->lock);
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Then disable them again.

  1692  

Of course the other warnings are mostly not "bugs" because the callers
haven't disabled IRQs.  They're just in need of clean up.

regards,
dan carpenter





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux