great catch! nobody could notice it in practice but it's definitely
needed, especially after long uptimes it could be noticeable ;), thanks!
I'm attaching for review what I'm applying to my -aa tree, to fix the
above and the other issue with the non-ram vma merging fixed in 2.5.
Please review, thanks again!
--- CGL/include/linux/mm.h.~1~ 2003-05-07 23:39:00.000000000 +0200
+++ CGL/include/linux/mm.h 2003-05-10 18:25:04.000000000 +0200
@@ -587,11 +587,15 @@ static inline void __vma_unlink(struct m
mm->mmap_cache = prev;
}
+#define VM_SPECIAL (VM_IO | VM_DONTCOPY | VM_DONTEXPAND | VM_RESERVED)
+
#define can_vma_merge(vma, vm_flags) __can_vma_merge(vma, vm_flags, NULL, 0, 0)
static inline int __can_vma_merge(struct vm_area_struct * vma, unsigned long vm_flags,
struct file * file, unsigned long vm_pgoff, unsigned long offset)
{
- if (vma->vm_file == file && vma->vm_flags == vm_flags) {
+ if (vma->vm_file == file && vma->vm_flags == vm_flags &&
+ likely((!vma->vm_ops || !vma->vm_ops->close) && !vma->vm_private_data &&
+ !(vm_flags & VM_SPECIAL))) {
if (file) {
if (vma->vm_pgoff == vm_pgoff + offset) {
if ((long) offset > 0 && vm_pgoff + offset < vm_pgoff)
--- CGL/mm/mmap.c.~1~ 2003-05-07 23:39:42.000000000 +0200
+++ CGL/mm/mmap.c 2003-05-10 18:25:23.000000000 +0200
@@ -377,6 +377,8 @@ static int vma_merge(struct mm_struct *
spin_unlock(lock);
if (need_unlock)
unlock_vma_mappings(next);
+ if (file)
+ fput(file);
mm->map_count--;
kmem_cache_free(vm_area_cachep, next);
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/