NetBSD-Bugs archive

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

Re: kern/38707: scheduler related deadlock during

> >Fix:
> Not known, but the spc_unlock() in sched_catchlwp() looks suspicious.
> It may be unsafe to unlock curcpu there. I think it would be better
> to bail out if the trylock fails.

In case you have crash-dump, can you validate current LWP's l_target_cpu is
not NULL? I see one dead-lock case - if LWP migrates, in mi_switch() we do:

if (__predict_false(tci != NULL)) {
        /* Double-lock the runqueues */
        spc_dlock(ci, tci);
} else {
        /* Lock the runqueue */

While further in sched_nextlwp() we may re-lock the ci. In case when
ci < tci, re-locking would cause deadlock. New thread migration approach
will fix that, but it would still be nice to validate this.

Talking about re-locking in sched_nextlwp() - I agree that it is not nice.
Probably we can remove it, just interesting, does it affect times

Best regards,

Home | Main Index | Thread Index | Old Index