| Message ID | 20250314-page-pool-track-dma-v1-3-c212e57a74c2@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Fix late DMA unmap crash for page pool | expand |
On 3/14/2025 6:10 PM, Toke Høiland-Jørgensen wrote: ... > > To avoid having to walk the entire xarray on unmap to find the page > reference, we stash the ID assigned by xa_alloc() into the page > structure itself, using the upper bits of the pp_magic field. This > requires a couple of defines to avoid conflicting with the > POINTER_POISON_DELTA define, but this is all evaluated at compile-time, > so does not affect run-time performance. The bitmap calculations in this > patch gives the following number of bits for different architectures: > > - 24 bits on 32-bit architectures > - 21 bits on PPC64 (because of the definition of ILLEGAL_POINTER_VALUE) > - 32 bits on other 64-bit architectures From commit c07aea3ef4d4 ("mm: add a signature in struct page"): "The page->signature field is aliased to page->lru.next and page->compound_head, but it can't be set by mistake because the signature value is a bad pointer, and can't trigger a false positive in PageTail() because the last bit is 0." And commit 8a5e5e02fc83 ("include/linux/poison.h: fix LIST_POISON{1,2} offset"): "Poison pointer values should be small enough to find a room in non-mmap'able/hardly-mmap'able space." So the question seems to be: 1. Is stashing the ID causing page->pp_magic to be in the mmap'able/ easier-mmap'able space? If yes, how can we make sure this will not cause any security problem? 2. Is the masking the page->pp_magic causing a valid pionter for page->lru.next or page->compound_head to be treated as a vaild PP_SIGNATURE? which might cause page_pool to recycle a page not allocated via page_pool. > > Since all the tracking is performed on DMA map/unmap, no additional code > is needed in the fast path, meaning the performance overhead of this > tracking is negligible. A micro-benchmark shows that the total overhead > of using xarray for this purpose is about 400 ns (39 cycles(tsc) 395.218 > ns; sum for both map and unmap[1]). Since this cost is only paid on DMA > map and unmap, it seems like an acceptable cost to fix the late unmap For most use cases when PP_FLAG_DMA_MAP is set and IOMMU is off, the DMA map and unmap operation is almost negligible as said below, so the cost is about 200% performance degradation, which doesn't seems like an acceptable cost. > issue. Further optimisation can narrow the cases where this cost is > paid (for instance by eliding the tracking when DMA map/unmap is a > no-op). The above was discussed in [1] and brought up again in [2], so cc Robin to see if there is any clarifying to see if he still view the above as misuse of DMA API. 1. https://lore.kernel.org/all/9a4d1357-f30d-420d-a575-7ae305ca6dda@huawei.com/ 2. https://lore.kernel.org/all/caf31b5e-0e8f-4844-b7ba-ef59ed13b74e@arm.com/ > > The extra memory needed to track the pages is neatly encapsulated inside > xarray, which uses the 'struct xa_node' structure to track items. This > structure is 576 bytes long, with slots for 64 items, meaning that a > full node occurs only 9 bytes of overhead per slot it tracks (in > practice, it probably won't be this efficient, but in any case it should Is there any debug infrastructure to know if it is not this efficient? as there may be 576 byte overhead for a page for the worst case. > be an acceptable overhead). > > [0] https://lore.kernel.org/all/CAHS8izPg7B5DwKfSuzz-iOop_YRbk3Sd6Y4rX7KBG9DcVJcyWg@mail.gmail.com/ > [1] https://lore.kernel.org/r/ae07144c-9295-4c9d-a400-153bb689fe9e@huawei.com > > Reported-by: Yonglong Liu <liuyonglong@huawei.com> > Closes: https://lore.kernel.org/r/8743264a-9700-4227-a556-5f931c720211@huawei.com > Fixes: ff7d6b27f894 ("page_pool: refurbish version of page_pool code") > Suggested-by: Mina Almasry <almasrymina@google.com> > Reviewed-by: Mina Almasry <almasrymina@google.com> > Reviewed-by: Jesper Dangaard Brouer <hawk@kernel.org> > Tested-by: Jesper Dangaard Brouer <hawk@kernel.org> > Tested-by: Qiuling Ren <qren@redhat.com> > Tested-by: Yuying Ma <yuma@redhat.com> > Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> ... > @@ -1084,8 +1112,32 @@ static void page_pool_empty_alloc_cache_once(struct page_pool *pool) > > static void page_pool_scrub(struct page_pool *pool) > { > + unsigned long id; > + void *ptr; > + > page_pool_empty_alloc_cache_once(pool); > - pool->destroy_cnt++; > + if (!pool->destroy_cnt++ && pool->dma_map) { > + if (pool->dma_sync) { > + /* paired with READ_ONCE in > + * page_pool_dma_sync_for_device() and > + * __page_pool_dma_sync_for_cpu() > + */ > + WRITE_ONCE(pool->dma_sync, false); > + > + /* Make sure all concurrent returns that may see the old > + * value of dma_sync (and thus perform a sync) have > + * finished before doing the unmapping below. Skip the > + * wait if the device doesn't actually need syncing, or > + * if there are no outstanding mapped pages. > + */ > + if (dma_dev_need_sync(pool->p.dev) && > + !xa_empty(&pool->dma_mapped)) > + synchronize_net(); I guess the above synchronize_net() is assuming that the above dma sync API is always called in the softirq context, as it seems there is no rcu read lock added in this patch to be paired with that. Doesn't page_pool_put_page() might be called in non-softirq context when allow_direct is false and in_softirq() returns false? > + } > + > + xa_for_each(&pool->dma_mapped, id, ptr) > + __page_pool_release_page_dma(pool, page_to_netmem(ptr)); > + } > > /* No more consumers should exist, but producers could still > * be in-flight. >
Yunsheng Lin <yunshenglin0825@gmail.com> writes: > On 3/14/2025 6:10 PM, Toke Høiland-Jørgensen wrote: > > ... > >> >> To avoid having to walk the entire xarray on unmap to find the page >> reference, we stash the ID assigned by xa_alloc() into the page >> structure itself, using the upper bits of the pp_magic field. This >> requires a couple of defines to avoid conflicting with the >> POINTER_POISON_DELTA define, but this is all evaluated at compile-time, >> so does not affect run-time performance. The bitmap calculations in this >> patch gives the following number of bits for different architectures: >> >> - 24 bits on 32-bit architectures >> - 21 bits on PPC64 (because of the definition of ILLEGAL_POINTER_VALUE) >> - 32 bits on other 64-bit architectures > > From commit c07aea3ef4d4 ("mm: add a signature in struct page"): > "The page->signature field is aliased to page->lru.next and > page->compound_head, but it can't be set by mistake because the > signature value is a bad pointer, and can't trigger a false positive > in PageTail() because the last bit is 0." > > And commit 8a5e5e02fc83 ("include/linux/poison.h: fix LIST_POISON{1,2} > offset"): > "Poison pointer values should be small enough to find a room in > non-mmap'able/hardly-mmap'able space." > > So the question seems to be: > 1. Is stashing the ID causing page->pp_magic to be in the mmap'able/ > easier-mmap'able space? If yes, how can we make sure this will not > cause any security problem? > 2. Is the masking the page->pp_magic causing a valid pionter for > page->lru.next or page->compound_head to be treated as a vaild > PP_SIGNATURE? which might cause page_pool to recycle a page not > allocated via page_pool. Right, so my reasoning for why the defines in this patch works for this is as follows: in both cases we need to make sure that the ID stashed in that field never looks like a valid kernel pointer. For 64-bit arches (where CONFIG_ILLEGAL_POINTER_VALUE), we make sure of this by never writing to any bits that overlap with the illegal value (so that the PP_SIGNATURE written to the field keeps it as an illegal pointer value). For 32-bit arches, we make sure of this by making sure the top-most bit is always 0 (the -1 in the define for _PP_DMA_INDEX_BITS) in the patch, which puts it outside the range used for kernel pointers (AFAICT). >> Since all the tracking is performed on DMA map/unmap, no additional code >> is needed in the fast path, meaning the performance overhead of this >> tracking is negligible. A micro-benchmark shows that the total overhead >> of using xarray for this purpose is about 400 ns (39 cycles(tsc) 395.218 >> ns; sum for both map and unmap[1]). Since this cost is only paid on DMA >> map and unmap, it seems like an acceptable cost to fix the late unmap > > For most use cases when PP_FLAG_DMA_MAP is set and IOMMU is off, the > DMA map and unmap operation is almost negligible as said below, so the > cost is about 200% performance degradation, which doesn't seems like an > acceptable cost. I disagree. This only impacts the slow path, as long as pages are recycled there is no additional cost. While your patch series has demonstrated that it is *possible* to reduce the cost even in the slow path, I don't think the complexity cost of this is worth it. [...] >> The extra memory needed to track the pages is neatly encapsulated inside >> xarray, which uses the 'struct xa_node' structure to track items. This >> structure is 576 bytes long, with slots for 64 items, meaning that a >> full node occurs only 9 bytes of overhead per slot it tracks (in >> practice, it probably won't be this efficient, but in any case it should > > Is there any debug infrastructure to know if it is not this efficient? > as there may be 576 byte overhead for a page for the worst case. There's an XA_DEBUG define which enables some dump functions, but I don't think there's any API to inspect the memory usage. I guess you could attach a BPF program and walk the structure, or something? >> + /* Make sure all concurrent returns that may see the old >> + * value of dma_sync (and thus perform a sync) have >> + * finished before doing the unmapping below. Skip the >> + * wait if the device doesn't actually need syncing, or >> + * if there are no outstanding mapped pages. >> + */ >> + if (dma_dev_need_sync(pool->p.dev) && >> + !xa_empty(&pool->dma_mapped)) >> + synchronize_net(); > > I guess the above synchronize_net() is assuming that the above dma sync > API is always called in the softirq context, as it seems there is no > rcu read lock added in this patch to be paired with that. Yup, that was my assumption. > Doesn't page_pool_put_page() might be called in non-softirq context when > allow_direct is false and in_softirq() returns false? I am not sure if this happens in practice in any of the delayed return paths we are worried about for this patch. If it does we could apply something like the diff below (on top of this patch). I can respin with this if needed, but I'll wait a bit and give others a chance to chime in. -Toke @@ -465,9 +465,13 @@ page_pool_dma_sync_for_device(const struct page_pool *pool, netmem_ref netmem, u32 dma_sync_size) { - if ((READ_ONCE(pool->dma_sync) & PP_DMA_SYNC_DEV) && - dma_dev_need_sync(pool->p.dev)) - __page_pool_dma_sync_for_device(pool, netmem, dma_sync_size); + if (dma_dev_need_sync(pool->p.dev)) { + rcu_read_lock(); + if (READ_ONCE(pool->dma_sync) & PP_DMA_SYNC_DEV) + __page_pool_dma_sync_for_device(pool, netmem, + dma_sync_size); + rcu_read_unlock(); + } } static bool page_pool_dma_map(struct page_pool *pool, netmem_ref netmem, gfp_t gfp)
On 2025/3/17 23:16, Toke Høiland-Jørgensen wrote: > Yunsheng Lin <yunshenglin0825@gmail.com> writes: > >> On 3/14/2025 6:10 PM, Toke Høiland-Jørgensen wrote: >> >> ... >> >>> >>> To avoid having to walk the entire xarray on unmap to find the page >>> reference, we stash the ID assigned by xa_alloc() into the page >>> structure itself, using the upper bits of the pp_magic field. This >>> requires a couple of defines to avoid conflicting with the >>> POINTER_POISON_DELTA define, but this is all evaluated at compile-time, >>> so does not affect run-time performance. The bitmap calculations in this >>> patch gives the following number of bits for different architectures: >>> >>> - 24 bits on 32-bit architectures >>> - 21 bits on PPC64 (because of the definition of ILLEGAL_POINTER_VALUE) >>> - 32 bits on other 64-bit architectures >> >> From commit c07aea3ef4d4 ("mm: add a signature in struct page"): >> "The page->signature field is aliased to page->lru.next and >> page->compound_head, but it can't be set by mistake because the >> signature value is a bad pointer, and can't trigger a false positive >> in PageTail() because the last bit is 0." >> >> And commit 8a5e5e02fc83 ("include/linux/poison.h: fix LIST_POISON{1,2} >> offset"): >> "Poison pointer values should be small enough to find a room in >> non-mmap'able/hardly-mmap'able space." >> >> So the question seems to be: >> 1. Is stashing the ID causing page->pp_magic to be in the mmap'able/ >> easier-mmap'able space? If yes, how can we make sure this will not >> cause any security problem? >> 2. Is the masking the page->pp_magic causing a valid pionter for >> page->lru.next or page->compound_head to be treated as a vaild >> PP_SIGNATURE? which might cause page_pool to recycle a page not >> allocated via page_pool. > > Right, so my reasoning for why the defines in this patch works for this > is as follows: in both cases we need to make sure that the ID stashed in > that field never looks like a valid kernel pointer. For 64-bit arches > (where CONFIG_ILLEGAL_POINTER_VALUE), we make sure of this by never > writing to any bits that overlap with the illegal value (so that the > PP_SIGNATURE written to the field keeps it as an illegal pointer value). > For 32-bit arches, we make sure of this by making sure the top-most bit > is always 0 (the -1 in the define for _PP_DMA_INDEX_BITS) in the patch, > which puts it outside the range used for kernel pointers (AFAICT). Is there any season you think only kernel pointer is relevant here? It seems it is not really only about kernel pointers as round_hint_to_min() in mm/mmap.c suggests and the commit log in the above commit 8a5e5e02fc83 if I understand it correctly: "Given unprivileged users cannot mmap anything below mmap_min_addr, it should be safe to use poison pointers lower than mmap_min_addr." And the above "making sure the top-most bit is always 0" doesn't seems to ensure page->signature to be outside the range used for kernel pointers for 32-bit arches with VMSPLIT_1G defined, see arch/arm/Kconfig, there is a similar config for x86 too: prompt "Memory split" depends on MMU default VMSPLIT_3G help Select the desired split between kernel and user memory. If you are not absolutely sure what you are doing, leave this option alone! config VMSPLIT_3G bool "3G/1G user/kernel split" config VMSPLIT_3G_OPT depends on !ARM_LPAE bool "3G/1G user/kernel split (for full 1G low memory)" config VMSPLIT_2G bool "2G/2G user/kernel split" config VMSPLIT_1G bool "1G/3G user/kernel split" IMHO, even if some trick like above is really feasible, it may be adding some limitation or complexity to the ARCH and MM subsystem, for example, stashing the ID in page->signature may cause 0x*40 signature to be unusable for other poison pointer purpose, it makes more sense to make it obvious by doing the above trick in some MM header file like poison.h instead of in the page_pool subsystem. > >>> Since all the tracking is performed on DMA map/unmap, no additional code >>> is needed in the fast path, meaning the performance overhead of this >>> tracking is negligible. A micro-benchmark shows that the total overhead >>> of using xarray for this purpose is about 400 ns (39 cycles(tsc) 395.218 >>> ns; sum for both map and unmap[1]). Since this cost is only paid on DMA >>> map and unmap, it seems like an acceptable cost to fix the late unmap >> >> For most use cases when PP_FLAG_DMA_MAP is set and IOMMU is off, the >> DMA map and unmap operation is almost negligible as said below, so the >> cost is about 200% performance degradation, which doesn't seems like an >> acceptable cost. > > I disagree. This only impacts the slow path, as long as pages are > recycled there is no additional cost. While your patch series has > demonstrated that it is *possible* to reduce the cost even in the slow > path, I don't think the complexity cost of this is worth it. It is still the datapath otherwise there isn't a specific testing for that use case, more than 200% performance degradation is too much IHMO. Let aside the above severe performance degradation, reusing space in page->signature seems to be a tradeoff between adding complexity in page_pool subsystem and in VM/ARCH subsystem as mentioned above. > > [...] > >>> The extra memory needed to track the pages is neatly encapsulated inside >>> xarray, which uses the 'struct xa_node' structure to track items. This >>> structure is 576 bytes long, with slots for 64 items, meaning that a >>> full node occurs only 9 bytes of overhead per slot it tracks (in >>> practice, it probably won't be this efficient, but in any case it should >> >> Is there any debug infrastructure to know if it is not this efficient? >> as there may be 576 byte overhead for a page for the worst case. > > There's an XA_DEBUG define which enables some dump functions, but I > don't think there's any API to inspect the memory usage. I guess you > could attach a BPF program and walk the structure, or something? > It seems the XA_DEBUG is not defined in production environment. And I am not familiar enough with BPF program to understand if the BPF way is feasiable in production environment. Any example for the above BPF program and how to attach it?
Yunsheng Lin <linyunsheng@huawei.com> writes: > On 2025/3/17 23:16, Toke Høiland-Jørgensen wrote: >> Yunsheng Lin <yunshenglin0825@gmail.com> writes: >> >>> On 3/14/2025 6:10 PM, Toke Høiland-Jørgensen wrote: >>> >>> ... >>> >>>> >>>> To avoid having to walk the entire xarray on unmap to find the page >>>> reference, we stash the ID assigned by xa_alloc() into the page >>>> structure itself, using the upper bits of the pp_magic field. This >>>> requires a couple of defines to avoid conflicting with the >>>> POINTER_POISON_DELTA define, but this is all evaluated at compile-time, >>>> so does not affect run-time performance. The bitmap calculations in this >>>> patch gives the following number of bits for different architectures: >>>> >>>> - 24 bits on 32-bit architectures >>>> - 21 bits on PPC64 (because of the definition of ILLEGAL_POINTER_VALUE) >>>> - 32 bits on other 64-bit architectures >>> >>> From commit c07aea3ef4d4 ("mm: add a signature in struct page"): >>> "The page->signature field is aliased to page->lru.next and >>> page->compound_head, but it can't be set by mistake because the >>> signature value is a bad pointer, and can't trigger a false positive >>> in PageTail() because the last bit is 0." >>> >>> And commit 8a5e5e02fc83 ("include/linux/poison.h: fix LIST_POISON{1,2} >>> offset"): >>> "Poison pointer values should be small enough to find a room in >>> non-mmap'able/hardly-mmap'able space." >>> >>> So the question seems to be: >>> 1. Is stashing the ID causing page->pp_magic to be in the mmap'able/ >>> easier-mmap'able space? If yes, how can we make sure this will not >>> cause any security problem? >>> 2. Is the masking the page->pp_magic causing a valid pionter for >>> page->lru.next or page->compound_head to be treated as a vaild >>> PP_SIGNATURE? which might cause page_pool to recycle a page not >>> allocated via page_pool. >> >> Right, so my reasoning for why the defines in this patch works for this >> is as follows: in both cases we need to make sure that the ID stashed in >> that field never looks like a valid kernel pointer. For 64-bit arches >> (where CONFIG_ILLEGAL_POINTER_VALUE), we make sure of this by never >> writing to any bits that overlap with the illegal value (so that the >> PP_SIGNATURE written to the field keeps it as an illegal pointer value). >> For 32-bit arches, we make sure of this by making sure the top-most bit >> is always 0 (the -1 in the define for _PP_DMA_INDEX_BITS) in the patch, >> which puts it outside the range used for kernel pointers (AFAICT). > > Is there any season you think only kernel pointer is relevant here? Yes. Any pointer stored in the same space as pp_magic by other users of the page will be kernel pointers (as they come from page->lru.next). The goal of PP_SIGNATURE is to be able to distinguish pages allocated by page_pool, so we don't accidentally recycle a page from somewhere else. That's the goal of the check in page_pool_page_is_pp(): (page->pp_magic & PP_MAGIC_MASK) == PP_SIGNATURE To achieve this, we must ensure that the check above never returns true for any value another page user could have written into the same field (i.e., into page->lru.next). For 64-bit arches, POISON_POINTER_DELTA serves this purpose. For 32-bit arches, we can leave the top-most bits out of PP_MAGIC_MASK, to make sure that any valid pointer value will fail the check above. > It seems it is not really only about kernel pointers as round_hint_to_min() > in mm/mmap.c suggests and the commit log in the above commit 8a5e5e02fc83 > if I understand it correctly: > "Given unprivileged users cannot mmap anything below mmap_min_addr, it > should be safe to use poison pointers lower than mmap_min_addr." > > And the above "making sure the top-most bit is always 0" doesn't seems to > ensure page->signature to be outside the range used for kernel pointers > for 32-bit arches with VMSPLIT_1G defined, see arch/arm/Kconfig, there > is a similar config for x86 too: > prompt "Memory split" > depends on MMU > default VMSPLIT_3G > help > Select the desired split between kernel and user memory. > > If you are not absolutely sure what you are doing, leave this > option alone! > > config VMSPLIT_3G > bool "3G/1G user/kernel split" > config VMSPLIT_3G_OPT > depends on !ARM_LPAE > bool "3G/1G user/kernel split (for full 1G low memory)" > config VMSPLIT_2G > bool "2G/2G user/kernel split" > config VMSPLIT_1G > bool "1G/3G user/kernel split" Ah, interesting, didn't know this was configurable. Okay, so AFAICT, the lowest value of PAGE_OFFSET is 0x40000000 (for VMSPLIT_1G), so we need to leave two bits off at the top instead of just one. Will update this, and try to explain the logic better in the comment. > IMHO, even if some trick like above is really feasible, it may be > adding some limitation or complexity to the ARCH and MM subsystem, for > example, stashing the ID in page->signature may cause 0x*40 signature > to be unusable for other poison pointer purpose, it makes more sense to > make it obvious by doing the above trick in some MM header file like > poison.h instead of in the page_pool subsystem. AFAIU, PP_SIGNATURE is used for page_pool to be able to distinguish its own pages from those allocated elsewhere (cf the description above). Which means that these definitions are logically page_pool-internal, and thus it makes the most sense to keep them in the page pool headers. The only bits the mm subsystem cares about in that field are the bottom two (for pfmemalloc pages and compound pages). >>>> Since all the tracking is performed on DMA map/unmap, no additional code >>>> is needed in the fast path, meaning the performance overhead of this >>>> tracking is negligible. A micro-benchmark shows that the total overhead >>>> of using xarray for this purpose is about 400 ns (39 cycles(tsc) 395.218 >>>> ns; sum for both map and unmap[1]). Since this cost is only paid on DMA >>>> map and unmap, it seems like an acceptable cost to fix the late unmap >>> >>> For most use cases when PP_FLAG_DMA_MAP is set and IOMMU is off, the >>> DMA map and unmap operation is almost negligible as said below, so the >>> cost is about 200% performance degradation, which doesn't seems like an >>> acceptable cost. >> >> I disagree. This only impacts the slow path, as long as pages are >> recycled there is no additional cost. While your patch series has >> demonstrated that it is *possible* to reduce the cost even in the slow >> path, I don't think the complexity cost of this is worth it. > > It is still the datapath otherwise there isn't a specific testing > for that use case, more than 200% performance degradation is too much > IHMO. Do you have a real-world use case (i.e., a networking benchmark, not a micro-benchmark of the allocation function) where this change has a measurable impact on performance? If so, please do share the numbers! I very much doubt it will be anything close to that magnitude, but I'm always willing to be persuaded by data :) > Let aside the above severe performance degradation, reusing space in > page->signature seems to be a tradeoff between adding complexity in > page_pool subsystem and in VM/ARCH subsystem as mentioned above. I think you are overstating the impact on other MM users; this is all mostly page_pool-internal logic, cf the explanation above. >> >> [...] >> >>>> The extra memory needed to track the pages is neatly encapsulated inside >>>> xarray, which uses the 'struct xa_node' structure to track items. This >>>> structure is 576 bytes long, with slots for 64 items, meaning that a >>>> full node occurs only 9 bytes of overhead per slot it tracks (in >>>> practice, it probably won't be this efficient, but in any case it should >>> >>> Is there any debug infrastructure to know if it is not this efficient? >>> as there may be 576 byte overhead for a page for the worst case. >> >> There's an XA_DEBUG define which enables some dump functions, but I >> don't think there's any API to inspect the memory usage. I guess you >> could attach a BPF program and walk the structure, or something? >> > > It seems the XA_DEBUG is not defined in production environment. > And I am not familiar enough with BPF program to understand if the > BPF way is feasiable in production environment. > Any example for the above BPF program and how to attach it? Hmm, no, not really, sorry :( I *think* it should be possible to write a bpftrace script that walks the internal xarray tree and counts the nodes along the way, but it's not trivial to do, and I haven't tried. -Toke
On 2025/3/19 4:55, Toke Høiland-Jørgensen wrote: > Yunsheng Lin <linyunsheng@huawei.com> writes: > >> On 2025/3/17 23:16, Toke Høiland-Jørgensen wrote: >>> Yunsheng Lin <yunshenglin0825@gmail.com> writes: >>> >>>> On 3/14/2025 6:10 PM, Toke Høiland-Jørgensen wrote: >>>> >>>> ... >>>> >>>>> >>>>> To avoid having to walk the entire xarray on unmap to find the page >>>>> reference, we stash the ID assigned by xa_alloc() into the page >>>>> structure itself, using the upper bits of the pp_magic field. This >>>>> requires a couple of defines to avoid conflicting with the >>>>> POINTER_POISON_DELTA define, but this is all evaluated at compile-time, >>>>> so does not affect run-time performance. The bitmap calculations in this >>>>> patch gives the following number of bits for different architectures: >>>>> >>>>> - 24 bits on 32-bit architectures >>>>> - 21 bits on PPC64 (because of the definition of ILLEGAL_POINTER_VALUE) >>>>> - 32 bits on other 64-bit architectures >>>> >>>> From commit c07aea3ef4d4 ("mm: add a signature in struct page"): >>>> "The page->signature field is aliased to page->lru.next and >>>> page->compound_head, but it can't be set by mistake because the >>>> signature value is a bad pointer, and can't trigger a false positive >>>> in PageTail() because the last bit is 0." >>>> >>>> And commit 8a5e5e02fc83 ("include/linux/poison.h: fix LIST_POISON{1,2} >>>> offset"): >>>> "Poison pointer values should be small enough to find a room in >>>> non-mmap'able/hardly-mmap'able space." >>>> >>>> So the question seems to be: >>>> 1. Is stashing the ID causing page->pp_magic to be in the mmap'able/ >>>> easier-mmap'able space? If yes, how can we make sure this will not >>>> cause any security problem? >>>> 2. Is the masking the page->pp_magic causing a valid pionter for >>>> page->lru.next or page->compound_head to be treated as a vaild >>>> PP_SIGNATURE? which might cause page_pool to recycle a page not >>>> allocated via page_pool. >>> >>> Right, so my reasoning for why the defines in this patch works for this >>> is as follows: in both cases we need to make sure that the ID stashed in >>> that field never looks like a valid kernel pointer. For 64-bit arches >>> (where CONFIG_ILLEGAL_POINTER_VALUE), we make sure of this by never >>> writing to any bits that overlap with the illegal value (so that the >>> PP_SIGNATURE written to the field keeps it as an illegal pointer value). >>> For 32-bit arches, we make sure of this by making sure the top-most bit >>> is always 0 (the -1 in the define for _PP_DMA_INDEX_BITS) in the patch, >>> which puts it outside the range used for kernel pointers (AFAICT). >> >> Is there any season you think only kernel pointer is relevant here? > > Yes. Any pointer stored in the same space as pp_magic by other users of > the page will be kernel pointers (as they come from page->lru.next). The > goal of PP_SIGNATURE is to be able to distinguish pages allocated by > page_pool, so we don't accidentally recycle a page from somewhere else. > That's the goal of the check in page_pool_page_is_pp(): > > (page->pp_magic & PP_MAGIC_MASK) == PP_SIGNATURE > > To achieve this, we must ensure that the check above never returns true > for any value another page user could have written into the same field > (i.e., into page->lru.next). For 64-bit arches, POISON_POINTER_DELTA POISON_POINTER_DELTA is defined according to CONFIG_ILLEGAL_POINTER_VALUE, if CONFIG_ILLEGAL_POINTER_VALUE is not defined yet, POISON_POINTER_DELTA is defined to zero. It seems only the below 64-bit arches define CONFIG_ILLEGAL_POINTER_VALUE through grepping: a29815a333c6 core, x86: make LIST_POISON less deadly 5c178472af24 riscv: define ILLEGAL_POINTER_VALUE for 64bit f6853eb561fb powerpc/64: Define ILLEGAL_POINTER_VALUE for 64-bit bf0c4e047324 arm64: kconfig: Move LIST_POISON to a safe value The below 64-bit arches don't seems to define the above config yet: MIPS64, SPARC64, System z(S390X),loongarch Does ID stashing cause problem for the above arches? > serves this purpose. For 32-bit arches, we can leave the top-most bits > out of PP_MAGIC_MASK, to make sure that any valid pointer value will > fail the check above. The above mainly explained how to ensure page_pool_page_is_pp() will not return false positive result from the page_pool perspective. From MM/security perspective, most of the commits quoted above seem to suggest that poison pointer should be in the non-mmap'able or hardly-mmap'able space, otherwise userspace can arrange for those pointers to actually be dereferencable, potentially turning an oops to an expolit, more detailed example in the below paper, which explains how to exploit a vulnerability which hardened by the 8a5e5e02fc83 commit: https://www.usenix.org/system/files/conference/woot15/woot15-paper-xu.pdf ID stashing seems to cause page->lru.next (aliased to page->pp_magic) to be in the mmap'able space for some arches. > >> It seems it is not really only about kernel pointers as round_hint_to_min() >> in mm/mmap.c suggests and the commit log in the above commit 8a5e5e02fc83 >> if I understand it correctly: >> "Given unprivileged users cannot mmap anything below mmap_min_addr, it >> should be safe to use poison pointers lower than mmap_min_addr." >> >> And the above "making sure the top-most bit is always 0" doesn't seems to >> ensure page->signature to be outside the range used for kernel pointers >> for 32-bit arches with VMSPLIT_1G defined, see arch/arm/Kconfig, there >> is a similar config for x86 too: ... > > Ah, interesting, didn't know this was configurable. Okay, so AFAICT, the > lowest value of PAGE_OFFSET is 0x40000000 (for VMSPLIT_1G), so we need > to leave two bits off at the top instead of just one. Will update this, > and try to explain the logic better in the comment. It seems there was attempt of doing 4G/4G split too, and that is the kind of limitation or complexity added to the ARCH and MM subsystem by doing the ID stashing I mentioned earlier. https://lore.kernel.org/lkml/Pine.LNX.4.44.0307082332450.17252-100000@localhost.localdomain/ > >> IMHO, even if some trick like above is really feasible, it may be >> adding some limitation or complexity to the ARCH and MM subsystem, for >> example, stashing the ID in page->signature may cause 0x*40 signature >> to be unusable for other poison pointer purpose, it makes more sense to >> make it obvious by doing the above trick in some MM header file like >> poison.h instead of in the page_pool subsystem. > > AFAIU, PP_SIGNATURE is used for page_pool to be able to distinguish its > own pages from those allocated elsewhere (cf the description above). > Which means that these definitions are logically page_pool-internal, and > thus it makes the most sense to keep them in the page pool headers. The > only bits the mm subsystem cares about in that field are the bottom two > (for pfmemalloc pages and compound pages). All I asked is about moving PP_MAGIC_MASK macro into poison.h if you still want to proceed with reusing the page->pp_magic as the masking and the signature to be masked seems reasonable to be in the same file. > >>>>> Since all the tracking is performed on DMA map/unmap, no additional code >>>>> is needed in the fast path, meaning the performance overhead of this >>>>> tracking is negligible. A micro-benchmark shows that the total overhead >>>>> of using xarray for this purpose is about 400 ns (39 cycles(tsc) 395.218 >>>>> ns; sum for both map and unmap[1]). Since this cost is only paid on DMA >>>>> map and unmap, it seems like an acceptable cost to fix the late unmap >>>> >>>> For most use cases when PP_FLAG_DMA_MAP is set and IOMMU is off, the >>>> DMA map and unmap operation is almost negligible as said below, so the >>>> cost is about 200% performance degradation, which doesn't seems like an >>>> acceptable cost. >>> >>> I disagree. This only impacts the slow path, as long as pages are >>> recycled there is no additional cost. While your patch series has >>> demonstrated that it is *possible* to reduce the cost even in the slow >>> path, I don't think the complexity cost of this is worth it. >> >> It is still the datapath otherwise there isn't a specific testing >> for that use case, more than 200% performance degradation is too much >> IHMO. > > Do you have a real-world use case (i.e., a networking benchmark, not a > micro-benchmark of the allocation function) where this change has a > measurable impact on performance? If so, please do share the numbers! I don't have one yet. > > I very much doubt it will be anything close to that magnitude, but I'm > always willing to be persuaded by data :) > >> Let aside the above severe performance degradation, reusing space in >> page->signature seems to be a tradeoff between adding complexity in >> page_pool subsystem and in VM/ARCH subsystem as mentioned above. > > I think you are overstating the impact on other MM users; this is all > mostly page_pool-internal logic, cf the explanation above. To be honest, I am not that familiar with the pointer poison mechanism. But through some researching and analyzing, it makes sense to overstate it a little as it seems to be security-related. Cc'ed some security-related experts and ML to see if there is some clarifying from them. > >>> >>> [...] >>> >>>>> The extra memory needed to track the pages is neatly encapsulated inside >>>>> xarray, which uses the 'struct xa_node' structure to track items. This >>>>> structure is 576 bytes long, with slots for 64 items, meaning that a >>>>> full node occurs only 9 bytes of overhead per slot it tracks (in >>>>> practice, it probably won't be this efficient, but in any case it should >>>> >>>> Is there any debug infrastructure to know if it is not this efficient? >>>> as there may be 576 byte overhead for a page for the worst case. >>> >>> There's an XA_DEBUG define which enables some dump functions, but I >>> don't think there's any API to inspect the memory usage. I guess you >>> could attach a BPF program and walk the structure, or something? >>> >> >> It seems the XA_DEBUG is not defined in production environment. >> And I am not familiar enough with BPF program to understand if the >> BPF way is feasiable in production environment. >> Any example for the above BPF program and how to attach it? > > Hmm, no, not really, sorry :( > > I *think* it should be possible to write a bpftrace script that walks > the internal xarray tree and counts the nodes along the way, but it's > not trivial to do, and I haven't tried. > > -Toke > >
Yunsheng Lin <linyunsheng@huawei.com> writes: > On 2025/3/19 4:55, Toke Høiland-Jørgensen wrote: >> Yunsheng Lin <linyunsheng@huawei.com> writes: >> >>> On 2025/3/17 23:16, Toke Høiland-Jørgensen wrote: >>>> Yunsheng Lin <yunshenglin0825@gmail.com> writes: >>>> >>>>> On 3/14/2025 6:10 PM, Toke Høiland-Jørgensen wrote: >>>>> >>>>> ... >>>>> >>>>>> >>>>>> To avoid having to walk the entire xarray on unmap to find the page >>>>>> reference, we stash the ID assigned by xa_alloc() into the page >>>>>> structure itself, using the upper bits of the pp_magic field. This >>>>>> requires a couple of defines to avoid conflicting with the >>>>>> POINTER_POISON_DELTA define, but this is all evaluated at compile-time, >>>>>> so does not affect run-time performance. The bitmap calculations in this >>>>>> patch gives the following number of bits for different architectures: >>>>>> >>>>>> - 24 bits on 32-bit architectures >>>>>> - 21 bits on PPC64 (because of the definition of ILLEGAL_POINTER_VALUE) >>>>>> - 32 bits on other 64-bit architectures >>>>> >>>>> From commit c07aea3ef4d4 ("mm: add a signature in struct page"): >>>>> "The page->signature field is aliased to page->lru.next and >>>>> page->compound_head, but it can't be set by mistake because the >>>>> signature value is a bad pointer, and can't trigger a false positive >>>>> in PageTail() because the last bit is 0." >>>>> >>>>> And commit 8a5e5e02fc83 ("include/linux/poison.h: fix LIST_POISON{1,2} >>>>> offset"): >>>>> "Poison pointer values should be small enough to find a room in >>>>> non-mmap'able/hardly-mmap'able space." >>>>> >>>>> So the question seems to be: >>>>> 1. Is stashing the ID causing page->pp_magic to be in the mmap'able/ >>>>> easier-mmap'able space? If yes, how can we make sure this will not >>>>> cause any security problem? >>>>> 2. Is the masking the page->pp_magic causing a valid pionter for >>>>> page->lru.next or page->compound_head to be treated as a vaild >>>>> PP_SIGNATURE? which might cause page_pool to recycle a page not >>>>> allocated via page_pool. >>>> >>>> Right, so my reasoning for why the defines in this patch works for this >>>> is as follows: in both cases we need to make sure that the ID stashed in >>>> that field never looks like a valid kernel pointer. For 64-bit arches >>>> (where CONFIG_ILLEGAL_POINTER_VALUE), we make sure of this by never >>>> writing to any bits that overlap with the illegal value (so that the >>>> PP_SIGNATURE written to the field keeps it as an illegal pointer value). >>>> For 32-bit arches, we make sure of this by making sure the top-most bit >>>> is always 0 (the -1 in the define for _PP_DMA_INDEX_BITS) in the patch, >>>> which puts it outside the range used for kernel pointers (AFAICT). >>> >>> Is there any season you think only kernel pointer is relevant here? >> >> Yes. Any pointer stored in the same space as pp_magic by other users of >> the page will be kernel pointers (as they come from page->lru.next). The >> goal of PP_SIGNATURE is to be able to distinguish pages allocated by >> page_pool, so we don't accidentally recycle a page from somewhere else. >> That's the goal of the check in page_pool_page_is_pp(): >> >> (page->pp_magic & PP_MAGIC_MASK) == PP_SIGNATURE >> >> To achieve this, we must ensure that the check above never returns true >> for any value another page user could have written into the same field >> (i.e., into page->lru.next). For 64-bit arches, POISON_POINTER_DELTA > > POISON_POINTER_DELTA is defined according to CONFIG_ILLEGAL_POINTER_VALUE, > if CONFIG_ILLEGAL_POINTER_VALUE is not defined yet, POISON_POINTER_DELTA > is defined to zero. > > It seems only the below 64-bit arches define CONFIG_ILLEGAL_POINTER_VALUE > through grepping: > a29815a333c6 core, x86: make LIST_POISON less deadly > 5c178472af24 riscv: define ILLEGAL_POINTER_VALUE for 64bit > f6853eb561fb powerpc/64: Define ILLEGAL_POINTER_VALUE for 64-bit > bf0c4e047324 arm64: kconfig: Move LIST_POISON to a safe value > > The below 64-bit arches don't seems to define the above config yet: > MIPS64, SPARC64, System z(S390X),loongarch > > Does ID stashing cause problem for the above arches? Well, not from a "number of bits available" perspective. In that case we have plenty of bits, but we limit the size of the ID we stash to 32 bits in all cases, so we will just end up with the 21 leading bits being all-zero. So for those arches we basically end up in the same situation as on 32-bit (see below). >> serves this purpose. For 32-bit arches, we can leave the top-most bits >> out of PP_MAGIC_MASK, to make sure that any valid pointer value will >> fail the check above. > > The above mainly explained how to ensure page_pool_page_is_pp() will > not return false positive result from the page_pool perspective. > > From MM/security perspective, most of the commits quoted above seem > to suggest that poison pointer should be in the non-mmap'able or > hardly-mmap'able space, otherwise userspace can arrange for those > pointers to actually be dereferencable, potentially turning an oops > to an expolit, more detailed example in the below paper, which explains > how to exploit a vulnerability which hardened by the 8a5e5e02fc83 commit: > https://www.usenix.org/system/files/conference/woot15/woot15-paper-xu.pdf > > ID stashing seems to cause page->lru.next (aliased to page->pp_magic) to > be in the mmap'able space for some arches. Right, okay, I see what you mean. So the risk is basically the following: If some other part of the kernel ends up dereferencing the page->lru.next pointer of a page that is owned by page_pool, and which has an ID stashed into page->pp_magic, that dereference can end up being to a valid userspace mapping, which can lead to Bad Things(tm), cf the paper above. This is mitigated by the fact that it can only happen on architectures that don't set ILLEGAL_POINTER_VALUE (which includes 32-bit arches, and the ones you listed above). In addition, this has to happen while the page is owned by page_pool, and while it is DMA-mapped - we already clear the pp_magic field when releasing the page from page_pool. I am not sure to what extent the above is a risk we should take pains to avoid, TBH. It seems to me that for this to become a real problem, lots of other things will already have gone wrong. But happy to defer to the mm/security folks here. >>> It seems it is not really only about kernel pointers as round_hint_to_min() >>> in mm/mmap.c suggests and the commit log in the above commit 8a5e5e02fc83 >>> if I understand it correctly: >>> "Given unprivileged users cannot mmap anything below mmap_min_addr, it >>> should be safe to use poison pointers lower than mmap_min_addr." >>> >>> And the above "making sure the top-most bit is always 0" doesn't seems to >>> ensure page->signature to be outside the range used for kernel pointers >>> for 32-bit arches with VMSPLIT_1G defined, see arch/arm/Kconfig, there >>> is a similar config for x86 too: > > ... > >> >> Ah, interesting, didn't know this was configurable. Okay, so AFAICT, the >> lowest value of PAGE_OFFSET is 0x40000000 (for VMSPLIT_1G), so we need >> to leave two bits off at the top instead of just one. Will update this, >> and try to explain the logic better in the comment. > > It seems there was attempt of doing 4G/4G split too, and that is the kind > of limitation or complexity added to the ARCH and MM subsystem by doing the > ID stashing I mentioned earlier. > https://lore.kernel.org/lkml/Pine.LNX.4.44.0307082332450.17252-100000@localhost.localdomain/ Given that this is all temporary until the folio rework Matthew alluded to is completed, I think that particular concern is somewhat theoretical :) >>> IMHO, even if some trick like above is really feasible, it may be >>> adding some limitation or complexity to the ARCH and MM subsystem, for >>> example, stashing the ID in page->signature may cause 0x*40 signature >>> to be unusable for other poison pointer purpose, it makes more sense to >>> make it obvious by doing the above trick in some MM header file like >>> poison.h instead of in the page_pool subsystem. >> >> AFAIU, PP_SIGNATURE is used for page_pool to be able to distinguish its >> own pages from those allocated elsewhere (cf the description above). >> Which means that these definitions are logically page_pool-internal, and >> thus it makes the most sense to keep them in the page pool headers. The >> only bits the mm subsystem cares about in that field are the bottom two >> (for pfmemalloc pages and compound pages). > > All I asked is about moving PP_MAGIC_MASK macro into poison.h if you > still want to proceed with reusing the page->pp_magic as the masking and > the signature to be masked seems reasonable to be in the same file. Hmm, my thinking was that this would be a lot of irrelevant stuff to put into poison.h, but I suppose we could do so if the mm folks don't object :) -Toke
On Wed, Mar 19, 2025 at 07:06:57PM +0800, Yunsheng Lin wrote: > On 2025/3/19 4:55, Toke Høiland-Jørgensen wrote: > > Yunsheng Lin <linyunsheng@huawei.com> writes: > >> On 2025/3/17 23:16, Toke Høiland-Jørgensen wrote: > >>> Yunsheng Lin <yunshenglin0825@gmail.com> writes: > >>>> On 3/14/2025 6:10 PM, Toke Høiland-Jørgensen wrote: > >>>> > >>>> ... > >>>> > >>>>> To avoid having to walk the entire xarray on unmap to find the page > >>>>> reference, we stash the ID assigned by xa_alloc() into the page > >>>>> structure itself, using the upper bits of the pp_magic field. This > >>>>> requires a couple of defines to avoid conflicting with the > >>>>> POINTER_POISON_DELTA define, but this is all evaluated at compile-time, > >>>>> so does not affect run-time performance. The bitmap calculations in this > >>>>> patch gives the following number of bits for different architectures: > >>>>> > >>>>> - 24 bits on 32-bit architectures > >>>>> - 21 bits on PPC64 (because of the definition of ILLEGAL_POINTER_VALUE) > >>>>> - 32 bits on other 64-bit architectures > >>>> > >>>> From commit c07aea3ef4d4 ("mm: add a signature in struct page"): > >>>> "The page->signature field is aliased to page->lru.next and > >>>> page->compound_head, but it can't be set by mistake because the > >>>> signature value is a bad pointer, and can't trigger a false positive > >>>> in PageTail() because the last bit is 0." > >>>> > >>>> And commit 8a5e5e02fc83 ("include/linux/poison.h: fix LIST_POISON{1,2} > >>>> offset"): > >>>> "Poison pointer values should be small enough to find a room in > >>>> non-mmap'able/hardly-mmap'able space." > >>>> > >>>> So the question seems to be: > >>>> 1. Is stashing the ID causing page->pp_magic to be in the mmap'able/ > >>>> easier-mmap'able space? If yes, how can we make sure this will not > >>>> cause any security problem? > >>>> 2. Is the masking the page->pp_magic causing a valid pionter for > >>>> page->lru.next or page->compound_head to be treated as a vaild > >>>> PP_SIGNATURE? which might cause page_pool to recycle a page not > >>>> allocated via page_pool. > >>> > >>> Right, so my reasoning for why the defines in this patch works for this > >>> is as follows: in both cases we need to make sure that the ID stashed in > >>> that field never looks like a valid kernel pointer. For 64-bit arches > >>> (where CONFIG_ILLEGAL_POINTER_VALUE), we make sure of this by never > >>> writing to any bits that overlap with the illegal value (so that the > >>> PP_SIGNATURE written to the field keeps it as an illegal pointer value). > >>> For 32-bit arches, we make sure of this by making sure the top-most bit > >>> is always 0 (the -1 in the define for _PP_DMA_INDEX_BITS) in the patch, > >>> which puts it outside the range used for kernel pointers (AFAICT). > >> > >> Is there any season you think only kernel pointer is relevant here? > > > > Yes. Any pointer stored in the same space as pp_magic by other users of > > the page will be kernel pointers (as they come from page->lru.next). The > > goal of PP_SIGNATURE is to be able to distinguish pages allocated by > > page_pool, so we don't accidentally recycle a page from somewhere else. > > That's the goal of the check in page_pool_page_is_pp(): > > > > (page->pp_magic & PP_MAGIC_MASK) == PP_SIGNATURE > > > > To achieve this, we must ensure that the check above never returns true > > for any value another page user could have written into the same field > > (i.e., into page->lru.next). For 64-bit arches, POISON_POINTER_DELTA > > POISON_POINTER_DELTA is defined according to CONFIG_ILLEGAL_POINTER_VALUE, > if CONFIG_ILLEGAL_POINTER_VALUE is not defined yet, POISON_POINTER_DELTA > is defined to zero. > > It seems only the below 64-bit arches define CONFIG_ILLEGAL_POINTER_VALUE > through grepping: > a29815a333c6 core, x86: make LIST_POISON less deadly > 5c178472af24 riscv: define ILLEGAL_POINTER_VALUE for 64bit > f6853eb561fb powerpc/64: Define ILLEGAL_POINTER_VALUE for 64-bit > bf0c4e047324 arm64: kconfig: Move LIST_POISON to a safe value > > The below 64-bit arches don't seems to define the above config yet: > MIPS64, SPARC64, System z(S390X),loongarch > > Does ID stashing cause problem for the above arches? > > > serves this purpose. For 32-bit arches, we can leave the top-most bits > > out of PP_MAGIC_MASK, to make sure that any valid pointer value will > > fail the check above. > > The above mainly explained how to ensure page_pool_page_is_pp() will > not return false positive result from the page_pool perspective. > > From MM/security perspective, most of the commits quoted above seem > to suggest that poison pointer should be in the non-mmap'able or > hardly-mmap'able space, otherwise userspace can arrange for those > pointers to actually be dereferencable, potentially turning an oops > to an expolit, more detailed example in the below paper, which explains > how to exploit a vulnerability which hardened by the 8a5e5e02fc83 commit: > https://www.usenix.org/system/files/conference/woot15/woot15-paper-xu.pdf > > ID stashing seems to cause page->lru.next (aliased to page->pp_magic) to > be in the mmap'able space for some arches. ... > To be honest, I am not that familiar with the pointer poison mechanism. > But through some researching and analyzing, it makes sense to overstate > it a little as it seems to be security-related. > Cc'ed some security-related experts and ML to see if there is some > clarifying from them. You're correct that the pointer poison values should be in areas not mmap'able by userspace (at least with reasonable mmap_min_addr values). Looking at the union inside "struct page", I see pp_magic is aliased against multiple pointers in the union'ed anonymous structs. I'm not familiar with the uses of page->pp_magic and how likely or not we are to have a bug where its aliasing with pointers would be exposed as an attack vector, but this does look like a serious security concern. It looks like we would be seriously weakening the poisoning, except on archs where the new values with ID stashing are still not mmap'able. I just discussed the matter with my colleague at CIQ, Sultan Alsawaf, and he thinks the added risk is not that bad. He wrote: > Toke's response here is fair: > > > Right, okay, I see what you mean. So the risk is basically the > > following: > > > > If some other part of the kernel ends up dereferencing the > > page->lru.next pointer of a page that is owned by page_pool, and which > > has an ID stashed into page->pp_magic, that dereference can end up being > > to a valid userspace mapping, which can lead to Bad Things(tm), cf the > > paper above. > > > > This is mitigated by the fact that it can only happen on architectures > > that don't set ILLEGAL_POINTER_VALUE (which includes 32-bit arches, and > > the ones you listed above). In addition, this has to happen while the > > page is owned by page_pool, and while it is DMA-mapped - we already > > clear the pp_magic field when releasing the page from page_pool. > > > > I am not sure to what extent the above is a risk we should take pains to > > avoid, TBH. It seems to me that for this to become a real problem, lots > > of other things will already have gone wrong. But happy to defer to the > > mm/security folks here. > > For this to be a problem, there already needs to be a use-after-free on > a page, which arguably creates many other vectors for attack. > > The lru field of struct page is already used as a generic list pointer > in several places in the kernel once ownership of the page is obtained. > Any risk of dereferencing lru.next in a use-after-free scenario would > technically apply to a bunch of other places in the kernel (grep for > page->lru). We also tried searching for existing exploitation techniques for "struct page" use-after-free. We couldn't find any. The closest (non-)match I found is this fine research (the same project presented differently): https://i.blackhat.com/BH-US-24/Presentations/US24-Qian-PageJack-A-Powerful-Exploit-Technique-With-Page-Level-UAF-Thursday.pdf page 33+ https://arxiv.org/html/2401.17618v2#S4 https://phrack.org/issues/71/13 The arxiv paper includes this sentence: "To create a page-level UAF, the key is to cause a UAF of the struct page objects." However, we do not see them actually do that, and this statement is not found in the slides nor in the Phrack article. Confused. Thank you for CC'ing me and the kernel-hardening list. However, please do not CC the oss-security list like that, where it's against content guidelines. Only properly focused new postings/threads are acceptable there (not CC'ing from/to other lists where only part of the content is on-topic, and follow-ups might not be on-topic at all). See: https://oss-security.openwall.org/wiki/mailing-lists/oss-security#list-content-guidelines As a moderator for oss-security, I'm going to remove these messages from the queue now. Please drop Cc: oss-security from any further replies. If desired, we may bring these topics to oss-security separately, with a proper Subject line and clear description of what we're talking about. Alexander
On 2025/3/19 20:18, Toke Høiland-Jørgensen wrote: >> >> All I asked is about moving PP_MAGIC_MASK macro into poison.h if you >> still want to proceed with reusing the page->pp_magic as the masking and >> the signature to be masked seems reasonable to be in the same file. > > Hmm, my thinking was that this would be a lot of irrelevant stuff to put > into poison.h, but I suppose we could do so if the mm folks don't object :) The masking and the signature to be masked is correlated, I am not sure what you meant by 'irrelevant stuff' here. As you seemed to have understood most of my concern about reusing page->pp_magic, I am not going to argue with you about the uncertainty of security and complexity of different address layout for different arches again. But I am still think it is not the way forward with the reusing of page->pp_magic through doing some homework about the 'POISON_POINTER'. If you still think my idea is complex and still want to proceed with reusing the space of page->pp_magic, go ahead and let the maintainers decide if it is worth the security risk and performance degradation. > > -Toke > >
Yunsheng Lin <linyunsheng@huawei.com> writes: > On 2025/3/19 20:18, Toke Høiland-Jørgensen wrote: >>> >>> All I asked is about moving PP_MAGIC_MASK macro into poison.h if you >>> still want to proceed with reusing the page->pp_magic as the masking and >>> the signature to be masked seems reasonable to be in the same file. >> >> Hmm, my thinking was that this would be a lot of irrelevant stuff to put >> into poison.h, but I suppose we could do so if the mm folks don't object :) > > The masking and the signature to be masked is correlated, I am not sure > what you meant by 'irrelevant stuff' here. Well, looking at it again, mostly the XA_LIMIT define, I guess. But I can just leave that in the PP header. > As you seemed to have understood most of my concern about reusing > page->pp_magic, I am not going to argue with you about the uncertainty > of security and complexity of different address layout for different > arches again. > > But I am still think it is not the way forward with the reusing of > page->pp_magic through doing some homework about the 'POISON_POINTER'. > If you still think my idea is complex and still want to proceed with > reusing the space of page->pp_magic, go ahead and let the maintainers > decide if it is worth the security risk and performance degradation. Yeah, thanks for taking the time to go through the implications. On balance, I still believe reusing the bits is a better solution, but it will of course ultimately be up to the maintainers to decide. I will post a v2 of this series with the adjustments we've discussed, and try to outline the tradeoffs and risks involved in the description, and then leave it to the maintainers to decide which approach they want to move forward with. -Toke
Solar Designer <solar@openwall.com> writes: > On Wed, Mar 19, 2025 at 07:06:57PM +0800, Yunsheng Lin wrote: >> On 2025/3/19 4:55, Toke Høiland-Jørgensen wrote: >> > Yunsheng Lin <linyunsheng@huawei.com> writes: >> >> On 2025/3/17 23:16, Toke Høiland-Jørgensen wrote: >> >>> Yunsheng Lin <yunshenglin0825@gmail.com> writes: >> >>>> On 3/14/2025 6:10 PM, Toke Høiland-Jørgensen wrote: >> >>>> >> >>>> ... >> >>>> >> >>>>> To avoid having to walk the entire xarray on unmap to find the page >> >>>>> reference, we stash the ID assigned by xa_alloc() into the page >> >>>>> structure itself, using the upper bits of the pp_magic field. This >> >>>>> requires a couple of defines to avoid conflicting with the >> >>>>> POINTER_POISON_DELTA define, but this is all evaluated at compile-time, >> >>>>> so does not affect run-time performance. The bitmap calculations in this >> >>>>> patch gives the following number of bits for different architectures: >> >>>>> >> >>>>> - 24 bits on 32-bit architectures >> >>>>> - 21 bits on PPC64 (because of the definition of ILLEGAL_POINTER_VALUE) >> >>>>> - 32 bits on other 64-bit architectures >> >>>> >> >>>> From commit c07aea3ef4d4 ("mm: add a signature in struct page"): >> >>>> "The page->signature field is aliased to page->lru.next and >> >>>> page->compound_head, but it can't be set by mistake because the >> >>>> signature value is a bad pointer, and can't trigger a false positive >> >>>> in PageTail() because the last bit is 0." >> >>>> >> >>>> And commit 8a5e5e02fc83 ("include/linux/poison.h: fix LIST_POISON{1,2} >> >>>> offset"): >> >>>> "Poison pointer values should be small enough to find a room in >> >>>> non-mmap'able/hardly-mmap'able space." >> >>>> >> >>>> So the question seems to be: >> >>>> 1. Is stashing the ID causing page->pp_magic to be in the mmap'able/ >> >>>> easier-mmap'able space? If yes, how can we make sure this will not >> >>>> cause any security problem? >> >>>> 2. Is the masking the page->pp_magic causing a valid pionter for >> >>>> page->lru.next or page->compound_head to be treated as a vaild >> >>>> PP_SIGNATURE? which might cause page_pool to recycle a page not >> >>>> allocated via page_pool. >> >>> >> >>> Right, so my reasoning for why the defines in this patch works for this >> >>> is as follows: in both cases we need to make sure that the ID stashed in >> >>> that field never looks like a valid kernel pointer. For 64-bit arches >> >>> (where CONFIG_ILLEGAL_POINTER_VALUE), we make sure of this by never >> >>> writing to any bits that overlap with the illegal value (so that the >> >>> PP_SIGNATURE written to the field keeps it as an illegal pointer value). >> >>> For 32-bit arches, we make sure of this by making sure the top-most bit >> >>> is always 0 (the -1 in the define for _PP_DMA_INDEX_BITS) in the patch, >> >>> which puts it outside the range used for kernel pointers (AFAICT). >> >> >> >> Is there any season you think only kernel pointer is relevant here? >> > >> > Yes. Any pointer stored in the same space as pp_magic by other users of >> > the page will be kernel pointers (as they come from page->lru.next). The >> > goal of PP_SIGNATURE is to be able to distinguish pages allocated by >> > page_pool, so we don't accidentally recycle a page from somewhere else. >> > That's the goal of the check in page_pool_page_is_pp(): >> > >> > (page->pp_magic & PP_MAGIC_MASK) == PP_SIGNATURE >> > >> > To achieve this, we must ensure that the check above never returns true >> > for any value another page user could have written into the same field >> > (i.e., into page->lru.next). For 64-bit arches, POISON_POINTER_DELTA >> >> POISON_POINTER_DELTA is defined according to CONFIG_ILLEGAL_POINTER_VALUE, >> if CONFIG_ILLEGAL_POINTER_VALUE is not defined yet, POISON_POINTER_DELTA >> is defined to zero. >> >> It seems only the below 64-bit arches define CONFIG_ILLEGAL_POINTER_VALUE >> through grepping: >> a29815a333c6 core, x86: make LIST_POISON less deadly >> 5c178472af24 riscv: define ILLEGAL_POINTER_VALUE for 64bit >> f6853eb561fb powerpc/64: Define ILLEGAL_POINTER_VALUE for 64-bit >> bf0c4e047324 arm64: kconfig: Move LIST_POISON to a safe value >> >> The below 64-bit arches don't seems to define the above config yet: >> MIPS64, SPARC64, System z(S390X),loongarch >> >> Does ID stashing cause problem for the above arches? >> >> > serves this purpose. For 32-bit arches, we can leave the top-most bits >> > out of PP_MAGIC_MASK, to make sure that any valid pointer value will >> > fail the check above. >> >> The above mainly explained how to ensure page_pool_page_is_pp() will >> not return false positive result from the page_pool perspective. >> >> From MM/security perspective, most of the commits quoted above seem >> to suggest that poison pointer should be in the non-mmap'able or >> hardly-mmap'able space, otherwise userspace can arrange for those >> pointers to actually be dereferencable, potentially turning an oops >> to an expolit, more detailed example in the below paper, which explains >> how to exploit a vulnerability which hardened by the 8a5e5e02fc83 commit: >> https://www.usenix.org/system/files/conference/woot15/woot15-paper-xu.pdf >> >> ID stashing seems to cause page->lru.next (aliased to page->pp_magic) to >> be in the mmap'able space for some arches. > > ... > >> To be honest, I am not that familiar with the pointer poison mechanism. >> But through some researching and analyzing, it makes sense to overstate >> it a little as it seems to be security-related. >> Cc'ed some security-related experts and ML to see if there is some >> clarifying from them. > > You're correct that the pointer poison values should be in areas not > mmap'able by userspace (at least with reasonable mmap_min_addr values). > > Looking at the union inside "struct page", I see pp_magic is aliased > against multiple pointers in the union'ed anonymous structs. > > I'm not familiar with the uses of page->pp_magic and how likely or not > we are to have a bug where its aliasing with pointers would be exposed > as an attack vector, but this does look like a serious security concern. > It looks like we would be seriously weakening the poisoning, except on > archs where the new values with ID stashing are still not mmap'able. > > I just discussed the matter with my colleague at CIQ, Sultan Alsawaf, > and he thinks the added risk is not that bad. He wrote: > >> Toke's response here is fair: >> >> > Right, okay, I see what you mean. So the risk is basically the >> > following: >> > >> > If some other part of the kernel ends up dereferencing the >> > page->lru.next pointer of a page that is owned by page_pool, and which >> > has an ID stashed into page->pp_magic, that dereference can end up being >> > to a valid userspace mapping, which can lead to Bad Things(tm), cf the >> > paper above. >> > >> > This is mitigated by the fact that it can only happen on architectures >> > that don't set ILLEGAL_POINTER_VALUE (which includes 32-bit arches, and >> > the ones you listed above). In addition, this has to happen while the >> > page is owned by page_pool, and while it is DMA-mapped - we already >> > clear the pp_magic field when releasing the page from page_pool. >> > >> > I am not sure to what extent the above is a risk we should take pains to >> > avoid, TBH. It seems to me that for this to become a real problem, lots >> > of other things will already have gone wrong. But happy to defer to the >> > mm/security folks here. >> >> For this to be a problem, there already needs to be a use-after-free on >> a page, which arguably creates many other vectors for attack. >> >> The lru field of struct page is already used as a generic list pointer >> in several places in the kernel once ownership of the page is obtained. >> Any risk of dereferencing lru.next in a use-after-free scenario would >> technically apply to a bunch of other places in the kernel (grep for >> page->lru). > > We also tried searching for existing exploitation techniques for "struct > page" use-after-free. We couldn't find any. The closest (non-)match I > found is this fine research (the same project presented differently): > > https://i.blackhat.com/BH-US-24/Presentations/US24-Qian-PageJack-A-Powerful-Exploit-Technique-With-Page-Level-UAF-Thursday.pdf page 33+ > https://arxiv.org/html/2401.17618v2#S4 > https://phrack.org/issues/71/13 > > The arxiv paper includes this sentence: "To create a page-level UAF, the > key is to cause a UAF of the struct page objects." However, we do not > see them actually do that, and this statement is not found in the slides > nor in the Phrack article. Confused. Thank you for weighing in! I will post an updated version of this patch with a reference to this discussion and try to summarise the above. > Thank you for CC'ing me and the kernel-hardening list. However, please > do not CC the oss-security list like that, where it's against content > guidelines. Only properly focused new postings/threads are acceptable > there (not CC'ing from/to other lists where only part of the content is > on-topic, and follow-ups might not be on-topic at all). See: > > https://oss-security.openwall.org/wiki/mailing-lists/oss-security#list-content-guidelines > > As a moderator for oss-security, I'm going to remove these messages from > the queue now. Please drop Cc: oss-security from any further replies. > > If desired, we may bring these topics to oss-security separately, with a > proper Subject line and clear description of what we're talking about. Noted, thanks! -Toke
diff --git a/include/net/page_pool/types.h b/include/net/page_pool/types.h index fbe34024b20061e8bcd1d4474f6ebfc70992f1eb..1e187489d392757c8dd2960870b0d875c1dde01b 100644 --- a/include/net/page_pool/types.h +++ b/include/net/page_pool/types.h @@ -6,6 +6,7 @@ #include <linux/dma-direction.h> #include <linux/ptr_ring.h> #include <linux/types.h> +#include <linux/xarray.h> #include <net/netmem.h> #define PP_FLAG_DMA_MAP BIT(0) /* Should page_pool do the DMA @@ -58,13 +59,38 @@ struct pp_alloc_cache { netmem_ref cache[PP_ALLOC_CACHE_SIZE]; }; +/* + * DMA mapping IDs + * + * When DMA-mapping a page, we allocate an ID (from an xarray) and stash this in + * the upper bits of page->pp_magic. The number of bits available here is + * constrained by the size of an unsigned long, and the definition of + * PP_SIGNATURE. + */ +#define PP_DMA_INDEX_SHIFT (1 + __fls(PP_SIGNATURE - POISON_POINTER_DELTA)) +#define _PP_DMA_INDEX_BITS MIN(32, BITS_PER_LONG - PP_DMA_INDEX_SHIFT - 1) + +/* PP_SIGNATURE includes POISON_POINTER_DELTA, so limit the size of the DMA + * index to not overlap with that if set + */ +#if POISON_POINTER_DELTA > 0 +#define PP_DMA_INDEX_BITS MIN(_PP_DMA_INDEX_BITS, \ + __ffs(POISON_POINTER_DELTA) - PP_DMA_INDEX_SHIFT) +#else +#define PP_DMA_INDEX_BITS _PP_DMA_INDEX_BITS +#endif + +#define PP_DMA_INDEX_MASK GENMASK(PP_DMA_INDEX_BITS + PP_DMA_INDEX_SHIFT - 1, \ + PP_DMA_INDEX_SHIFT) +#define PP_DMA_INDEX_LIMIT XA_LIMIT(1, BIT(PP_DMA_INDEX_BITS) - 1) + /* Mask used for checking in page_pool_page_is_pp() below. page->pp_magic is * OR'ed with PP_SIGNATURE after the allocation in order to preserve bit 0 for - * the head page of compound page and bit 1 for pfmemalloc page. - * page_is_pfmemalloc() is checked in __page_pool_put_page() to avoid recycling - * the pfmemalloc page. + * the head page of compound page and bit 1 for pfmemalloc page, as well as the + * bits used for the DMA index. page_is_pfmemalloc() is checked in + * __page_pool_put_page() to avoid recycling the pfmemalloc page. */ -#define PP_MAGIC_MASK ~0x3UL +#define PP_MAGIC_MASK ~(PP_DMA_INDEX_MASK | 0x3UL) /** * struct page_pool_params - page pool parameters @@ -233,6 +259,8 @@ struct page_pool { void *mp_priv; const struct memory_provider_ops *mp_ops; + struct xarray dma_mapped; + #ifdef CONFIG_PAGE_POOL_STATS /* recycle stats are per-cpu to avoid locking */ struct page_pool_recycle_stats __percpu *recycle_stats; diff --git a/net/core/netmem_priv.h b/net/core/netmem_priv.h index f33162fd281c23e109273ba09950c5d0a2829bc9..cd95394399b40c3604934ba7898eeeeacb8aee99 100644 --- a/net/core/netmem_priv.h +++ b/net/core/netmem_priv.h @@ -5,7 +5,7 @@ static inline unsigned long netmem_get_pp_magic(netmem_ref netmem) { - return __netmem_clear_lsb(netmem)->pp_magic; + return __netmem_clear_lsb(netmem)->pp_magic & ~PP_DMA_INDEX_MASK; } static inline void netmem_or_pp_magic(netmem_ref netmem, unsigned long pp_magic) @@ -15,6 +15,8 @@ static inline void netmem_or_pp_magic(netmem_ref netmem, unsigned long pp_magic) static inline void netmem_clear_pp_magic(netmem_ref netmem) { + WARN_ON_ONCE(__netmem_clear_lsb(netmem)->pp_magic & PP_DMA_INDEX_MASK); + __netmem_clear_lsb(netmem)->pp_magic = 0; } @@ -33,4 +35,28 @@ static inline void netmem_set_dma_addr(netmem_ref netmem, { __netmem_clear_lsb(netmem)->dma_addr = dma_addr; } + +static inline unsigned long netmem_get_dma_index(netmem_ref netmem) +{ + unsigned long magic; + + if (WARN_ON_ONCE(netmem_is_net_iov(netmem))) + return 0; + + magic = __netmem_clear_lsb(netmem)->pp_magic; + + return (magic & PP_DMA_INDEX_MASK) >> PP_DMA_INDEX_SHIFT; +} + +static inline void netmem_set_dma_index(netmem_ref netmem, + unsigned long id) +{ + unsigned long magic; + + if (WARN_ON_ONCE(netmem_is_net_iov(netmem))) + return; + + magic = netmem_get_pp_magic(netmem) | (id << PP_DMA_INDEX_SHIFT); + __netmem_clear_lsb(netmem)->pp_magic = magic; +} #endif diff --git a/net/core/page_pool.c b/net/core/page_pool.c index d51ca4389dd62d8bc266a9a2b792838257173535..5612d72d483cad8c24d2f703bb48aad185cfe59a 100644 --- a/net/core/page_pool.c +++ b/net/core/page_pool.c @@ -226,6 +226,8 @@ static int page_pool_init(struct page_pool *pool, return -EINVAL; pool->dma_map = true; + + xa_init_flags(&pool->dma_mapped, XA_FLAGS_ALLOC1); } if (pool->slow.flags & PP_FLAG_DMA_SYNC_DEV) { @@ -275,9 +277,6 @@ static int page_pool_init(struct page_pool *pool, /* Driver calling page_pool_create() also call page_pool_destroy() */ refcount_set(&pool->user_cnt, 1); - if (pool->dma_map) - get_device(pool->p.dev); - if (pool->slow.flags & PP_FLAG_ALLOW_UNREADABLE_NETMEM) { /* We rely on rtnl_lock()ing to make sure netdev_rx_queue * configuration doesn't change while we're initializing @@ -325,7 +324,7 @@ static void page_pool_uninit(struct page_pool *pool) ptr_ring_cleanup(&pool->ring, NULL); if (pool->dma_map) - put_device(pool->p.dev); + xa_destroy(&pool->dma_mapped); #ifdef CONFIG_PAGE_POOL_STATS if (!pool->system) @@ -471,9 +470,11 @@ page_pool_dma_sync_for_device(const struct page_pool *pool, __page_pool_dma_sync_for_device(pool, netmem, dma_sync_size); } -static bool page_pool_dma_map(struct page_pool *pool, netmem_ref netmem) +static bool page_pool_dma_map(struct page_pool *pool, netmem_ref netmem, gfp_t gfp) { dma_addr_t dma; + int err; + u32 id; /* Setup DMA mapping: use 'struct page' area for storing DMA-addr * since dma_addr_t can be either 32 or 64 bits and does not always fit @@ -487,15 +488,28 @@ static bool page_pool_dma_map(struct page_pool *pool, netmem_ref netmem) if (dma_mapping_error(pool->p.dev, dma)) return false; - if (page_pool_set_dma_addr_netmem(netmem, dma)) + if (in_softirq()) + err = xa_alloc(&pool->dma_mapped, &id, netmem_to_page(netmem), + PP_DMA_INDEX_LIMIT, gfp); + else + err = xa_alloc_bh(&pool->dma_mapped, &id, netmem_to_page(netmem), + PP_DMA_INDEX_LIMIT, gfp); + if (err) { + WARN_ONCE(1, "couldn't track DMA mapping, please report to netdev@"); goto unmap_failed; + } + if (page_pool_set_dma_addr_netmem(netmem, dma)) { + WARN_ONCE(1, "unexpected DMA address, please report to netdev@"); + goto unmap_failed; + } + + netmem_set_dma_index(netmem, id); page_pool_dma_sync_for_device(pool, netmem, pool->p.max_len); return true; unmap_failed: - WARN_ONCE(1, "unexpected DMA address, please report to netdev@"); dma_unmap_page_attrs(pool->p.dev, dma, PAGE_SIZE << pool->p.order, pool->p.dma_dir, DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_WEAK_ORDERING); @@ -512,7 +526,7 @@ static struct page *__page_pool_alloc_page_order(struct page_pool *pool, if (unlikely(!page)) return NULL; - if (pool->dma_map && unlikely(!page_pool_dma_map(pool, page_to_netmem(page)))) { + if (pool->dma_map && unlikely(!page_pool_dma_map(pool, page_to_netmem(page), gfp))) { put_page(page); return NULL; } @@ -558,7 +572,7 @@ static noinline netmem_ref __page_pool_alloc_pages_slow(struct page_pool *pool, */ for (i = 0; i < nr_pages; i++) { netmem = pool->alloc.cache[i]; - if (dma_map && unlikely(!page_pool_dma_map(pool, netmem))) { + if (dma_map && unlikely(!page_pool_dma_map(pool, netmem, gfp))) { put_page(netmem_to_page(netmem)); continue; } @@ -660,6 +674,8 @@ void page_pool_clear_pp_info(netmem_ref netmem) static __always_inline void __page_pool_release_page_dma(struct page_pool *pool, netmem_ref netmem) { + struct page *old, *page = netmem_to_page(netmem); + unsigned long id; dma_addr_t dma; if (!pool->dma_map) @@ -668,6 +684,17 @@ static __always_inline void __page_pool_release_page_dma(struct page_pool *pool, */ return; + id = netmem_get_dma_index(netmem); + if (!id) + return; + + if (in_softirq()) + old = xa_cmpxchg(&pool->dma_mapped, id, page, NULL, 0); + else + old = xa_cmpxchg_bh(&pool->dma_mapped, id, page, NULL, 0); + if (old != page) + return; + dma = page_pool_get_dma_addr_netmem(netmem); /* When page is unmapped, it cannot be returned to our pool */ @@ -675,6 +702,7 @@ static __always_inline void __page_pool_release_page_dma(struct page_pool *pool, PAGE_SIZE << pool->p.order, pool->p.dma_dir, DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_WEAK_ORDERING); page_pool_set_dma_addr_netmem(netmem, 0); + netmem_set_dma_index(netmem, 0); } /* Disconnects a page (from a page_pool). API users can have a need @@ -1084,8 +1112,32 @@ static void page_pool_empty_alloc_cache_once(struct page_pool *pool) static void page_pool_scrub(struct page_pool *pool) { + unsigned long id; + void *ptr; + page_pool_empty_alloc_cache_once(pool); - pool->destroy_cnt++; + if (!pool->destroy_cnt++ && pool->dma_map) { + if (pool->dma_sync) { + /* paired with READ_ONCE in + * page_pool_dma_sync_for_device() and + * __page_pool_dma_sync_for_cpu() + */ + WRITE_ONCE(pool->dma_sync, false); + + /* Make sure all concurrent returns that may see the old + * value of dma_sync (and thus perform a sync) have + * finished before doing the unmapping below. Skip the + * wait if the device doesn't actually need syncing, or + * if there are no outstanding mapped pages. + */ + if (dma_dev_need_sync(pool->p.dev) && + !xa_empty(&pool->dma_mapped)) + synchronize_net(); + } + + xa_for_each(&pool->dma_mapped, id, ptr) + __page_pool_release_page_dma(pool, page_to_netmem(ptr)); + } /* No more consumers should exist, but producers could still * be in-flight.
When enabling DMA mapping in page_pool, pages are kept DMA mapped until they are released from the pool, to avoid the overhead of re-mapping the pages every time they are used. This causes resource leaks and/or crashes when there are pages still outstanding while the device is torn down, because page_pool will attempt an unmap through a non-existent DMA device on the subsequent page return. To fix this, implement a simple tracking of outstanding DMA-mapped pages in page pool using an xarray. This was first suggested by Mina[0], and turns out to be fairly straight forward: We simply store pointers to pages directly in the xarray with xa_alloc() when they are first DMA mapped, and remove them from the array on unmap. Then, when a page pool is torn down, it can simply walk the xarray and unmap all pages still present there before returning, which also allows us to get rid of the get/put_device() calls in page_pool. Using xa_cmpxchg(), no additional synchronisation is needed, as a page will only ever be unmapped once. To avoid having to walk the entire xarray on unmap to find the page reference, we stash the ID assigned by xa_alloc() into the page structure itself, using the upper bits of the pp_magic field. This requires a couple of defines to avoid conflicting with the POINTER_POISON_DELTA define, but this is all evaluated at compile-time, so does not affect run-time performance. The bitmap calculations in this patch gives the following number of bits for different architectures: - 24 bits on 32-bit architectures - 21 bits on PPC64 (because of the definition of ILLEGAL_POINTER_VALUE) - 32 bits on other 64-bit architectures Since all the tracking is performed on DMA map/unmap, no additional code is needed in the fast path, meaning the performance overhead of this tracking is negligible. A micro-benchmark shows that the total overhead of using xarray for this purpose is about 400 ns (39 cycles(tsc) 395.218 ns; sum for both map and unmap[1]). Since this cost is only paid on DMA map and unmap, it seems like an acceptable cost to fix the late unmap issue. Further optimisation can narrow the cases where this cost is paid (for instance by eliding the tracking when DMA map/unmap is a no-op). The extra memory needed to track the pages is neatly encapsulated inside xarray, which uses the 'struct xa_node' structure to track items. This structure is 576 bytes long, with slots for 64 items, meaning that a full node occurs only 9 bytes of overhead per slot it tracks (in practice, it probably won't be this efficient, but in any case it should be an acceptable overhead). [0] https://lore.kernel.org/all/CAHS8izPg7B5DwKfSuzz-iOop_YRbk3Sd6Y4rX7KBG9DcVJcyWg@mail.gmail.com/ [1] https://lore.kernel.org/r/ae07144c-9295-4c9d-a400-153bb689fe9e@huawei.com Reported-by: Yonglong Liu <liuyonglong@huawei.com> Closes: https://lore.kernel.org/r/8743264a-9700-4227-a556-5f931c720211@huawei.com Fixes: ff7d6b27f894 ("page_pool: refurbish version of page_pool code") Suggested-by: Mina Almasry <almasrymina@google.com> Reviewed-by: Mina Almasry <almasrymina@google.com> Reviewed-by: Jesper Dangaard Brouer <hawk@kernel.org> Tested-by: Jesper Dangaard Brouer <hawk@kernel.org> Tested-by: Qiuling Ren <qren@redhat.com> Tested-by: Yuying Ma <yuma@redhat.com> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> --- include/net/page_pool/types.h | 36 +++++++++++++++++++--- net/core/netmem_priv.h | 28 ++++++++++++++++- net/core/page_pool.c | 72 +++++++++++++++++++++++++++++++++++++------ 3 files changed, 121 insertions(+), 15 deletions(-)