On Mon, 1 Jul 2019 14:23:03 -0700 Henry Burns <henrybu...@google.com> wrote:
> __SetPageMovable() expects it's page to be locked, but z3fold.c doesn't > lock the page. So this triggers the VM_BUG_ON_PAGE(!PageLocked(page), page) in __SetPageMovable(), yes? > Following zsmalloc.c's example we call trylock_page() and > unlock_page(). Also makes z3fold_page_migrate() assert that newpage is > passed in locked, as documentation. > > ... > > --- a/mm/z3fold.c > +++ b/mm/z3fold.c > @@ -918,7 +918,9 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t > size, gfp_t gfp, > set_bit(PAGE_HEADLESS, &page->private); > goto headless; > } > + WARN_ON(!trylock_page(page)); If this warn triggers then someone else has locked the page. > __SetPageMovable(page, pool->inode->i_mapping); > + unlock_page(page); and we proceed to undo their lock. So that other code path will then perform an unlock of an unlocked page. Etcetera. It would be much much better to do a plain old lock_page() here. If that results in a deadlock then let's find out why and fix it without trylock hacks.
