From: green@linuxhacker.ru
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devel@driverdev.osuosl.org,
Andreas Dilger <andreas.dilger@intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Bobi Jam <bobijam.xu@intel.com>,
Oleg Drokin <oleg.drokin@intel.com>
Subject: [PATCH 05/10] staging/lustre/mgc: detach MGC dev on error
Date: Wed, 25 Mar 2015 21:53:21 -0400 [thread overview]
Message-ID: <1427334806-31466-6-git-send-email-green@linuxhacker.ru> (raw)
In-Reply-To: <1427334806-31466-1-git-send-email-green@linuxhacker.ru>
From: Bobi Jam <bobijam.xu@intel.com>
lustre_start_mgc() creates MGC device, if error happens later on
ll_fill_super(), this device is still attached, and later mount
fails by keep complaining that the MGC device's already in the
client node.
It turns out that the device was referenced by mgc config llog data
which is arranged in the mgc lock requeue thread re-trying to get its
mgc lock, and in normal case, this llog reference only released in
mgc_blocking_ast() when the system is umount.
This patch make mgc_precleanup() to wake up requeue thread to handle
the config llog data.
This patch also makes mgc_setup() wait for mgc_requeue_thread() start
before moving on.
Signed-off-by: Bobi Jam <bobijam.xu@intel.com>
Reviewed-on: http://review.whamcloud.com/11765
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4943
Reviewed-by: Ryan Haasken <haasken@cray.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
---
drivers/staging/lustre/lustre/mgc/mgc_request.c | 36 +++++++++++++++++--------
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c b/drivers/staging/lustre/lustre/mgc/mgc_request.c
index 3f00e77..8496d25 100644
--- a/drivers/staging/lustre/lustre/mgc/mgc_request.c
+++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c
@@ -484,9 +484,11 @@ int lprocfs_mgc_rd_ir_state(struct seq_file *m, void *data)
#define RQ_NOW 0x2
#define RQ_LATER 0x4
#define RQ_STOP 0x8
+#define RQ_PRECLEANUP 0x10
static int rq_state;
static wait_queue_head_t rq_waitq;
static DECLARE_COMPLETION(rq_exit);
+static DECLARE_COMPLETION(rq_start);
static void do_requeue(struct config_llog_data *cld)
{
@@ -515,6 +517,8 @@ static void do_requeue(struct config_llog_data *cld)
static int mgc_requeue_thread(void *data)
{
+ bool first = true;
+
CDEBUG(D_MGC, "Starting requeue thread\n");
/* Keep trying failed locks periodically */
@@ -531,13 +535,19 @@ static int mgc_requeue_thread(void *data)
rq_state &= ~(RQ_NOW | RQ_LATER);
spin_unlock(&config_list_lock);
+ if (first) {
+ first = false;
+ complete(&rq_start);
+ }
+
/* Always wait a few seconds to allow the server who
caused the lock revocation to finish its setup, plus some
random so everyone doesn't try to reconnect at once. */
to = MGC_TIMEOUT_MIN_SECONDS * HZ;
to += rand * HZ / 100; /* rand is centi-seconds */
lwi = LWI_TIMEOUT(to, NULL, NULL);
- l_wait_event(rq_waitq, rq_state & RQ_STOP, &lwi);
+ l_wait_event(rq_waitq, rq_state & (RQ_STOP | RQ_PRECLEANUP),
+ &lwi);
/*
* iterate & processing through the list. for each cld, process
@@ -550,6 +560,7 @@ static int mgc_requeue_thread(void *data)
cld_prev = NULL;
spin_lock(&config_list_lock);
+ rq_state &= ~RQ_PRECLEANUP;
list_for_each_entry(cld, &config_llog_list,
cld_list_chain) {
if (!cld->cld_lostlock)
@@ -666,24 +677,26 @@ static atomic_t mgc_count = ATOMIC_INIT(0);
static int mgc_precleanup(struct obd_device *obd, enum obd_cleanup_stage stage)
{
int rc = 0;
+ int temp;
switch (stage) {
case OBD_CLEANUP_EARLY:
break;
case OBD_CLEANUP_EXPORTS:
if (atomic_dec_and_test(&mgc_count)) {
- int running;
+ LASSERT(rq_state & RQ_RUNNING);
/* stop requeue thread */
- spin_lock(&config_list_lock);
- running = rq_state & RQ_RUNNING;
- if (running)
- rq_state |= RQ_STOP;
- spin_unlock(&config_list_lock);
- if (running) {
- wake_up(&rq_waitq);
- wait_for_completion(&rq_exit);
- }
+ temp = RQ_STOP;
+ } else {
+ /* wakeup requeue thread to clean our cld */
+ temp = RQ_NOW | RQ_PRECLEANUP;
}
+ spin_lock(&config_list_lock);
+ rq_state |= temp;
+ spin_unlock(&config_list_lock);
+ wake_up(&rq_waitq);
+ if (temp & RQ_STOP)
+ wait_for_completion(&rq_exit);
obd_cleanup_client_import(obd);
rc = mgc_llog_fini(NULL, obd);
if (rc != 0)
@@ -742,6 +755,7 @@ static int mgc_setup(struct obd_device *obd, struct lustre_cfg *lcfg)
}
/* rc is the task_struct pointer of mgc_requeue_thread. */
rc = 0;
+ wait_for_completion(&rq_start);
}
return rc;
--
2.1.0
next prev parent reply other threads:[~2015-03-26 1:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-26 1:53 [PATCH 00/10] Lustre fixes green
2015-03-26 1:53 ` [PATCH 01/10] staging/lustre/osc: shorten IO calling path green
2015-03-26 2:04 ` [PATCH v2 " green
2015-03-26 10:09 ` Greg Kroah-Hartman
2015-03-26 1:53 ` [PATCH 02/10] staging/lustre/mdc: Handle empty but non-zero acl xattr green
2015-03-26 1:53 ` [PATCH 03/10] staging/lustre/ptlrpc: false alarm in AT network latency measuring green
2015-03-26 1:53 ` [PATCH 04/10] staging/lustre/mgc: check the import stat for lprocfs green
2015-03-26 1:53 ` green [this message]
2015-03-26 1:53 ` [PATCH 06/10] staging/lustre/lov: don't crash accessing LOV object with FID{0,0} green
2015-03-26 1:53 ` [PATCH 07/10] staging/lustre/ptlrpc: fix import state during replay green
2015-03-26 2:07 ` [PATCH v2 " green
2015-03-26 1:53 ` [PATCH 08/10] staging/lustre/llite: glimpse the inode before doing fiemap green
2015-03-26 1:53 ` [PATCH 09/10] staging/lustre: update timestamps after buiding rpc green
2015-03-26 1:53 ` [PATCH 10/10] staging/lustre/xattr: xattr data may be gone with lock held green
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=1427334806-31466-6-git-send-email-green@linuxhacker.ru \
--to=green@linuxhacker.ru \
--cc=andreas.dilger@intel.com \
--cc=bobijam.xu@intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg.drokin@intel.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.