From: Theodore Ts'o <tytso@mit.edu>
To: Abbas Raza <abbas_raza@mentor.com>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 1/2] procfs: Add function to lookup a subdirectory name
Date: Sat, 21 Dec 2013 20:20:09 -0500 [thread overview]
Message-ID: <20131222012009.GA27304@thunk.org> (raw)
In-Reply-To: <1387580357-28440-1-git-send-email-abbas_raza@mentor.com>
On Sat, Dec 21, 2013 at 03:59:16AM +0500, Abbas Raza wrote:
> /*
> + * Lookup if a subdirectory is present in the given directory by name
> + */
> +int proc_lookup_subdir_by_name(struct proc_dir_entry *dir, const char *name)
> +{
I'm not sure this is the best way to solve the problem you are trying
to get at in patch 2/2. First of all, this solution is fundamentally
racy; the moment you release proc_subdir_lock, there's always a chance
that some other process will come in and create the proc file in the
subdirectory. Sure, it's not likely in the case of the ext4 use case,
but as a generic function to be added to fs/proc/generic.c, I suspent
Al is going to NACK this.
Secondly, there is a bigger problem that this is papering over, which
is we don't have a good way of dealing with an unclean eject. If the
the system was in the middle of reading or writing to the file system
at the time of the unclean eject, there will be all sorts of warnings
and file system errors that will be logged. That's because we don't
have a way for the block device layer to let the file system know that
the block device has disappeared, and we need to revoke open file
descriptors, and accept the fact that any dirty pages in the cache
cache need to be deleted, lest it clog the system memory forever.
Given the larger problem, I have to admit it's hard for me to get
excited about trying to suppress this particular warning message. If
we are going to do this, it may be better to simply add a new
proc_mkdir_flags() interface which extends proc_mkdir_data() with a
new integer flags parameter, for which we define a new flag, which
suppresses the warning.
Regards,
- Ted
prev parent reply other threads:[~2013-12-22 1:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-20 22:59 [PATCH 1/2] procfs: Add function to lookup a subdirectory name Abbas Raza
2013-12-20 22:59 ` [PATCH 2/2] ext4: handle mount failures more gracefully Abbas Raza
2013-12-22 1:20 ` Theodore Ts'o [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=20131222012009.GA27304@thunk.org \
--to=tytso@mit.edu \
--cc=abbas_raza@mentor.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--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).