On Tue, Feb 25, 2025 at 08:08:53AM -0800, Boqun Feng wrote:
> On Tue, Feb 25, 2025 at 07:58:01AM -0800, Paul E. McKenney wrote:
> > Hello, Boqun,
> >
> > I have run overnight tests on your earlier branches here:
> >
> > ccb986e8b69f ("MAINTAINERS: Update Joel's email address")
> >
Oh and I should have let you know, I updated next and dev branch, the
latest ones are:
next.2025.02.24a and dev.2025.02.24a in rcu repo.
Regards,
Boqun
> > These passed other than a KCSAN complaint involving
> > rcu_preempt_deferred_qs_handler() and rcu_read_unlock_special().
> > This looks like the plain C-language writes to ->defer_qs_iw_pending.
> >
> > My guess is that this is low probability, despite having happened twice,
> > and that it happens when rcu_read_unlock_special() is interrupted,
> > resulting in rcu_preempt_deferred_qs_handler() being invoked as an
> > IRQ-work handler. Keeping in mind that RCU runs KCSAN so as to locate
> > data races between task and handler on the same CPU.
> >
> > Thoughts?
> >
>
> Do you have a KCSAN of this? Also this is not a regression, right?
> Meaning you probably have seen this before? Anyway, it should be an easy
> fix (just using READ_ONCE() and WRITE_ONCE()). I can send the fix out
> and put it in.
>
> Regards,
> Boqun
>
> > Thanx, Paul
