From: Kirill Korotaev <dev@sw.ru>
To: Neil Brown <neilb@suse.de>
Cc: Kirill Korotaev <dev@openvz.org>, Jan Blunck <jblunck@suse.de>,
akpm@osdl.org, viro@zeniv.linux.org.uk, olh@suse.de,
bsingharora@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix shrink_dcache_parent() against shrink_dcache_memory() race (3rd updated patch)]
Date: Fri, 10 Mar 2006 11:28:39 +0300 [thread overview]
Message-ID: <441138B7.9060809@sw.ru> (raw)
In-Reply-To: <17425.2594.967505.22336@cse.unsw.edu.au>
Neil,
> On Thursday March 9, dev@openvz.org wrote:
>
>>Andrew,
>>
>>Acked-By: Kirill Korotaev <dev@openvz.org>
>
>
> I'm afraid that I'm not convinced.
>
>
>>>+static int wait_on_prunes(struct super_block *sb)
>>>+{
>>>+ DEFINE_WAIT(wait);
>>>+ int prunes_remaining = 0;
>>>+
>>>+#ifdef DCACHE_DEBUG
>>>+ printk(KERN_DEBUG "%s: waiting for %d prunes\n", __FUNCTION__,
>>>+ sb->s_prunes);
>>>+#endif
>>>+
>>>+ spin_lock(&dcache_lock);
>>>+ for (;;) {
>>>+ prepare_to_wait(&sb->s_wait_prunes, &wait,
>>>+ TASK_UNINTERRUPTIBLE);
>>>+ if (!sb->s_prunes)
>>>+ break;
>>>+ spin_unlock(&dcache_lock);
>>>+ schedule();
>>>+ prunes_remaining = 1;
>>>+ spin_lock(&dcache_lock);
>>>+ }
>>>+ spin_unlock(&dcache_lock);
>>>+ finish_wait(&sb->s_wait_prunes, &wait);
>>>+ return prunes_remaining;
>>>+}
>
>
> I don't think that a return value from wait_on_prunes is meaningful.
> All it tells us is whether a prune_one_dentry finished before or after
> wait_on_prunes takes the spin_lock. This isn't very useful
> information as it has no significance to upper levels.
>
> So:
>
>
>>>+ do {
>>>+ shrink_dcache_parent(root);
>>>+ } while(wait_on_prunes(sb));
>>>+
>
>
> Suppose shrink_dcache_parent misses on dentry because the inode was being
> iput. This iput completes immediately that
> shrink_dcache_parent completes. It decrements ->s_prunes and when
> wait_on_prunes takes dcache_lock, ->s_prunes is zero so the loop
> terminates, and the remaining dentries - the parents of the dentry
> what was undergoing iput - don't get put.
you are right... :/
And this is actually why we originally inserted check for race
in select_parent() under dcache_lock... I just lost my memory :(
> I really think that we need to stop prune_one_dentry from being called
> on dentries for a filesystem that is being unmounted. With that code
> currently in -git, that means passing a 'struct super_block *' into
> prune_dcache so that it ignores any filesystem with ->s_root==NULL
> unless that filesystem is the filesystem that was passed.
Can try...
Thanks,
Kirill
next prev parent reply other threads:[~2006-03-10 8:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-09 16:58 [PATCH] Fix shrink_dcache_parent() against shrink_dcache_memory() race (3rd updated patch)] Jan Blunck
2006-03-09 17:07 ` Kirill Korotaev
2006-03-10 5:09 ` Neil Brown
2006-03-10 8:28 ` Kirill Korotaev [this message]
2006-03-10 10:59 ` Jan Blunck
2006-03-10 11:23 ` Kirill Korotaev
2006-03-10 11:56 ` Neil Brown
2006-03-10 12:02 ` Jan Blunck
2006-03-10 12:19 ` Kirill Korotaev
2006-03-10 11:51 ` Neil Brown
2006-03-10 12:31 ` Jan Blunck
2006-03-10 17:17 ` Balbir Singh
2006-03-12 21:57 ` Neil Brown
2006-03-12 23:03 ` Jan Blunck
2006-03-13 5:45 ` Neil Brown
2006-03-13 15:52 ` Balbir Singh
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=441138B7.9060809@sw.ru \
--to=dev@sw.ru \
--cc=akpm@osdl.org \
--cc=bsingharora@gmail.com \
--cc=dev@openvz.org \
--cc=jblunck@suse.de \
--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.