folio_change_private(9)
π folio_change_private β the kernel API manual, but make it make sense
ok so bestie, you know how there's this whole folio_change_private(9) thing in the Kernel API Manual? Yeah. We're doing this. Sit down, grab a lil snack π, and let me tell you about the one function that swaps out a folio's private data like it's trading friendship bracelets.
β¨ NAME β¨
folio_change_private β Change private data on a folio.
That's it. That's the whole vibe. It changes the private data. On a folio. π¦
π SYNOPSIS π
void * folio_change_private (struct folio *folio , void *data );
Look at that signature. void * in, void * out β the kernel's favourite little mystery box π
πΈ ARGUMENTS πΈ
folioβ the folio we're changing the data on. it's giving main character energy, everything happens to it πdataβ the data to set on the folio. whatever you're handing over, it goes right here π«Ά
π DESCRIPTION π
Okay so real talk. This function changes the private data attached to a folio, and then it hands you back the old data. Like a swap. A trade. A lil exchange program for pointers π₯
But here's the important part, and I need you to actually listen to this one, no cap:
The page must previously have had data attached, and the data must be detached before the folio will be freed.
So it's not a "set it and forget it" situation. You can't just roll up on a folio with no private data and expect things to go well, and you definitely can't leave your data attached and expect the folio to get freed. Detach your stuff. Clean up after yourself. Be a person. π
β RETURN β
It returns the data that was previously attached to the folio β aka the old one, the one that was there before you showed up. iconic behaviour honestly π
π SEE ALSO π
okay this list is LONG, buckle up bestie, it's the whole crew:
Kernel file ./include/linux/pagemap.h β filemap_set_wb_err(9), filemap_check_wb_err(9), filemap_sample_wb_err(9), file_sample_sb_err(9), mapping_set_error(9), mapping_set_large_folios(9), mapping_align_index(9), mapping_pmd_folio_support(9), folio_flush_mapping(9), folio_inode(9), folio_attach_private(9), folio_detach_private(9), fgf_t(9), fgf_set_order(9), write_begin_get_folio(9), filemap_get_folio(9), filemap_lock_folio(9), filemap_grab_folio(9), find_get_page(9), find_lock_page(9), find_or_create_page(9), grab_cache_page_nowait(9), folio_next_index(9), folio_next_pos(9), folio_file_page(9), folio_contains(9), page_pgoff(9), folio_pos(9), linear_page_delta(9), linear_page_index(9), linear_anon_page_index(9), folio_trylock(9), folio_lock(9), lock_page(9), folio_lock_killable(9), filemap_range_needs_writeback(9), struct readahead_control(9), page_cache_sync_readahead(9), page_cache_async_readahead(9), readahead_folio(9), readahead_pos(9), readahead_length(9), readahead_index(9), readahead_count(9), readahead_batch_length(9), folio_mkwrite_check_truncate(9), i_blocks_per_folio(9)
Honestly? Go read folio_attach_private(9) and folio_detach_private(9) first, they're literally the prequel and the sequel to this one π§ iykyk
π gentle reminder bestie: attach then detach. don't leave a folio holding your data hostage. the kernel WILL notice. π
ok that's the page!! slay π this one's from ./include/linux, dated October 2026 β so like, the version of the future, and it's serving. bye bestie, go change some private data responsibly πΈβ¨
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms