From: Linus Torvalds <torvalds@linux-foundation.org>
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Hugh Dickins <hugh@veritas.com>, Greg KH <gregkh@suse.de>,
Maksim Yevmenkin <maksim.yevmenkin@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Nick Piggin <npiggin@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
will@crowder-design.com, Rik van Riel <riel@redhat.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH] Fix OOPS in mmap_region() when merging adjacent VM_LOCKED file segments
Date: Fri, 30 Jan 2009 12:31:13 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.00.0901301159500.3150@localhost.localdomain> (raw)
In-Reply-To: <1233345190.908.36.camel@lts-notebook>
On Fri, 30 Jan 2009, Lee Schermerhorn wrote:
>
> Ad hoc instrumentation shows that it's the VM_ACCOUNT flag that is
> different between the existing file segment and the one attempting the
> merge:
Gaah. I looked at VM_ACCOUNT, since it looked like a prime example of the
same VM_CAN_NONLINEAR thing and was thinking that I should just add it to
the "ok to merge" flags, but decided after a quick look that we do all the
VM_ACCOUNT handling before we call vma_merge, so I just left it at that.
But apparently we _do_ do some VM_ACCOUNT stuff afterwards.
> is_mergeable_vma: !mergable: vma flags: 0x80020f9:0x1020f9
> | |-VM_ACCOUNT
> +-----------VM_CAN_NONLINEAR
>
> So happens, I'm mapping with MAP_SHARED, so the VM_ACCOUNT flag gets
> cleared later in mmap_region(). Comments say that this is for checking
> memory availability during shmem_file_setup(). Maybe we can move the
> temporary setting of VM_ACCOUNT until just before the call to
> shmem_zero_setup()?
Yeah, that would probably fix it, and looks like the right thing to do.
It all looks pretty confused wrong to set the whole VM_ACCOUNT flag for a
file-backed file AT ALL in the first place, but the code knows that it
won't matter for a shared file, and will be cleared again later.
So it plays these temporary games with vm_flags, and it didn't matter
because of how we used to call "vma_merge()" either early only for the
anonymous memory case (that had VM_ACCOUNT stable and didn't have that
temporary case at all) or much later (after having undone the temporary
flag setting) for files.
Why do we pass in that "accountable" flag, btw? It's only ever set to 0 by
a MAP_PRIVATE mapping that hits is_file_hugepages() (see do_mmap_pgoff),
and we could just do that decision all inside mmap_region(). So the flag
doesn't really seem to have any real meaning, and is just passed around
for some odd historical reason?
Linus
next prev parent reply other threads:[~2009-01-30 20:31 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bb4a86c70901281151w4300605r3882461cd6e9774a@mail.gmail.com>
[not found] ` <alpine.LFD.2.00.0901281316450.3123@localhost.localdomain>
2009-01-29 20:03 ` Lee Schermerhorn
2009-01-29 20:33 ` Linus Torvalds
2009-01-29 20:48 ` Linus Torvalds
2009-01-29 22:32 ` Hugh Dickins
2009-01-29 23:02 ` Linus Torvalds
2009-01-30 4:43 ` Lee Schermerhorn
2009-01-30 4:49 ` Linus Torvalds
2009-01-29 22:47 ` Maksim Yevmenkin
2009-01-29 22:48 ` Randy Dunlap
2009-01-29 23:31 ` Maksim Yevmenkin
2009-01-30 2:08 ` Linus Torvalds
2009-01-30 5:56 ` Greg KH
2009-01-30 16:36 ` Linus Torvalds
2009-01-30 17:40 ` Hugh Dickins
2009-01-30 18:14 ` Linus Torvalds
2009-01-30 18:30 ` Hugh Dickins
2009-01-30 19:53 ` Lee Schermerhorn
2009-01-30 20:31 ` Linus Torvalds [this message]
2009-01-30 21:12 ` Hugh Dickins
2009-01-30 21:25 ` Linus Torvalds
2009-01-30 21:36 ` Lee Schermerhorn
2009-01-30 22:27 ` Linus Torvalds
2009-01-31 12:35 ` Hugh Dickins
2009-01-31 18:34 ` Linus Torvalds
2009-02-02 11:59 ` KOSAKI Motohiro
2009-02-02 12:54 ` Hugh Dickins
2009-02-02 14:10 ` KOSAKI Motohiro
2009-02-02 18:58 ` Mel Gorman
2009-02-02 19:23 ` Linus Torvalds
2009-02-02 21:50 ` Mel Gorman
2009-02-02 22:12 ` Linus Torvalds
2009-02-02 22:35 ` Mel Gorman
2009-02-02 18:33 ` Mel Gorman
2009-02-03 16:13 ` Lee Schermerhorn
2009-02-03 16:40 ` Linus Torvalds
2009-02-03 17:10 ` Hugh Dickins
2009-02-03 21:50 ` Lee Schermerhorn
2009-01-30 21:37 ` Linus Torvalds
2009-01-31 12:16 ` Hugh Dickins
2009-01-30 20:33 ` Hugh Dickins
2009-01-30 20:53 ` Randy Dunlap
2009-01-30 20:59 ` Lee Schermerhorn
2009-01-30 21:11 ` Will Crowder
2009-01-30 23:44 ` Greg KH
2009-01-30 8:34 ` Peter Zijlstra
2009-01-30 16:45 ` Linus Torvalds
2009-01-30 16:49 ` Randy Dunlap
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=alpine.LFD.2.00.0901301159500.3150@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=Lee.Schermerhorn@hp.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@suse.de \
--cc=hugh@veritas.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maksim.yevmenkin@gmail.com \
--cc=npiggin@suse.de \
--cc=riel@redhat.com \
--cc=will@crowder-design.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®