EPOCH tracing support for debugging.

[glebius]

Summary

Add a debugging kernel option that allows to check whether we are
entering epochs recursively or nest them improperly.

[• hselasky]

sys/kern/subr_epoch.c

213

What do you do if "et" is already in td->td_epochs? panic?

sys/sys/epoch.h

80

Maybe call this EPOCH_TRACE_FILE_LINE

89

(epoch)->epoch (et)->et

Arguments are already comma separated.

sys/sys/proc.h

370

When you are in an epoch section, the CPU is pinned. Are you sure you cannot use the per-cpu epoch lists for this. I.E. have a pointer to the thread from the epoch tracker to avoid mangling the thread structure.

[glebius]

sys/kern/subr_epoch.c

213

I'm sure we will panic anyway in this case. Typical double insertion, single removal into a list. Already covered by INVARIANTS and probably QUEUE_MACRO_DEBUG.

sys/sys/epoch.h

80

Makes sense.

sys/sys/proc.h

370

Pinned, but we aren't in critical section. CPU may work with a different thread that also uses epoch.

[glebius]

• Improve per Hans's suggestions.

[• hselasky]

sys/sys/proc.h

370

The per-CPU list can be accessed in a critial section w/o risk of other CPU's modifying it. Can you explain again why this is not possible? I still need some more time to review your patch.

[• hselasky]

sys/kern/subr_epoch.c

209

You could do a critical enter here and iterate the per-cpu list instead, because we are not allowed to switch CPU in an EPOCH section. I really want to try to avoid adding new members to struct thread.

[glebius]

sys/kern/subr_epoch.c

209

I would still need to link threads into the list, so instead of SLIST_HEAD in the thread, I would need SLIST_ENTRY.

Also, I'm not sure entering the critical section during list iteration would be enough to preserve integrity.

P.S. struct thread will lose some other epoch related fields soon, once I sweep through all NIC drivers that use if_addr_lock().

[• hselasky]

sys/kern/subr_epoch.c

209

For the non-preemtive epochs, there is not a per-thread SLIST, but for the preemptive ones there is the epoch tracker structure.

I guess you are aware about that?

[glebius]

sys/kern/subr_epoch.c

209

Sure. The scope of this patch is only preemptive epochs, since they are more widely used in the kernel and they also cover large branches of code, hence the need for a tracing facility.

[• hselasky]

sys/kern/kern_thread.c

671

When a thread is destroyed, should we assert that this list is empty?
Does this init also cover thread0 ?

[• hselasky]

I'm fine with the "epoch->e_name = name;" change and its dependencies. Can this be committed separately?

[glebius]

• Merge remote-tracking branch 'FreeBSD/master' into epoch-trace
• More from Hans's review.

[• hselasky]

Looks good.

[glebius]

Committed