On Thu, 3 Sep 2020 19:30:26 +0100 "Matthew Wilcox (Oracle)" <willy@xxxxxxxxxxxxx> wrote: > As described more verbosely in the [3/3] changelog, we can > inadvertently put an order-0 page in the page cache which > occupies 512 consecutive entries. Users are running into > this if they enable the READ_ONLY_THP_FOR_FS config option; > see https://bugzilla.kernel.org/show_bug.cgi?id=206569 > and Qian Cai has also reported it here: > https://lore.kernel.org/lkml/20200616013309.GB815@xxxxxx/ > > This is a rather intrusive way of fixing the problem, but has the > advantage that I've actually been testing it with the THP patches, > which means that it sees far more use than it does upstream -- indeed, > Song has been entirely unable to reproduce it. It also has the advantage > that it removes a few patches from my gargantuan backlog of THP patches. ERROR: modpost: "xa_get_order" [lib/test_xarray.ko] undefined! ERROR: modpost: "xas_split_alloc" [lib/test_xarray.ko] undefined! xarray is an odd mixture of EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(). I did this: --- a/lib/xarray.c~xarray-add-xas_split-fix +++ a/lib/xarray.c @@ -1025,6 +1025,7 @@ nomem: xas_destroy(xas); xas_set_err(xas, -ENOMEM); } +EXPORT_SYMBOL_GPL(xas_split_alloc); /** * xas_split() - Split a multi-index entry into smaller entries. _ and --- a/lib/xarray.c~xarray-add-xa_get_order-fix +++ a/lib/xarray.c @@ -1631,6 +1631,7 @@ unlock: return order; } +EXPORT_SYMBOL(xa_get_order); #endif /* CONFIG_XARRAY_MULTI */ /** _
