From: Jan Blunck <jblunck@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: balbir@in.ibm.com, viro@zeniv.linux.org.uk, olh@suse.de,
neilb@suse.de, dev@openvz.org, bsingharora@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix shrink_dcache_parent() against shrink_dcache_memory() race (updated patch)
Date: Thu, 9 Mar 2006 12:58:27 +0100 [thread overview]
Message-ID: <20060309115827.GF4243@hasse.suse.de> (raw)
In-Reply-To: <20060309032157.0592153e.akpm@osdl.org>
On Thu, Mar 09, Andrew Morton wrote:
> > Hmm, right. Andrew, if you want a rediff against -mm just tell me. I'm
> > actually diff'ing against lates linux-2.6.git.
>
> I'll work it out.
>
Ok, so I'll just send an updated patch against linux-2.6.git adressing your
issues later.
> Cosmetically, I don't think wait_on_prunes() should be concerned about
> whether or not it "slept". That action is not significant and preemptible
> kernels can "sleep" at just about any stage. So I think the concept of
> "slept" in there should be replaced with, say, "prunes_remaining" or
> something like that. Consequently the all-important comment over
> wait_on_prunes() should be updated to provide a bit more information about
> the significance of its return value, please.
Ok, will do.
> Also I think there should be some explanation somewhere which describes why
> we can continue to assume that there aren't any prunes left to do after
> wait_on_prunes() has dropped dcache_lock. I mean, once you've dropped the
> lock it's usually the case that anything which you examined while holding
> that lock now becomes out-of-date and invalid. I assume the thinking is
> that because there's an unmount in progress, nothing can come in and add
> new dentries?
>
> IOW: why isn't there a race between wait_on_prunes() and prune_one_dentry()?
Because outside dcache_lock, either the refcount on the parent dentry is wrong
(therefore select_parent() might return 0) and sb_prunes != 0 or the refcount
is correct and the sb_prunes == 0. Since sb_root == NULL when unmounting the
filesystem there are no new dentries coming in.
> Are we all happy with this patch now?
I'll update the comments and come back to you with an updated patch. Then I'm
fine with the patch.
Regards,
Jan
--
Jan Blunck jblunck@suse.de
SuSE LINUX AG - A Novell company
Maxfeldstr. 5 +49-911-74053-608
D-90409 Nürnberg http://www.suse.de
next prev parent reply other threads:[~2006-03-09 11:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-08 14:51 [PATCH] Fix shrink_dcache_parent() against shrink_dcache_memory() race (updated patch) Jan Blunck
2006-03-09 6:33 ` Balbir Singh
2006-03-09 11:00 ` Jan Blunck
2006-03-09 11:21 ` Andrew Morton
2006-03-09 11:58 ` Jan Blunck [this message]
2006-03-09 12:53 ` Kirill Korotaev
2006-03-09 14:08 ` Jan Blunck
2006-03-09 14:36 ` Kirill Korotaev
2006-03-09 11:36 ` Balbir Singh
2006-03-09 14:42 ` Kirill Korotaev
2006-03-09 16:09 ` Jan Blunck
2006-03-09 16:18 ` Kirill Korotaev
2006-03-09 16:39 ` Jan Blunck
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=20060309115827.GF4243@hasse.suse.de \
--to=jblunck@suse.de \
--cc=akpm@osdl.org \
--cc=balbir@in.ibm.com \
--cc=bsingharora@gmail.com \
--cc=dev@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=olh@suse.de \
--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 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.