On 6/6/25 14:55, Jann Horn wrote:
On Thu, Jun 5, 2025 at 9:33 AM Vlastimil Babka vbabka@suse.cz wrote:
- Before mmap_write_unlock(), a TLB flush ensures that parent threads can't
- write to copy-on-write pages anymore.
- Before dup_mmap() copies page contents (which happens rarely), the
- parent's PTE for the page is made read-only and a TLB flush is issued, so
- subsequent writes are delayed until mmap_write_unlock().
But I guess this way makes it hard to review patch 1/2 individually. Should I just squash the two patches together, and then write in the commit message "see the comment blocks I'm adding for the fix
That would be good unless it makes it increases the conflicts in stable backports.
approach"? Or is there value in repeating the explanation in the commit message?
Depending on the above, if the stable fix needs to stay minimal, it would be valuable to make it more self-contained by repeating that in the commit message. So that the LLM has an easier job marking it as a CVE. </sarcasm>
Vlastimil
Fixes: 70e806e4e645 ("mm: Do early cow for pinned pages during fork() for ptes") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn jannh@google.com
Given how the fix seems to be localized to the already rare slowpath and doesn't require us to pessimize every trivial fork(), it seems reasonable to me even if don't have a concrete example of a sane code in the wild that's broken by the current behavior, so:
Acked-by: Vlastimil Babka vbabka@suse.cz
Thanks!