> > On 10/23/20 5:11 AM, Oscar Salvador wrote: > > On Fri, Oct 23, 2020 at 01:32:54PM +0200, Laurent Cremmer wrote: > >> I came to the same conclusion with the help of David's remarks :-) . > >> And in the end, this patch would be more about fixing the readability > >> of the code than fixing a live problem per-se. If it ain't broken, > >> don't fix it as they say :-) > > > > Yeah, definitely the code could benefit from a cleanup, so no one > > has to stare at it for a while before he gets the idea. > > INDEED, those *region* routines dealing with reservation maps are difficult > to understand, and could benefit from some cleanup. Recent changes to add > support for reservation cgroup support made them even more complex. > > Laurent, thank you for taking the time to look into this. And thanks to > Oscar and David for their analysis. The suggested patch would make the > code more readable. However, that would be at the expense of another > (and unnecessary) lock/unlock cycle. I'll add cleanup of these routines > to my 'todo' list, but would be happy to work with anyone else who wants > to take on this task. > -- Hi Mike, I gave it a deeper look (although I'm not familiar enough with the whole subsystem to really qualify!) and could not come up with an easy "way" out. In the end it might depend on how often the error path is taken and if the unnecessary lock/unlock cycle does really hurt under pressure. What really tripped me (and smatch) is the erroneous " __must_hold(&resv->lock)" annotation of the allocate_file_region_entries function. It would be better suited to the function above (add_reservation_in_range). If you think that adding documentation would be helpful, I can do that. In any case, thanks for taking the time to review and consider adding to your todo list. much appreciated. Laurent.
