[PATCH 2/2] lib: sbi: Make ipi send/clear and access ipi_type non-reentrant
Xiang W
wxjstz at 126.com
Wed Nov 22 05:03:22 PST 2023
在 2023-11-21星期二的 16:56 -0800,Bo Gan写道:
> > > @@ -220,8 +224,12 @@ void sbi_ipi_process(void)
> > > u32 hartindex = sbi_hartid_to_hartindex(current_hartid());
> > >
> > > sbi_pmu_ctr_incr_fw(SBI_PMU_FW_IPI_RECVD);
> > > +
> > > + spin_lock(&ipi_data->lock);
> > > sbi_ipi_raw_clear(hartindex);
> > > ipi_type = atomic_raw_xchg_ulong(&ipi_data->ipi_type, 0);
> > > + spin_unlock(&ipi_data->lock);
> > > +
> > > ipi_event = 0;
> > > while (ipi_type) {
> > > if (ipi_type & 1UL) {
>
> Hi Xiang,
>
> I think we should drop this, and use Anup's new patch instead. I don't
> think the spinlock here is helping to ensure the ordering between
>
> sbi_ipi_raw_clear and xchg(). Furthermore, spinlock in OpenSBI doesn't
> order IO, so ipi_raw_clear can leak below spin_unlock. Thus, it won't
> address the race condition in previous discussions.
>
> With Anip's new patch that uses wmb() in both sender and receiver, it
> fixes the correctness issue, and hopefully has negligible performance
> impact: See the discussion here:
>
> http://lists.infradead.org/pipermail/opensbi/2023-November/005937.html
>
> Bo
This bug is not related to reorder. It's one more ipi interrupt is sent.
Regards,
Xiang W
More information about the opensbi
mailing list