On Fri, 10 Jun 2022 17:52:05 +0200 Sumanth Korikkar <sumanthk@xxxxxxxxxxxxx> wrote: [...] > > * Bisected the crash to this commit. > > To reproduce: > * clone libhugetlbfs: > * Execute, PATH=$PATH:"obj64/" LD_LIBRARY_PATH=../obj64/ alloc-instantiate-race shared > > Crashes on both s390 and x86. FWIW, not really able to understand the code changes, so I added some printks to track the state of inode->i_data.nrpages during remove_inode_hugepages(). Before this commit, we enter with nrpages = 99, and leave with nrpages = 0. With this commit we enter with nrpages = 99, and leave with nrpages = 84 (i.e. 99 - PAGEVEC_SIZE), resulting in the BUG later in fs/inode.c:612. The difference seems to be that with this commit, the outer while(filemap_get_folios) loop is only traversed once, while before the corresponding while(pagevec_lookup_range) loop was repeated until nrpages reached 0 (in steps of 15 == PAGEVEC_SIZE for the inner loop). Both before and after the commit, the pagevec_count / folio_batch_count for the inner loop starts with 15, but before the pagevec_lookup_range() also increased &next in steps of 15, while now the filemap_get_folios() moved &next from 0 to 270 in one step, while still only returning 15 as folio_batch_count for the inner loop. I assume the next index of 270 is then too big to find any other folios, so it stops after the first iteration, even though only 15 pages have been processed yet with remove_huge_page(&folio->page). I guess it is either wrong to return 15 as folio_batch_count (although it seems that would be the maximum possible value), or it is wrong to advance &next by 270 instead of 15. Hope that makes any sense, and might be of help for debugging, to someone more familiar with this code.
