* [PATCH] lockd
@ 2004-10-04 16:24 Steve Dickson
2004-10-04 17:50 ` Trond Myklebust
2004-10-04 18:01 ` Trond Myklebust
0 siblings, 2 replies; 6+ messages in thread
From: Steve Dickson @ 2004-10-04 16:24 UTC (permalink / raw)
To: nfs; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 225 bytes --]
Hey Neil,
Attached is a patch that fixes some potential SMP races
in the lockd code that were identified by the SLEEP_ON_BKLCHECK
that was (at one time) in the -mm tree...
Signed-Off-By: Steve Dickson <SteveD@RedHat.com>
[-- Attachment #2: linux-2.6.9-rc3-mm2-lockd-smprace.patch --]
[-- Type: text/x-patch, Size: 2343 bytes --]
--- 2.6.9-rc3-mm2/fs/lockd/clntlock.c.old 2004-10-04 09:32:20.404018000 -0400
+++ 2.6.9-rc3-mm2/fs/lockd/clntlock.c 2004-10-04 11:29:38.940621000 -0400
@@ -50,14 +50,19 @@ nlmclnt_block(struct nlm_host *host, str
struct nlm_wait block, **head;
int err;
u32 pstate;
+ wait_queue_t __wait;
block.b_host = host;
block.b_lock = fl;
- init_waitqueue_head(&block.b_wait);
block.b_status = NLM_LCK_BLOCKED;
+ init_waitqueue_entry(&__wait, current);
+ init_waitqueue_head(&block.b_wait);
+ add_wait_queue(&block.b_wait, &__wait);
+
block.b_next = nlm_blocked;
nlm_blocked = █
+
/* Remember pseudo nsm state */
pstate = host->h_state;
@@ -69,7 +74,7 @@ nlmclnt_block(struct nlm_host *host, str
* a 1 minute timeout would do. See the comment before
* nlmclnt_lock for an explanation.
*/
- sleep_on_timeout(&block.b_wait, 30*HZ);
+ schedule_timeout(30*HZ);
for (head = &nlm_blocked; *head; head = &(*head)->b_next) {
if (*head == &block) {
@@ -77,6 +82,7 @@ nlmclnt_block(struct nlm_host *host, str
break;
}
}
+ remove_wait_queue(&block.b_wait, &__wait);
if (!signalled()) {
*statp = block.b_status;
--- 2.6.9-rc3-mm2/fs/lockd/svc.c.old 2004-10-04 09:32:20.417019000 -0400
+++ 2.6.9-rc3-mm2/fs/lockd/svc.c 2004-10-04 11:27:54.868205000 -0400
@@ -278,6 +278,8 @@ void
lockd_down(void)
{
static int warned;
+ wait_queue_t __wait;
+ int retries=0;
down(&nlmsvc_sema);
if (nlmsvc_users) {
@@ -294,20 +296,33 @@ lockd_down(void)
warned = 0;
kill_proc(nlmsvc_pid, SIGKILL, 1);
+
+ init_waitqueue_entry(&__wait, current);
+ add_wait_queue(&lockd_exit, &__wait);
+
/*
* Wait for the lockd process to exit, but since we're holding
* the lockd semaphore, we can't wait around forever ...
*/
clear_thread_flag(TIF_SIGPENDING);
- interruptible_sleep_on_timeout(&lockd_exit, HZ);
- if (nlmsvc_pid) {
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ while (nlmsvc_pid) {
+
+ schedule_timeout(HZ);
+ if (retries++ < 3)
+ continue;
+
printk(KERN_WARNING
"lockd_down: lockd failed to exit, clearing pid\n");
nlmsvc_pid = 0;
}
+ set_current_state(TASK_RUNNING);
+ remove_wait_queue(&lockd_exit, &__wait);
+
spin_lock_irq(¤t->sighand->siglock);
recalc_sigpending();
spin_unlock_irq(¤t->sighand->siglock);
+
out:
up(&nlmsvc_sema);
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] lockd
2004-10-04 16:24 [PATCH] lockd Steve Dickson
@ 2004-10-04 17:50 ` Trond Myklebust
2004-10-04 19:25 ` Steve Dickson
2004-10-04 18:01 ` Trond Myklebust
1 sibling, 1 reply; 6+ messages in thread
From: Trond Myklebust @ 2004-10-04 17:50 UTC (permalink / raw)
To: Steve Dickson; +Cc: nfs, linux-kernel
På må , 04/10/2004 klokka 18:24, skreiv Steve Dickson:
> Hey Neil,
Hey! This is the client side NLM code... 8-)
> clear_thread_flag(TIF_SIGPENDING);
> - interruptible_sleep_on_timeout(&lockd_exit, HZ);
> - if (nlmsvc_pid) {
> + set_current_state(TASK_UNINTERRUPTIBLE);
Nope. Those clearly are not the same.
Note that you probably also want to move the call to
set_current_state(TASK_INTERRUPTIBLE) inside the loop. In that case you
can also remove the call to set_current_state(TASK_RUNNING) ('cos
schedule_timeout() will do that for you).
Also, why aren't you using the more standard DECLARE_WAITQUEUE(__wait)?
Cheers,
Trond
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] lockd
2004-10-04 16:24 [PATCH] lockd Steve Dickson
2004-10-04 17:50 ` Trond Myklebust
@ 2004-10-04 18:01 ` Trond Myklebust
2004-10-04 18:13 ` Arjan van de Ven
1 sibling, 1 reply; 6+ messages in thread
From: Trond Myklebust @ 2004-10-04 18:01 UTC (permalink / raw)
To: Steve Dickson; +Cc: nfs, linux-kernel
På må , 04/10/2004 klokka 18:24, skreiv Steve Dickson:
> Hey Neil,
>
> Attached is a patch that fixes some potential SMP races
> in the lockd code that were identified by the SLEEP_ON_BKLCHECK
> that was (at one time) in the -mm tree...
Just for the record: the "SMP race condition" argument given here is
completely bogus. sleep_on_* is quite safe to use when the SMP races are
being handled using the BKL, as is the case here.
That said, I agree that the patch is of interest given the long term
goal of removing the BKL completely. Perhaps you could therefore also
amend your changelog entry text to reflect this motive?
Cheers,
Trond
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] lockd
2004-10-04 18:01 ` Trond Myklebust
@ 2004-10-04 18:13 ` Arjan van de Ven
2004-10-04 18:22 ` Trond Myklebust
0 siblings, 1 reply; 6+ messages in thread
From: Arjan van de Ven @ 2004-10-04 18:13 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Steve Dickson, nfs, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
On Mon, 2004-10-04 at 20:01, Trond Myklebust wrote:
> På må , 04/10/2004 klokka 18:24, skreiv Steve Dickson:
> > Hey Neil,
> >
> > Attached is a patch that fixes some potential SMP races
> > in the lockd code that were identified by the SLEEP_ON_BKLCHECK
> > that was (at one time) in the -mm tree...
>
> Just for the record: the "SMP race condition" argument given here is
> completely bogus. sleep_on_* is quite safe to use when the SMP races are
> being handled using the BKL, as is the case here.
actually this triggered because there was NO bkl... if you hold the bkl
the warning doesn't trigger.....
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] lockd
2004-10-04 18:13 ` Arjan van de Ven
@ 2004-10-04 18:22 ` Trond Myklebust
0 siblings, 0 replies; 6+ messages in thread
From: Trond Myklebust @ 2004-10-04 18:22 UTC (permalink / raw)
To: arjanv; +Cc: Steve Dickson, nfs, linux-kernel
På må , 04/10/2004 klokka 20:13, skreiv Arjan van de Ven:
> actually this triggered because there was NO bkl... if you hold the bkl
> the warning doesn't trigger.....
Then the fix is downright wrong.
We *must* be holding the BKL upon entry to nlmclnt_lock(). All sorts of
other things depend on it.
Cheers,
Trond
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] lockd
2004-10-04 17:50 ` Trond Myklebust
@ 2004-10-04 19:25 ` Steve Dickson
0 siblings, 0 replies; 6+ messages in thread
From: Steve Dickson @ 2004-10-04 19:25 UTC (permalink / raw)
To: Trond Myklebust; +Cc: nfs, linux-kernel
Trond Myklebust wrote:
>På må , 04/10/2004 klokka 18:24, skreiv Steve Dickson:
>
>
>
>>Hey Neil,
>>
>>
>
>Hey! This is the client side NLM code... 8-)
>
>
Sorry buddy.... I'm having one of those days!!!! :-\
>Note that you probably also want to move the call to
>set_current_state(TASK_INTERRUPTIBLE) inside the loop. In that case you
>can also remove the call to set_current_state(TASK_RUNNING) ('cos
>schedule_timeout() will do that for you).
>
>
>
Ok...
>Also, why aren't you using the more standard DECLARE_WAITQUEUE(__wait)?
>
>
I guess I didn't realize that would be a better way to do it... I'll
look into to...
thanks,
SteveD.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-10-04 19:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-04 16:24 [PATCH] lockd Steve Dickson
2004-10-04 17:50 ` Trond Myklebust
2004-10-04 19:25 ` Steve Dickson
2004-10-04 18:01 ` Trond Myklebust
2004-10-04 18:13 ` Arjan van de Ven
2004-10-04 18:22 ` Trond Myklebust
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox