On 3/18/25 15:47, Hannes Reinecke wrote: > Hey all, > > (Thanks, Jon, for the title :-) > the recent discussion around frozen pages and when to do a > get_page()/put_page() and when not resulted in quite some unresolved issues. > So I would like to propose a session at LSF/MM: > > 'Warming up to frozen pages' > With the frozen pages patchset from Willy slab pages don't need > (and, in fact, can have) a page reference anymore. While this easy BTW, my hope is that large kmalloc folios would also drop the refcount. That means anything obtained by kmalloc(N) where N is over 8k (order-1 folio on 4k PAGE_SIZE). That 8k is an implementation detail of SLUB (SLAB used to have more) and thus all kmalloc() buffers should better behave the same to avoid surprises when some particular allocation size changes, or the thing becomes used on an architecture with larger than 4k page size and thus becomes a "small" kmalloc() there. Willy already added a page type for large kmalloc. Given we can expect possible troubles after the small kmalloc() ones already hit us, I'd first just add get_page()/put_page() warnings for that large kmalloc page type in addition to the slab page type ones and expose that to -next (after the 6.15 merge window) to see if something needs fixing. > to state, and to implement when using iov iterators, problems > arise when these iov iterators get mangled eg when being passed > via the various layers in the kernel. > Case in point: 'recvmsg()', when called from userspace, is being > passed an iov, and the iterator type defines if a page reference > need to be taken. However, when called from other kernel subsystems > (eg from nvme-tcp or iscsi), the iov is filled from a bvec which > in itself is filled from an iov iter from userspace, so the iov > iterator will assume it's a 'normal' bvec, and get a reference for > all entries as it wouldn't know which entry is a 'normal' and which > is a 'slab' page. > As Christoph indicated this is _not_ how things should be, so > a discussion on how to disentangle this would be good. > Maybe we even manage to lay down some rules when a page reference > should be taken and when not. > > Cheers, > > Hannes
