On Wed, Jul 05, 2023 at 02:55:16PM +0200, Gerald Schaefer wrote: > Ah ok, I was aware of that "semi-RCU" fallback logic in tlb_remove_table(), > but that is rather a generic issue, and not s390-specific. I thought you > meant some s390-oddity here, of which we have a lot, unfortunately... > Of course, we call tlb_remove_table() from our page_table_free_rcu(), so > I guess you could say that page_table_free_rcu() cannot guarantee what > tlb_remove_table() cannot guarantee. The issue is the arches don't provide a reliable way to RCU free things, so the core code creates an RCU situation using the MMU batch. With the non-RCU compatible IPI fallback. So it isn't actually RCU, it is IPI but optimized with RCU in some cases. When Hugh introduces a reliable way to RCU free stuff we could fall back to that in the TLB code instead of invoking the synchronize_rcu() For lots of arches, S390 included after this series, this would be pretty easy. What I see now as the big trouble is that this series only addresses PTE RCU'ness and making all the other levels RCUable would be much harder on some arches like power. In short we could create a CONFIG_ARCH_RCU_SAFE_PAGEWALK and it could be done on alot of arches quite simply, but at least not power. Which makes me wonder about the value, but maybe it could shame power into doing something.. However, calling things 'page_table_free_rcu()' when it doesn't actually always do RCU but IPI optimzed RCU is an unfortunate name :( As long as you never assume it does RCU anywhere else, and don't use rcu_read_lock(), it is fine :) The corner case is narrow, you have to OOM the TLB batching before you loose the RCU optimization of the IPI. Then you can notice that rcu_read_lock() doesn't actually protect against concurrent free. Jason
