Re: [PATCH] Fix OOPS in mmap_region() when merging adjacent VM_LOCKED file segments

KOSAKI Motohiro
2009-02-02T11:59:36Z

Hi

I went to trip for last three days and I returned today.
I suprised this loooong thread now :)

I have one comment.

> TOTALLY UNTESTED. As usual. But the concept is pretty simple, and it
> actually removes a fair chunk of hacky code. The only reason the diffstat
> output says that it adds more lines than it deletes is that I added more
> comments and made that helper inline function rather than make a complex
> conditional.
>
> Whaddaya think?
>
> Linus
>
> ---
> mm/mmap.c | 48 +++++++++++++++++++++++++-----------------------
> mm/shmem.c | 2 +-
> 2 files changed, 26 insertions(+), 24 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index c581df1..5fcaec3 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1090,6 +1090,15 @@ int vma_wants_writenotify(struct vm_area_struct *vma)
> mapping_cap_account_dirty(vma->vm_file->f_mapping);
> }
>
> +/*
> + * We account for memory if it's a private writeable mapping,
> + * and VM_NORESERVE wasn't set.
> + */
> +static inline int private_accountable_mapping(unsigned int vm_flags)
> +{
> + return (vm_flags & (VM_NORESERVE | VM_SHARED | VM_WRITE)) == VM_WRITE;
> +}
> +
> unsigned long mmap_region(struct file *file, unsigned long addr,
> unsigned long len, unsigned long flags,
> unsigned int vm_flags, unsigned long pgoff,
> @@ -1117,23 +1126,24 @@ munmap_back:
> if (!may_expand_vm(mm, len >> PAGE_SHIFT))
> return -ENOMEM;
>
> - if (flags & MAP_NORESERVE)
> + /*
> + * Set 'VM_NORESERVE' if we should not account for the
> + * memory use of this mapping. We only honor MAP_NORESERVE
> + * if we're allowed to overcommit memory.
> + */
> + if ((flags & MAP_NORESERVE) && sysctl_overcommit_memory != OVERCOMMIT_NEVER)

I afraid this line a bit.
if following scenario happend, we can lost VM_NORESERVE?

1. admin set overcommit_memory to "never"
2. mmap
3. admin set overcommit_memory to "guess"

thanks.