From: "J. R. Okajima" <hooanon05@yahoo.co.jp>
To: Valerie Aurora <vaurora@redhat.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
Neil Brown <neilb@suse.de>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Miklos Szeredi <miklos@szeredi.hu>, Jan Blunck <jblunck@suse.de>,
Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: Union mounts and file locks (was Re: [PATCH 14/39] union-mount: Union mounts documentation)
Date: Wed, 18 Aug 2010 09:27:36 +0900 [thread overview]
Message-ID: <6194.1282091256@jrobl> (raw)
In-Reply-To: <20100817210610.GF5556@shell>
Valerie Aurora:
> Union mounts behaves this way with locks for the same reason as
> fchmod(), etc. on O_RDONLY file descriptors fails. In-kernel copyup
> only happens before a file descriptor is open. Once it is open, it is
> very difficult to switch the open file with the newly copied up file
> ("very difficult" meaning "Al Viro refuses to even discuss it").
Laugh, laugh, laugh.
But this is one of the major difference between "union in VFS" and
"union as FS". By the union implemented as FS, the file object will be a
virtual one in a virtual FS, and you can switch two real files on the
layers in the virtual object.
> However, fcntl(F_SETLK) on a file opened read-write will behave
> exactly as expected. The question is how many applications call
> fcntl(F_SETLK) on a read-only file descriptor as the first lock
> operation on a file? Of those applications, how many could easily be
> rewritten to open that file descriptor with write permissions?
I don't know.
If users never use such AP or never meet the problem, then there will be
no actual problem.
J. R. Okajima
prev parent reply other threads:[~2010-08-18 0:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-17 21:06 Union mounts and file locks (was Re: [PATCH 14/39] union-mount: Union mounts documentation) Valerie Aurora
2010-08-18 0:27 ` J. R. Okajima [this message]
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=6194.1282091256@jrobl \
--to=hooanon05@yahoo.co.jp \
--cc=bfields@fieldses.org \
--cc=hch@infradead.org \
--cc=jblunck@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=neilb@suse.de \
--cc=vaurora@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).