Nathan Lynch <nath...@linux.ibm.com> writes: > Michael Ellerman <m...@ellerman.id.au> writes: >> Tyrel Datwyler <tyr...@linux.ibm.com> writes: >>> On 8/11/20 6:20 PM, Nathan Lynch wrote: >>>> >>>> +static inline struct drmem_lmb *drmem_lmb_next(struct drmem_lmb *lmb) >>>> +{ >>>> + const unsigned int resched_interval = 20; >>>> + >>>> + BUG_ON(lmb < drmem_info->lmbs); >>>> + BUG_ON(lmb >= drmem_info->lmbs + drmem_info->n_lmbs); >>> >>> I think BUG_ON is a pretty big no-no these days unless there is no other >>> option. >> >> It's complicated, but yes we would like to avoid adding them if we can. >> >> In a case like this there is no other option, *if* the check has to be >> in drmem_lmb_next(). >> >> But I don't think we really need to check that there. >> >> If for some reason this was called with an *lmb pointing outside of the >> lmbs array it would confuse the cond_resched() logic, but it's not worth >> crashing the box for that IMHO. > > The BUG_ONs are pretty much orthogonal to the cond_resched().
Yes that was kind of my point. We don't need them to implement the cond_resched() logic. > It's not apparent from the context of the change, but some users of the > for_each_drmem_lmb* macros modify elements of the drmem_info->lmbs > array. If the lmb passed to drmem_lmb_next() violates the bounds check > (say, if the callsite inappropriately modifies it within the loop), such > users are guaranteed to corrupt other objects in memory. This was my > thinking in adding the BUG_ONs, and I don't see another place to do > it. If it's really something we're worried about, I think we'd be better off putting checks for that in the code that's doing those modifications. That way you have enough context to do something more nuanced than a BUG(), ie. you can print a useful message and fail whatever operation is in progress. If we did that then we could also add those BUG_ONs() as a safety net. What you really want is a way for the for_each_xxx() construct to express that there was an error traversing the list, but there isn't really a nice way to do that in C. cheers