ktr: Avoid assertion failures from an unlocked STAILQ_EMPTY check

[markj]

Summary

Commit 34740937f7a4 ("queue: New debug macros for STAILQ") added a new
invariant check to STAILQ_EMPTY which validates the tail pointer. This
check can fail if the STAILQ_EMPTY check is unlocked. Introduce a new
STAILQ_EMPTY variant to work around this, and use it in ktr_drain(),
where such a race is possible.

Reported by: [e-mail]

[olce]

Thanks. I think it's worthwhile to keep the added check, which can't be guaranteed to work when an atomic access is necessary without resorting to more drastic measures.

[markj]

In D48899#1115340, @olce wrote:

Thanks. I think it's worthwhile to keep the added check, which can't be guaranteed to work when an atomic access is necessary without resorting to more drastic measures.

Certainly, I'd rather have an explicit variant for atomic checks anyway.

[markj]

In D48899#1115385, @markj wrote:

In D48899#1115340, @olce wrote:

Thanks. I think it's worthwhile to keep the added check, which can't be guaranteed to work when an atomic access is necessary without resorting to more drastic measures.

Certainly, I'd rather have an explicit variant for atomic checks anyway.

That said, shouldn't we add the new check to TAILQ_EMPTY() as well, and add TAILQ_EMPTY_ATOMIC() etc.?

[olce]

Thanks. I think it's worthwhile to keep the added check, which can't be guaranteed to work when an atomic access is necessary without resorting to more drastic measures.

In D48899#1115385, @markj wrote:

Certainly, I'd rather have an explicit variant for atomic checks anyway.

I concur.

In D48899#1115386, @markj wrote:

That said, shouldn't we add the new check to TAILQ_EMPTY() as well, and add TAILQ_EMPTY_ATOMIC() etc.?

Most probably, yes. I'll be off next week, but can take care of that when coming back (not preventing you from doing it in the meantime if you prefer).