fork() Causes DMA Buffer in Physical Memory to Retain Stale Data on Subsequent Writes

I'm working on a C++ application on Ubuntu 20.04 that uses PCIe DMA to transfer data from a user-space buffer to hardware. The buffer is mapped to a fixed 1K physical memory region via a custom library (plib->copyDataToBuffer). After calling fork() and running a child process (which just calls an external program and exits), I notice that subsequent writes to the buffer by the parent process do not reflect in physical memory—the kernel still sees the old data from before the fork. **Key Details:** The 1K buffer is mapped specifically for DMA; it’s pinned and mapped to a known physical address. Before the fork(), a call to plib->copyDataToBuffer correctly updates physical memory. After the fork(), the parent process calls plib->copyDataToBuffer again with new data, and msync returns success, but the physical memory contents remain unchanged. The child process does not touch the buffer; it only runs an unrelated command via execvp. **My Assumptions & Concerns:** fork() causes COW (Copy-on-Write), but since only the parent writes to the buffer, I expected the updated contents to reflect in physical memory. Could the COW behavior or memory remapping post-fork be interfering with DMA-mapped memory regions? I confirmed that plib->copyDataToBuffer performs the write correctly from a software perspective, but the actual physical memory contents (verified from kernel space) remain stale. **Question:** Why does the physical memory backing my DMA buffer retain stale data after a fork() + exec in a child process, even though the parent writes new data afterward? What are the best practices to ensure consistent physical memory updates for DMA buffers across fork() calls?