From: Al Viro <viro@ZenIV.linux.org.uk>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Nathan Rutman <nathan_rutman@xyratex.com>,
Peng Tao <bergwolf@gmail.com>,
"Dilger, Andreas" <andreas.dilger@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [lustre mess] is mgc_fs_setup() reachable at all?
Date: Fri, 19 Jul 2013 09:12:58 +0100 [thread overview]
Message-ID: <20130719081258.GE4165@ZenIV.linux.org.uk> (raw)
In-Reply-To: <3F4C226D-9D3B-46FA-9C8C-55268B2F904F@dilger.ca>
On Thu, Jul 18, 2013 at 02:57:11PM -0600, Andreas Dilger wrote:
> > _THAT_ was going to be a remotely supplied data? I really hope I've
> > misparsed what you said above...
> >
> > And that still leaves the question about the code path that could
> > lead to execution of mgc_fs_setup().
>
> The KEY_SET_FS is only used in the server code, not on the client.
> The MGC code is shared between client and server to mount the
> filesystem and fetch the cluster configuration from the management
> server. In the case of a server mount, it also has to mount the
> underlying block device, which isn't true on the client, so this
> code is indeed unused.
Wait a minute... So we have client side of things in staging, with
parts shared with the server, which is *not* in tree at all? That
sounds painful - any changes done to the client code either risk
to break the server, or have the copies of the shared stuff diverge...
I honestly have no idea about your plans wrt merging; are you going
to put the server side of things there as well?
Another thing: is your ll_statfs_internal() safe to call right up to
the moment when client_common_put_super calls lprocfs_unregister_mountpoint?
Because procfs IO *can* come right until the procfs entry removal;
said removal will act as a barrier, so it won't leak past the return from
remove_proc_entry(), but that's it.
While we are at procfs side of thing, looks like you need exclusion between
ll_..._seq_write() that clear/set bits in ->ll_flags; at least I haven't
found anything that would prevent the races among those.
next prev parent reply other threads:[~2013-07-19 8:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-18 9:08 [lustre mess] is mgc_fs_setup() reachable at all? Al Viro
2013-07-18 13:32 ` Peng Tao
[not found] ` <5DD1CAAA-2008-47F9-B3B6-8D342B28D08C@xyratex.com>
2013-07-18 19:07 ` Al Viro
2013-07-18 20:57 ` Andreas Dilger
2013-07-19 8:12 ` Al Viro [this message]
2013-07-19 9:55 ` Peng, Tao
2013-07-19 9:55 ` Peng, Tao
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=20130719081258.GE4165@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=adilger@dilger.ca \
--cc=andreas.dilger@intel.com \
--cc=bergwolf@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nathan_rutman@xyratex.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 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.