From: Tejun Heo <tj@kernel.org>
To: Hugh Dickins <hugh@veritas.com>
Cc: linux-kernel@vger.kernel.org, fuse-devel@lists.sourceforge.net,
miklos@szeredi.hu, akpm@linux-foundation.org, npiggin@suse.de
Subject: Re: [PATCH 1/5] mmap: don't assume f_op->mmap() doesn't change vma->vm_file
Date: Wed, 15 Apr 2009 11:22:23 +0900 [thread overview]
Message-ID: <49E544DF.2060109@kernel.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0904142047410.16616@blonde.anvils>
Hello,
Hugh Dickins wrote:
> On Tue, 14 Apr 2009, Tejun Heo wrote:
>
>> mmap_region() assumes that vma->vm_file isn't changed by f_op->mmap()
>> and continues to use cache file after f_op->mmap() returns.
>
> It does use "file" again in the unmap_and_free_vma error path
> (isn't that reasonable? if the ->mmap failed, it shouldn't have
> mucked with vma; and even if it has, then we'd better not change
> the current behaviour of which to fput), but I don't see where else.
>
> Further down, covering both vma->vm_file previously set and previously
> unset cases, there is a "file = vma->vm_file;" before file is used.
> So I think this patch is not necessary - if it is necessary, it's
> already a bug, because already we switch from /dev/zero to a
> shmem file there.
Right, ->mmap() shouldn't modify @vma if it has failed. I was trying
to clarify that @vma->file may change as the code was a bit confusing
regarding whether @vma->vm_file is allowed to be substituted or not.
Hmmmm... how about adding a BUG_ON() or WARN_ON() in the failure path
to make sure @vma->vm_file hasn't changed?
Anyways, I'm dropping this patch and updating FUSE mmap implementation
accordingly. Thanks for the comment.
--
tejun
next prev parent reply other threads:[~2009-04-15 2:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-14 2:04 [PATCHSET] FUSE: implement direct mmap, take#2 Tejun Heo
2009-04-14 2:04 ` [PATCH 1/5] mmap: don't assume f_op->mmap() doesn't change vma->vm_file Tejun Heo
2009-04-14 19:59 ` Hugh Dickins
2009-04-15 2:22 ` Tejun Heo [this message]
2009-04-15 4:13 ` Tejun Heo
2009-04-14 2:04 ` [PATCH 2/5] fdtable: export alloc_fd() Tejun Heo
2009-04-14 2:04 ` [PATCH 3/5] FUSE: make request_wait_answer() wait for ->end() completion Tejun Heo
2009-04-14 2:04 ` [PATCH 4/5] FUSE: implement fuse_req->prep() Tejun Heo
2009-04-14 2:04 ` [PATCH 5/5] FUSE: implement direct mmap Tejun Heo
2009-04-15 4:14 ` [PATCH UPDATED] " Tejun Heo
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=49E544DF.2060109@kernel.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=fuse-devel@lists.sourceforge.net \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=npiggin@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.