From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: "'Hugh Dickins'" <hugh@veritas.com>
Cc: "'David Gibson'" <david@gibson.dropbear.id.au>,
"Andrew Morton" <akpm@osdl.org>, <linux-kernel@vger.kernel.org>
Subject: RE: Hugepage regression
Date: Tue, 10 Oct 2006 16:03:44 -0700 [thread overview]
Message-ID: <000201c6ecc0$565cdc00$cb34030a@amr.corp.intel.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0610102045190.24759@blonde.wat.veritas.com>
Hugh Dickins wrote on Tuesday, October 10, 2006 1:10 PM
> > can we reverse that order (call unmap_region
> > and then nulls out vma->vmfile and fput)?
>
> I'm pretty sure we cannot: the ordering is quite intentional, that if
> a driver ->mmap failed, then it'd be wrong to call down to driver in
> the unmap_region (if a driver is nicely behaved, that unmap_region
> shouldn't be unnecessary; but some do rely on us clearing ptes there).
Even not something like the following? I believe you that nullifying
vma->vm_file can not be done after unmap_region(), I just want to make
sure we are talking the same thing. It looks OK to me to defer the fput
in the do_mmap_pgoff clean up path.
--- ./mm/mmap.c.orig 2006-10-10 15:58:17.000000000 -0700
+++ ./mm/mmap.c 2006-10-10 15:59:02.000000000 -0700
@@ -1159,11 +1159,12 @@ out:
unmap_and_free_vma:
if (correct_wcount)
atomic_inc(&inode->i_writecount);
- vma->vm_file = NULL;
- fput(file);
/* Undo any partial mapping done by a device driver. */
unmap_region(mm, vma, prev, vma->vm_start, vma->vm_end);
+
+ vma->vm_file = NULL;
+ fput(file);
charged = 0;
free_vma:
kmem_cache_free(vm_area_cachep, vma);
next prev parent reply other threads:[~2006-10-10 23:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-10 8:47 Hugepage regression David Gibson
2006-10-10 9:04 ` Andrew Morton
2006-10-10 9:15 ` David Gibson
2006-10-10 17:35 ` Chen, Kenneth W
2006-10-10 19:14 ` Andrew Morton
2006-10-10 19:18 ` Hugh Dickins
2006-10-10 19:30 ` Chen, Kenneth W
2006-10-10 20:10 ` Hugh Dickins
2006-10-10 23:03 ` Chen, Kenneth W [this message]
2006-10-13 17:03 ` Hugh Dickins
2006-10-10 23:34 ` Chen, Kenneth W
2006-10-11 1:18 ` 'David Gibson'
2006-10-11 2:47 ` Chen, Kenneth W
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='000201c6ecc0$565cdc00$cb34030a@amr.corp.intel.com' \
--to=kenneth.w.chen@intel.com \
--cc=akpm@osdl.org \
--cc=david@gibson.dropbear.id.au \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
/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.