All the mistakes mentioned by the reviewers have been corrected in this patch.

Thanks a lot for reviewing ipfw AQM man page patch. I have corrected all the mistakes that you mentioned and created a new patch against the current ipfw.8 man page.

Thank you for reviewing the patch. I have revised that patch and checked it using mandoc -Tlint and igor. Hopefully, it is OK now.

Should I remove DN_BH_WLOCK()/DN_BH_WUNLOCK() and use atomic_add_int() instead?
Is the patch reasonable now?

Sorry if my thought is incorrect but just to explain my idea of using DN_BH_WLOCK():
1- ref_count (namely pie_desc.ref_count) is updated only by PIE module and checked (read access) by unload_dn_sched() in ip_dummynet.c.
2- ref_count in unload_dn_sched() is accessed with DN_BH_WLOCK()
3- ref_count in PIE module is updated when DN_BH_WLOCK() is held (either explicitly by calling DN_BH_WLOCK() in PIE module or implicitly by Dummynet somewhere before call PIE functions.
So, is the lock I added still isn't sufficient?
Anyway, using atomic_add_int() is much easier than dealing with deadlocks ;-)

If PIE ref_count is decremented by the user thread after callout_reset_sbt(), how we guarantee that pie_callout_cleanup() finished its execution?
Thus, I used DN_BH_WLOCK() and DN_BH_WUNLOCK() (provided by Dummynet) to make ref_count manipulation atomic.

Based on truckman (Don Lewis) suggestions, the race fixed by resetting the callout in aqm_pie_cleanup() to call pie_callout_cleanup() and removing memory freeing from calculate_drop_prob(). No additional flags are needed.
This patch was tested and no kernel panic happens.

fq_pie also has a callout but no kernel panic has been reported for fq_pie. After we finish from PIE fixing we can have a look at fq_pie.

Based on truckman suggestion, the callout_pending()/callout_active()/callout_deactivate() stuff has been removed since they are not required when callout_init_mtx() is used.