NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/38707: scheduler related deadlock during build.sh
> >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 */
spc_lock(ci);
}
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 build.sh times
anyhow?
--
Best regards,
Mindaugas
www.NetBSD.org
Home |
Main Index |
Thread Index |
Old Index