From: Tejun Heo <tj@kernel.org>
To: gregkh@linuxfoundation.org
Cc: linux-kernel@vger.kernel.org, schwidefsky@de.ibm.com,
heiko.carstens@de.ibm.com, stern@rowland.harvard.edu,
JBottomley@parallels.com, bhelgaas@google.com,
Tejun Heo <tj@kernel.org>
Subject: [PATCH 04/12] kernfs: invoke kernfs_unmap_bin_file() directly from kernfs_deactivate()
Date: Mon, 3 Feb 2014 14:02:57 -0500 [thread overview]
Message-ID: <1391454185-32143-5-git-send-email-tj@kernel.org> (raw)
In-Reply-To: <1391454185-32143-1-git-send-email-tj@kernel.org>
kernfs_unmap_bin_file() is supposed to unmap all memory mappings of
the target file before kernfs_remove() finishes; however, it currently
is being called from kernfs_addrm_finish() and has the same race
problem as the original implementation of deactivation when there are
multiple removers - only the remover which snatches the node to its
addrm_cxt->removed list is guaranteed to wait for its completion
before returning.
It can be easily fixed by moving kernfs_unmap_bin_file() invocation
from kernfs_addrm_finish() to kernfs_deactivated(). The function may
be called multiple times but that shouldn't do any harm.
Signed-off-by: Tejun Heo <tj@kernel.org>
---
fs/kernfs/dir.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index 3ac9373..9603c06 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -177,9 +177,10 @@ void kernfs_put_active(struct kernfs_node *kn)
* kernfs_deactivate - deactivate kernfs_node
* @kn: kernfs_node to deactivate
*
- * Deny new active references and drain existing ones. Mutiple
- * removers may invoke this function concurrently on @kn and all will
- * return after deactivation and draining are complete.
+ * Deny new active references, drain existing ones and nuke all
+ * existing mmaps. Mutiple removers may invoke this function
+ * concurrently on @kn and all will return after deactivation and
+ * draining are complete.
*/
static void kernfs_deactivate(struct kernfs_node *kn)
__releases(&kernfs_mutex) __acquires(&kernfs_mutex)
@@ -213,6 +214,8 @@ static void kernfs_deactivate(struct kernfs_node *kn)
rwsem_release(&kn->dep_map, 1, _RET_IP_);
}
+ kernfs_unmap_bin_file(kn);
+
mutex_lock(&kernfs_mutex);
}
@@ -493,7 +496,6 @@ void kernfs_addrm_finish(struct kernfs_addrm_cxt *acxt)
acxt->removed = kn->u.removed_list;
- kernfs_unmap_bin_file(kn);
kernfs_put(kn);
}
}
--
1.8.5.3
next prev parent reply other threads:[~2014-02-03 19:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-03 19:02 [PATCHSET v5 driver-core-next] kernfs, sysfs, driver-core: implement synchronous self-removal Tejun Heo
2014-02-03 19:02 ` [PATCH 01/12] kernfs: make kernfs_deactivate() honor KERNFS_LOCKDEP flag Tejun Heo
2014-02-03 19:02 ` [PATCH 02/12] kernfs: replace kernfs_node->u.completion with kernfs_root->deactivate_waitq Tejun Heo
2014-02-03 19:02 ` [PATCH 03/12] kernfs: restructure removal path to fix possible premature return Tejun Heo
2014-02-03 19:02 ` Tejun Heo [this message]
2014-02-03 19:02 ` [PATCH 05/12] kernfs: remove kernfs_addrm_cxt Tejun Heo
2014-02-03 19:02 ` [PATCH 06/12] kernfs: remove KERNFS_ACTIVE_REF and add kernfs_lockdep() Tejun Heo
2014-02-03 19:03 ` [PATCH 07/12] kernfs: remove KERNFS_REMOVED Tejun Heo
2014-02-03 19:03 ` [PATCH 08/12] kernfs, sysfs, driver-core: implement kernfs_remove_self() and its wrappers Tejun Heo
2014-02-03 19:03 ` [PATCH 09/12] pci: use device_remove_file_self() instead of device_schedule_callback() Tejun Heo
2014-02-03 19:03 ` [PATCH 10/12] scsi: " Tejun Heo
2014-02-03 19:03 ` [PATCH 11/12] s390: " Tejun Heo
2014-02-03 19:03 ` [PATCH 12/12] sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner() Tejun Heo
-- strict thread matches above, loose matches on Subject: below --
2014-01-07 17:59 [PATCHSET driver-core-next] kernfs, sysfs, driver-core: implement synchronous self-removal Tejun Heo
2014-01-07 17:59 ` [PATCH 04/12] kernfs: invoke kernfs_unmap_bin_file() directly from kernfs_deactivate() Tejun Heo
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=1391454185-32143-5-git-send-email-tj@kernel.org \
--to=tj@kernel.org \
--cc=JBottomley@parallels.com \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=schwidefsky@de.ibm.com \
--cc=stern@rowland.harvard.edu \
/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.