The original backport didn't move the code to link the vma into the MT and also the code to increment the map_count causing ~15 xfstests (including ext4/303 generic/051 generic/054 generic/069) to hard fail on some platforms. This patch resolves test failures.
Fixes: cec11fa2eb51 ("fork: defer linking file vma until vma is fully initialized") Signed-off-by: Leah Rumancik leah.rumancik@gmail.com --- kernel/fork.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c index 2eab916b504b..3bf0203c2195 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -733,6 +733,12 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, if (is_vm_hugetlb_page(tmp)) hugetlb_dup_vma_private(tmp);
+ /* Link the vma into the MT */ + if (vma_iter_bulk_store(&vmi, tmp)) + goto fail_nomem_vmi_store; + + mm->map_count++; + if (tmp->vm_ops && tmp->vm_ops->open) tmp->vm_ops->open(tmp);
@@ -752,11 +758,6 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, i_mmap_unlock_write(mapping); }
- /* Link the vma into the MT */ - if (vma_iter_bulk_store(&vmi, tmp)) - goto fail_nomem_vmi_store; - - mm->map_count++; if (!(tmp->vm_flags & VM_WIPEONFORK)) retval = copy_page_range(tmp, mpnt);
Same for this one, incomplete so please hold off on this patch for now.
On Mon, Jun 3, 2024 at 4:25 PM Leah Rumancik leah.rumancik@gmail.com wrote:
The original backport didn't move the code to link the vma into the MT and also the code to increment the map_count causing ~15 xfstests (including ext4/303 generic/051 generic/054 generic/069) to hard fail on some platforms. This patch resolves test failures.
Fixes: cec11fa2eb51 ("fork: defer linking file vma until vma is fully initialized") Signed-off-by: Leah Rumancik leah.rumancik@gmail.com
kernel/fork.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c index 2eab916b504b..3bf0203c2195 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -733,6 +733,12 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, if (is_vm_hugetlb_page(tmp)) hugetlb_dup_vma_private(tmp);
/* Link the vma into the MT */if (vma_iter_bulk_store(&vmi, tmp))goto fail_nomem_vmi_store;mm->map_count++;if (tmp->vm_ops && tmp->vm_ops->open) tmp->vm_ops->open(tmp);@@ -752,11 +758,6 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, i_mmap_unlock_write(mapping); }
/* Link the vma into the MT */if (vma_iter_bulk_store(&vmi, tmp))goto fail_nomem_vmi_store;mm->map_count++; if (!(tmp->vm_flags & VM_WIPEONFORK)) retval = copy_page_range(tmp, mpnt);-- 2.45.1.288.g0e0cd299f1-goog
Is it worth reverting the original bad backport for now, given it causes xfstests failures?
Greg KH gregkh@linuxfoundation.org writes:
On Fri, Jun 14, 2024 at 05:55:46AM +0100, Sam James wrote:
Is it worth reverting the original bad backport for now, given it causes xfstests failures?
Sounds like a good idea to me, anyone want to submit the revert so we can queue it up?
Thanks for the nudge, I wasn't planning on but why not?
6.1: https://lore.kernel.org/stable/20240614084038.3133260-1-sam@gentoo.org/T/#u 6.6: https://lore.kernel.org/stable/20240614085102.3198934-1-sam@gentoo.org/T/#u
Hope I've done it right. Cheers.
thanks,
greg k-h
thanks, sam
On Fri, Jun 14, 2024 at 09:52:21AM +0100, Sam James wrote:
Greg KH gregkh@linuxfoundation.org writes:
On Fri, Jun 14, 2024 at 05:55:46AM +0100, Sam James wrote:
Is it worth reverting the original bad backport for now, given it causes xfstests failures?
Sounds like a good idea to me, anyone want to submit the revert so we can queue it up?
Thanks for the nudge, I wasn't planning on but why not?
6.1: https://lore.kernel.org/stable/20240614084038.3133260-1-sam@gentoo.org/T/#u 6.6: https://lore.kernel.org/stable/20240614085102.3198934-1-sam@gentoo.org/T/#u
Hope I've done it right. Cheers.
Looks good, I'll queue them up for the next round of releases after this one is out, unless someone fixes this up before then.
thanks,
greg k-h
Hello!
After some more investigating, it seems while the original patch fixes a race with hugetlbfs, it creates an issue for vfio which results in a WARN which will fail xfstests when they _check_dmesg. I have been able to resolve this on our kernel. Today I'll check which upstream kernels it is applicable to and send out fixes where needed.
- Leah
On Fri, Jun 14, 2024 at 2:08 AM Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Jun 14, 2024 at 09:52:21AM +0100, Sam James wrote:
Greg KH gregkh@linuxfoundation.org writes:
On Fri, Jun 14, 2024 at 05:55:46AM +0100, Sam James wrote:
Is it worth reverting the original bad backport for now, given it causes xfstests failures?
Sounds like a good idea to me, anyone want to submit the revert so we can queue it up?
Thanks for the nudge, I wasn't planning on but why not?
6.1: https://lore.kernel.org/stable/20240614084038.3133260-1-sam@gentoo.org/T/#u 6.6: https://lore.kernel.org/stable/20240614085102.3198934-1-sam@gentoo.org/T/#u
Hope I've done it right. Cheers.
Looks good, I'll queue them up for the next round of releases after this one is out, unless someone fixes this up before then.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Leah Rumancik -
Sam James