On 9/2/2022 5:30 AM, Vlastimil Babka wrote: > On 9/2/22 11:26, Vlastimil Babka wrote: >> On 9/2/22 00:17, Joel Fernandes (Google) wrote: >>> From: Vlastimil Babka <vbabka@xxxxxxx> >>> >>> Joel reports [1] that increasing the rcu_head size for debugging >>> purposes used to work before struct slab was split from struct page, but >>> now runs into the various SLAB_MATCH() sanity checks of the layout. >>> >>> This is because the rcu_head in struct page is in union with large >>> sub-structures and has space to grow without exceeding their size, while >>> in struct slab (for SLAB and SLUB) it's in union only with a list_head. >>> >>> On closer inspection (and after the previous patch) we can put all >>> fields except slab_cache to a union with rcu_head, as slab_cache is >>> sufficient for the rcu freeing callbacks to work and the rest can be >>> overwritten by rcu_head without causing issues. >>> >>> This is only somewhat complicated by the need to keep SLUB's >>> freelist+counters aligned for cmpxchg_double. As a result the fields >>> need to be reordered so that slab_cache is first (after page flags) and >>> the union with rcu_head follows. For consistency, do that for SLAB as >>> well, although not necessary there. >>> >>> As a result, the rcu_head field in struct page and struct slab is no >>> longer at the same offset, but that doesn't matter as there is no >>> casting that would rely on that in the slab freeing callbacks, so we can >>> just drop the respective SLAB_MATCH() check. >>> >>> Also we need to update the SLAB_MATCH() for compound_head to reflect the >>> new ordering. >>> >>> While at it, also add a static_assert to check the alignment needed for >>> cmpxchg_double so mistakes are found sooner than a runtime GPF. >>> >>> [1] https://lore.kernel.org/all/85afd876-d8bb-0804-b2c5-48ed3055e702@xxxxxxxxxxxxxxxxx/ >>> >>> Reported-by: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> >>> Signed-off-by: Vlastimil Babka <vbabka@xxxxxxx> >> >> I've added patches 01 and 02 to slab tree for -next exposure before Joel's >> full series posting, but it should be also ok if rcu tree carries them with >> the whole patchset. I can then drop them from slab tree (there are no >> dependencies with other stuff there) so we don't introduce duplicite commits >> needlessly, just give me a heads up. > > Ah but in that case please apply the reviews from my posting [1] > > patch 1: > Reviewed-by: Hyeonggon Yoo <42.hyeyoo@xxxxxxxxx> > > patch 2 > Acked-by: Hyeonggon Yoo <42.hyeyoo@xxxxxxxxx> > > [1] https://lore.kernel.org/all/20220826090912.11292-1-vbabka@xxxxxxx/ Sorry for injecting confusion - my main intent with including the mm patches in this series is to make it easier for other reviewers/testers to backport the series to their kernels in one shot. Some reviewers expressed interested in trying out the series. I think it is best to let the -mm patches in the series go through the slab tree, as you also have the Acks/Reviews there and will take sure those dependencies are out of the way. My lesson here is to be more clear, I could have added some notes for context below the "---" of those mm patches. Thanks again for your help, - Joel
