On 02/10/21(Sat) 21:09, Mark Kettenis wrote:
> > Date: Sat, 2 Oct 2021 20:35:41 +0200
> > From: Martin Pieuchot <[email protected]>
> > [...]
> > There's no sleeping point but a call to wakeup(). This wakeup() is
> > supposed to wake a btrace(8) process. But if the curproc, which just
> > added itself to the global sleep queue, ends up in the same bucket as
> > the btrace process, the KASSERT() line 565 of kern/kern_synch.c will
> > trigger:
> >
> > /*
> > * If the rwlock passed to rwsleep() is contended, the
> > * CPU will end up calling wakeup() between sleep_setup()
> > * and sleep_finish().
> > */
> > if (p == curproc) {
> > KASSERT(p->p_stat == SONPROC);
> > continue;
> > }
>
> Ah, right. But that means the comment isn't accurate. At least there
> are other cases that make us hit that codepath.
>
> How useful is that KASSERT in catching actual bugs?
I added the KASSERT() to limit the scope of the check. If the test is
true `curproc' is obviously on the CPU. Its usefulness is questionable.
So a simpler fix would be to remove the assert, diff below does that and
update the comment, ok?
Index: kern/kern_synch.c
===================================================================
RCS file: /cvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.179
diff -u -p -r1.179 kern_synch.c
--- kern/kern_synch.c 9 Sep 2021 18:41:39 -0000 1.179
+++ kern/kern_synch.c 3 Oct 2021 08:48:28 -0000
@@ -558,14 +558,11 @@ wakeup_n(const volatile void *ident, int
for (p = TAILQ_FIRST(qp); p != NULL && n != 0; p = pnext) {
pnext = TAILQ_NEXT(p, p_runq);
/*
- * If the rwlock passed to rwsleep() is contended, the
- * CPU will end up calling wakeup() between sleep_setup()
- * and sleep_finish().
+ * This happens if wakeup(9) is called after enqueuing
+ * itself on the sleep queue and both `ident' collide.
*/
- if (p == curproc) {
- KASSERT(p->p_stat == SONPROC);
+ if (p == curproc)
continue;
- }
#ifdef DIAGNOSTIC
if (p->p_stat != SSLEEP && p->p_stat != SSTOP)
panic("wakeup: p_stat is %d", (int)p->p_stat);
