On 3/8/25 3:40 PM, Toke Høiland-Jørgensen wrote: > Yunsheng Lin <yunshenglin0825@xxxxxxxxx> writes: >> I only took a glance at git code above, it seems reusing the >> _pp_mapping_pad for pp_dma_index seems like a wrong direction >> as mentioned in discussion with Ilias above as the field might >> be used when a page is mmap'ed to user space, and reusing that >> field in 'struct page' seems to disable the tcp_zerocopy feature, >> see the below commit from Eric: >> https://github.com/torvalds/linux/commit/577e4432f3ac810049cb7e6b71f4d96ec7c6e894 >> >> Also, I am not sure if a page_pool owned page can be spliced into the fs >> subsystem yet, but if it does, I am not sure how is reusing the >> page->mapping possible if that page is called in __filemap_add_folio()? >> >> https://elixir.bootlin.com/linux/v6.14-rc5/source/mm/filemap.c#L882 > > Hmm, so I did look at the mapping field, but concluded using it wouldn't > interfere with anything relevant as long as it's reset back to zero > before the page is returned to the page allocator. However, I definitely > missed the TCP zero-copy thing, and other things as well, it would seem > (cf the discussion you referred to above). > > However, I did consider alternatives: AFAICT there should be space in > the pp_magic field (used for the PP_SIGNATURE), so that with a bit of > care we can stick an ID into the upper bits and still avoid ending up > with a value that could look like a valid pointer. > > I didn't implement that initially because I wasn't sure it was > necessary, but seeing as it is, I will take another look at it. I have > one or two other ideas if this turns out not to pan out. Another dumb option would be storing directly the page address in the xarray, and avoid entirely going through an ID. I guess it will use more memory (the array will be more sparse) and will have more overhead, but could be possibly simpler? /P
