On Mon, Dec 14, 2020 at 8:07 AM Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote: > > Here it is. Still barely tested. Ok, from looking at the patch (not applying it and looking at the end result), I think the locking - at least for the filemap_map_pages() case - is a lot easier to understand. So you seem to have fixed the thing I personally found most confusing. Thanks. > I expected to hate it more, but it looks reasonable. Opencoded > xas_for_each() smells bad, but... I think the open-coded xas_for_each() per se isn't a problem, but I agree that the startup condition is a bit ugly. And I'm actually personally more confused by why xas_retry() is needed here, bit not in many other places. That is perhaps more obvious now that it shows up twice. Adding Willy to the cc in case he has comments on that, and can explain it to me in small words. [ https://lore.kernel.org/lkml/20201214160724.ewhjqoi32chheone@box/ for context ] And I actually think it might make even more sense if you moved more of the pmd handling into "filemap_map_pages_pmd()". Now it's a bit odd, with filemap_map_pages() containing part of the pmd handling, and then part being in filemap_map_pages_pmd(). Could we have a "filemap_map_pmd()" that does it all, and then the filemap_map_pages() logic would be more along the lines of if (filemap_map_pmd(vmf, xas)) { rcu_read_unlock(); return; } ... then handle pte's ... Hmm? There may be some shared state thing why you didn't do it, the above is mostly a syntactic issue. Thanks, Linus
