On Thu, Feb 10, 2022 at 12:07:33AM -0500, Theodore Ts'o wrote: > On Wed, Feb 09, 2022 at 12:11:37PM -0800, Paul E. McKenney wrote: > > On Wed, Feb 09, 2022 at 07:10:10PM +0100, Jan Kara wrote: > > > > > > No, the performance impact of this would be just horrible. Can you > > > ellaborate a bit why SLAB_TYPESAFE_BY_RCU + __GFP_ZERO is a problem and why > > > synchronize_rcu() would be needed here before the memset() please? I mean > > > how is zeroing here any different from the memory just being used? > > > > Suppose a reader picks up a pointer to a memory block, then that memory > > is freed. No problem, given that this is a SLAB_TYPESAFE_BY_RCU slab, > > so the memory won't be freed while the reader is accessing it. But while > > the reader is in the process of validating the block, it is zeroed. > > > > How does the validation step handle this in all cases? > > > > If you have a way of handling this, I will of course drop the patch. > > And learn something new, which is always a good thing. ;-) > > I must be missing something. The change is on the allocation path, > and why would kmem_cache_[z]alloc() return a memory chunk which could > still be in use by a reader? Shouldn't the allocator _not_ return a > particular chunk until it is sure there aren't any readers left that > would be discombobulated by that memory being used for some new use > case?
