[RFC] include/interval_set: iterate until p->first < start

[dparmar18]

Contribution Guidelines

• To sign and title your commits, please refer to Submitting Patches to Ceph.

• If you are submitting a fix for a stable branch (e.g. "pacific"), please refer to Submitting Patches to Ceph - Backports for the proper workflow.

Checklist

• Tracker (select at least one)
  • References tracker ticket
  • Very recent bug; references commit where it was introduced
  • New feature (ticket optional)
  • Doc update (no ticket needed)
  • Code cleanup (no ticket needed)
• Component impact
  • Affects Dashboard, opened tracker ticket
  • Affects Orchestrator, opened tracker ticket
  • No impact that needs to be tracked
• Documentation (select at least one)
  • Updates relevant documentation
  • No doc update is appropriate
• Tests (select at least one)
  • Includes unit test(s)
  • Includes integration test(s)
  • Includes bug reproducer
  • No tests

Show available Jenkins commands

• jenkins retest this please
• jenkins test classic perf
• jenkins test crimson perf
• jenkins test signed
• jenkins test make check
• jenkins test make check arm64
• jenkins test submodules
• jenkins test dashboard
• jenkins test dashboard cephadm
• jenkins test api
• jenkins test docs
• jenkins render docs
• jenkins test ceph-volume all
• jenkins test ceph-volume tox
• jenkins test windows

[dparmar18]

there are a couple of crash trackers where assertion fails at ceph_assert(p->first <= start); in void erase(). The places are different but the assertion failure is same. Failures at these places will definitely be addressed but I feel these helpers need some changes too.

Existing code does decrement by one in case the key is gt than start but only once and so the decremented element's key should still be gt than start. I.e. the single decrement might not be enough, therefore keep decrementing until p->first is less than start; break and return.

https://tracker.ceph.com/issues/62356
https://tracker.ceph.com/issues/54943
https://tracker.ceph.com/issues/60241

[dparmar18]

@lxbsz

[lxbsz]

This is buggy. Old code will make sure that the p won't be .end(), but yours seems will crash ?

[dparmar18]

so if we dont hit this if {} then it assume either p->first > start or p==m.end(), so in this case we decrement --p

[dparmar18]

i.e. it wont hit end() here either

[lxbsz]

Won't the m.lower_bound() return .end() if it couldn't find any item ?

[dparmar18]

okay so you're implying that we should just return directly in case we dont find anything in the map, right? you're correct, i need to handle this edge case. decrementing in case there is nothing would be disastrous

[lxbsz]

Yeah, the corner edge case.

[dparmar18]

check now

[lxbsz]

In erase() it will check ceph_assert(p != m.end()); . Your above change could return .end().

[dparmar18]

This PR doesn't make sense now, the working of lower_bound is such that it will return an iterator pointing to an element that is just greater than the start, so the p doesn't need to be iterated through the entire map; just a single decrement is enough.

This doesn't mean the interval_set code is entirely perfect, the lower_bound() code has to do the adjustments --p / ++p to make sure that element the iterator is pointing to is correct. The code definitely needs some corrections for sure but since the priority is to send a fix for the mentioned crash trackers, i'll leave this for some other day. Closing this PR for now, if anyone has any comments/suggestions to add; please feel free to do it anytime.