lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20220610203530.7f84bbc0@thinkpad> Date: Fri, 10 Jun 2022 20:35:30 +0200 From: Gerald Schaefer <gerald.schaefer@...ux.ibm.com> To: willy@...radead.org Cc: Sumanth Korikkar <sumanthk@...ux.ibm.com>, linux-ext4@...r.kernel.org, gor@...ux.ibm.com, agordeev@...ux.ibm.com, linux-f2fs-devel@...ts.sourceforge.net, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org, linux-nilfs@...r.kernel.org, linux-s390@...r.kernel.org Subject: Re: [PATCH 06/10] hugetlbfs: Convert remove_inode_hugepages() to use filemap_get_folios() On Fri, 10 Jun 2022 17:52:05 +0200 Sumanth Korikkar <sumanthk@...ux.ibm.com> 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.
Powered by blists - more mailing lists