Re: [Bug 67651] Bisected: Lots of fragmented mmaps cause gimp tofail in 3.12 after exceeding vm_max_map_count

From: Andy Lutomirski
Date: Wed Jan 22 2014 - 17:46:02 EST

On 01/22/2014 11:08 AM, Mel Gorman wrote:
> Cyrill,
> Gimp is broken due to a kernel bug included in 3.12. It cannot open
> large files without failing memory allocations due to exceeding
> vm.max_map_count. The relevant bugzilla entries are
> They include details on how to reproduce the issue. In my case, a
> failure shows messages like this
> (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
> X-related junk is there was because I was using a headless server and
> xinit directly to launch gimp to reproduce the bug.
> Automated bisection using mmtests (
> and the configuration file configs/config-global-dhp__gimp-simple (needs
> local web server with a copy of the image file) identified the following
> commit. Test case was simple -- try and open the large file described in
> the bug. I did not investigate the patch itself as I'm just reporting
> the results of the bisection. If I had to guess, I'd say that VMA
> merging has been affected.
> d9104d1ca9662498339c0de975b4666c30485f4e is the first bad commit
> commit d9104d1ca9662498339c0de975b4666c30485f4e
> Author: Cyrill Gorcunov <gorcunov@xxxxxxxxx>
> Date: Wed Sep 11 14:22:24 2013 -0700
> mm: track vma changes with VM_SOFTDIRTY bit
> Pavel reported that in case if vma area get unmapped and then mapped (or
> expanded) in-place, the soft dirty tracker won't be able to recognize this
> situation since it works on pte level and ptes are get zapped on unmap,
> loosing soft dirty bit of course.
> So to resolve this situation we need to track actions on vma level, there
> VM_SOFTDIRTY flag comes in. When new vma area created (or old expanded)
> we set this bit, and keep it here until application calls for clearing
> soft dirty bit.
> Thus when user space application track memory changes now it can detect if
> vma area is renewed.

Presumably some path is failing to set VM_SOFTDIRTY, thus preventing mms
from being merged.

That being said, this could cause vma blowups for programs that are
actually using this thing.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at