All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul@parallels.com>
To: Cyrill Gorcunov <gorcunov@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>,
	gnome@rvzt.net, grawoc@darkrefraction.com,
	alan@lxorguk.ukuu.org.uk, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	bugzilla-daemon@bugzilla.kernel.org
Subject: Re: [PATCH] mm: Ignore VM_SOFTDIRTY on VMA merging, v2
Date: Thu, 23 Jan 2014 22:07:15 +0400	[thread overview]
Message-ID: <52E15A53.5020007@parallels.com> (raw)
In-Reply-To: <20140123151445.GX1574@moon>

On 01/23/2014 07:14 PM, Cyrill Gorcunov wrote:

> I think setting up dirty bit inside vma_merge() body is a big hammer
> which should not be used, but it's up to caller of vma_merge() to figure
> out if dirty bit should be set or not if merge successed. Thus softdirty
> vma bit should be (and it already is) set at the end of mmap_region and do_brk
> routines. So patch could be simplified (below). Pavel, what do you think?

Looks correct, thank you!

Acked-by: Pavel Emelyanov <xemul@parallels,com>

> ---
> From: Cyrill Gorcunov <gorcunov@gmail.com>
> Subject: [PATCH] mm: Ignore VM_SOFTDIRTY on VMA merging, v2
> 
> VM_SOFTDIRTY bit affects vma merge routine: if two VMAs has all
> bits in vm_flags matched except dirty bit the kernel can't longer
> merge them and this forces the kernel to generate new VMAs instead.
> 
> It finally may lead to the situation when userspace application
> reaches vm.max_map_count limit and get crashed in worse case
> 
>  | (gimp:11768): GLib-ERROR **: gmem.c:110: failed to allocate 4096 bytes
>  |
>  | (file-tiff-load:12038): LibGimpBase-WARNING **: file-tiff-load: gimp_wire_read(): error
>  | xinit: connection to X server lost
>  |
>  | waiting for X server to shut down
>  | /usr/lib64/gimp/2.0/plug-ins/file-tiff-load terminated: Hangup
>  | /usr/lib64/gimp/2.0/plug-ins/script-fu terminated: Hangup
>  | /usr/lib64/gimp/2.0/plug-ins/script-fu terminated: Hangup
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=67651
> https://bugzilla.gnome.org/show_bug.cgi?id=719619#c0
> 
> Initial problem came from missed VM_SOFTDIRTY in do_brk() routine
> but even if we would set up VM_SOFTDIRTY here, there is still a way to
> prevent VMAs from merging: one can call
> 
>  | echo 4 > /proc/$PID/clear_refs
> 
> and clear all VM_SOFTDIRTY over all VMAs presented in memory map,
> then new do_brk() will try to extend old VMA and finds that dirty
> bit doesn't match thus new VMA will be generated.
> 
> As discussed to Pavel, the right approach should be to ignore
> VM_SOFTDIRTY bit when we're trying to merge VMAs and if merge
> successed we mark extended VMA with dirty bit where needed.
> 
> v2: Don't mark VMA as dirty inside vma_merge() body, it's up
>     to calling code to set up dirty bit where needed.
> 
> Reported-by: Mel Gorman <mgorman@suse.de>
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
> CC: Pavel Emelyanov <xemul@parallels.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> ---
>  mm/mmap.c |   12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6.git/mm/mmap.c
> ===================================================================
> --- linux-2.6.git.orig/mm/mmap.c
> +++ linux-2.6.git/mm/mmap.c
> @@ -893,7 +893,15 @@ again:			remove_next = 1 + (end > next->
>  static inline int is_mergeable_vma(struct vm_area_struct *vma,
>  			struct file *file, unsigned long vm_flags)
>  {
> -	if (vma->vm_flags ^ vm_flags)
> +	/*
> +	 * VM_SOFTDIRTY should not prevent from VMA merging, if we
> +	 * match the flags but dirty bit -- the caller should mark
> +	 * merged VMA as dirty. If dirty bit won't be excluded from
> +	 * comparison, we increase pressue on the memory system forcing
> +	 * the kernel to generate new VMAs when old one could be
> +	 * extended instead.
> +	 */
> +	if ((vma->vm_flags ^ vm_flags) & ~VM_SOFTDIRTY)
>  		return 0;
>  	if (vma->vm_file != file)
>  		return 0;
> @@ -1082,7 +1090,7 @@ static int anon_vma_compatible(struct vm
>  	return a->vm_end == b->vm_start &&
>  		mpol_equal(vma_policy(a), vma_policy(b)) &&
>  		a->vm_file == b->vm_file &&
> -		!((a->vm_flags ^ b->vm_flags) & ~(VM_READ|VM_WRITE|VM_EXEC)) &&
> +		!((a->vm_flags ^ b->vm_flags) & ~(VM_READ|VM_WRITE|VM_EXEC|VM_SOFTDIRTY)) &&
>  		b->vm_pgoff == a->vm_pgoff + ((b->vm_start - a->vm_start) >> PAGE_SHIFT);
>  }
>  
> .
> 


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Pavel Emelyanov <xemul@parallels.com>
To: Cyrill Gorcunov <gorcunov@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>, <gnome@rvzt.net>,
	<grawoc@darkrefraction.com>, <alan@lxorguk.ukuu.org.uk>,
	<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
	<bugzilla-daemon@bugzilla.kernel.org>
Subject: Re: [PATCH] mm: Ignore VM_SOFTDIRTY on VMA merging, v2
Date: Thu, 23 Jan 2014 22:07:15 +0400	[thread overview]
Message-ID: <52E15A53.5020007@parallels.com> (raw)
In-Reply-To: <20140123151445.GX1574@moon>

On 01/23/2014 07:14 PM, Cyrill Gorcunov wrote:

> I think setting up dirty bit inside vma_merge() body is a big hammer
> which should not be used, but it's up to caller of vma_merge() to figure
> out if dirty bit should be set or not if merge successed. Thus softdirty
> vma bit should be (and it already is) set at the end of mmap_region and do_brk
> routines. So patch could be simplified (below). Pavel, what do you think?

Looks correct, thank you!

Acked-by: Pavel Emelyanov <xemul@parallels,com>

> ---
> From: Cyrill Gorcunov <gorcunov@gmail.com>
> Subject: [PATCH] mm: Ignore VM_SOFTDIRTY on VMA merging, v2
> 
> VM_SOFTDIRTY bit affects vma merge routine: if two VMAs has all
> bits in vm_flags matched except dirty bit the kernel can't longer
> merge them and this forces the kernel to generate new VMAs instead.
> 
> It finally may lead to the situation when userspace application
> reaches vm.max_map_count limit and get crashed in worse case
> 
>  | (gimp:11768): GLib-ERROR **: gmem.c:110: failed to allocate 4096 bytes
>  |
>  | (file-tiff-load:12038): LibGimpBase-WARNING **: file-tiff-load: gimp_wire_read(): error
>  | xinit: connection to X server lost
>  |
>  | waiting for X server to shut down
>  | /usr/lib64/gimp/2.0/plug-ins/file-tiff-load terminated: Hangup
>  | /usr/lib64/gimp/2.0/plug-ins/script-fu terminated: Hangup
>  | /usr/lib64/gimp/2.0/plug-ins/script-fu terminated: Hangup
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=67651
> https://bugzilla.gnome.org/show_bug.cgi?id=719619#c0
> 
> Initial problem came from missed VM_SOFTDIRTY in do_brk() routine
> but even if we would set up VM_SOFTDIRTY here, there is still a way to
> prevent VMAs from merging: one can call
> 
>  | echo 4 > /proc/$PID/clear_refs
> 
> and clear all VM_SOFTDIRTY over all VMAs presented in memory map,
> then new do_brk() will try to extend old VMA and finds that dirty
> bit doesn't match thus new VMA will be generated.
> 
> As discussed to Pavel, the right approach should be to ignore
> VM_SOFTDIRTY bit when we're trying to merge VMAs and if merge
> successed we mark extended VMA with dirty bit where needed.
> 
> v2: Don't mark VMA as dirty inside vma_merge() body, it's up
>     to calling code to set up dirty bit where needed.
> 
> Reported-by: Mel Gorman <mgorman@suse.de>
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
> CC: Pavel Emelyanov <xemul@parallels.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> ---
>  mm/mmap.c |   12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6.git/mm/mmap.c
> ===================================================================
> --- linux-2.6.git.orig/mm/mmap.c
> +++ linux-2.6.git/mm/mmap.c
> @@ -893,7 +893,15 @@ again:			remove_next = 1 + (end > next->
>  static inline int is_mergeable_vma(struct vm_area_struct *vma,
>  			struct file *file, unsigned long vm_flags)
>  {
> -	if (vma->vm_flags ^ vm_flags)
> +	/*
> +	 * VM_SOFTDIRTY should not prevent from VMA merging, if we
> +	 * match the flags but dirty bit -- the caller should mark
> +	 * merged VMA as dirty. If dirty bit won't be excluded from
> +	 * comparison, we increase pressue on the memory system forcing
> +	 * the kernel to generate new VMAs when old one could be
> +	 * extended instead.
> +	 */
> +	if ((vma->vm_flags ^ vm_flags) & ~VM_SOFTDIRTY)
>  		return 0;
>  	if (vma->vm_file != file)
>  		return 0;
> @@ -1082,7 +1090,7 @@ static int anon_vma_compatible(struct vm
>  	return a->vm_end == b->vm_start &&
>  		mpol_equal(vma_policy(a), vma_policy(b)) &&
>  		a->vm_file == b->vm_file &&
> -		!((a->vm_flags ^ b->vm_flags) & ~(VM_READ|VM_WRITE|VM_EXEC)) &&
> +		!((a->vm_flags ^ b->vm_flags) & ~(VM_READ|VM_WRITE|VM_EXEC|VM_SOFTDIRTY)) &&
>  		b->vm_pgoff == a->vm_pgoff + ((b->vm_start - a->vm_start) >> PAGE_SHIFT);
>  }
>  
> .
> 



  reply	other threads:[~2014-01-23 18:07 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-22 19:08 [Bug 67651] Bisected: Lots of fragmented mmaps cause gimp to fail in 3.12 after exceeding vm_max_map_count Mel Gorman
2014-01-22 19:08 ` Mel Gorman
2014-01-22 19:19 ` Cyrill Gorcunov
2014-01-22 19:19   ` Cyrill Gorcunov
2014-01-22 22:33   ` Cyrill Gorcunov
2014-01-22 22:33     ` Cyrill Gorcunov
2014-01-23  9:55     ` Mel Gorman
2014-01-23  9:55       ` Mel Gorman
2014-01-23 10:36       ` Cyrill Gorcunov
2014-01-23 10:36         ` Cyrill Gorcunov
2014-01-23 12:15         ` Cyrill Gorcunov
2014-01-23 12:15           ` Cyrill Gorcunov
2014-01-23 12:55           ` Cyrill Gorcunov
2014-01-23 12:55             ` Cyrill Gorcunov
2014-01-23 15:14             ` [PATCH] mm: Ignore VM_SOFTDIRTY on VMA merging, v2 Cyrill Gorcunov
2014-01-23 15:14               ` Cyrill Gorcunov
2014-01-23 18:07               ` Pavel Emelyanov [this message]
2014-01-23 18:07                 ` Pavel Emelyanov
2014-01-23 21:02               ` Andrew Morton
2014-01-23 21:02                 ` Andrew Morton
2014-01-23 21:45                 ` Cyrill Gorcunov
2014-01-23 21:45                   ` Cyrill Gorcunov
2014-01-24 10:14               ` Mel Gorman
2014-01-24 10:14                 ` Mel Gorman
2014-01-24 11:56                 ` Cyrill Gorcunov
2014-01-24 11:56                   ` Cyrill Gorcunov
2014-01-24 13:41                   ` Mel Gorman
2014-01-24 13:41                     ` Mel Gorman
2014-01-24 14:23                     ` Cyrill Gorcunov
2014-01-24 14:23                       ` Cyrill Gorcunov
2014-01-23 10:30     ` [Bug 67651] Bisected: Lots of fragmented mmaps cause gimp to fail in 3.12 after exceeding vm_max_map_count Mel Gorman
2014-01-23 10:30       ` Mel Gorman
2022-12-07 22:00       ` Cyrill Gorcunov
2014-01-22 19:52 ` Andrew Morton
2014-01-22 19:52   ` Andrew Morton
2014-01-23  7:28   ` Mel Gorman
2014-01-23  7:28     ` Mel Gorman
2014-01-22 22:45 ` Andy Lutomirski
2014-01-22 22:45   ` Andy Lutomirski
2014-01-23  5:59   ` Cyrill Gorcunov
2014-01-23  5:59     ` Cyrill Gorcunov
2014-01-23  6:09     ` Andrew Morton
2014-01-23  6:09       ` Andrew Morton
2014-01-23  6:27       ` Cyrill Gorcunov
2014-01-23  6:27         ` Cyrill Gorcunov
2022-11-21 17:23         ` Muhammad Usama Anjum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52E15A53.5020007@parallels.com \
    --to=xemul@parallels.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=bugzilla-daemon@bugzilla.kernel.org \
    --cc=gnome@rvzt.net \
    --cc=gorcunov@gmail.com \
    --cc=grawoc@darkrefraction.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.