All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Waychison <michael.waychison@sun.com>
To: Ian Kent <raven@themaw.net>
Cc: Arjan van de Ven <arjanv@redhat.com>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Maneesh Soni <maneesh@in.ibm.com>,
	autofs mailing list <autofs@linux.kernel.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [PATCH] autofs4 deadlock during expire - kernel 2.6
Date: Wed, 24 Sep 2003 11:54:37 -0400	[thread overview]
Message-ID: <3F71BE3D.6030501@sun.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0309242136080.6713-100000@raven.themaw.net>

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

Ian Kent wrote:
> On Wed, 24 Sep 2003, Arjan van de Ven wrote:
> 
> 
>>On Wed, 2003-09-24 at 15:01, Ian Kent wrote:
>>
>>>This is a corrected patch for the autofs4 daedlock problem I posted about 
>>>@@ -206,6 +207,11 @@
>>> 
>>> 		interruptible_sleep_on(&wq->queue);
>>> 
>>>+		if (waitqueue_active(&wq->queue) && current != wq->owner) {
>>>+			set_current_state(TASK_INTERRUPTIBLE);
>>>+			schedule_timeout(wq->wait_ctr * (HZ/10));
>>>+		}
>>>+
>>
>>this really really looks like you're trying to pamper over a bug by
>>changing the timing somewhere instead of fixing it...
> 
> 
> Agreed.
> 
> 
>>also are you sure the deadlock isn't because of the racey use of
>>interruptible_sleep_on ?
>>

I think the deadlock itself needs to be properly identified.

Could you explain where the deadlock is actually occuring?  I briefed 
over the automount 4 code as well as autofs4 and I don't see the 
deadlock.  The 'owner' in the case of an expiry will be a child process 
of the daemon, within a call to ioctl(EXPIRE_MULTI), correct?  Having it 
be released from the waitqueue first should not affect flow of execution 
and released from deadlock.

I don't see how having it wake up before before any other racing 
processes solves anything.

I think Arjan is right in that the race is do to the nautilus process 
entering the sleep_on after the a call to wake_up(&wq->queue).  I don't 
know if a change to using a workqueue is best..   how about refactoring 
that chunk of code to use wait_event_interruptible on the queue, which 
should be clear of any waitqueue/sleep_on races.

> 
> 
> OK so maybe I should have suggestions instead of comments.
> 
> Please elaborate.
> 

How about you try out this quick patch I threw together.

Mike Waychison

[-- Attachment #2: autofs4_wait_event.patch --]
[-- Type: text/plain, Size: 430 bytes --]

===== waitq.c 1.6 vs edited =====
--- 1.6/fs/autofs4/waitq.c	Fri Feb  7 12:25:20 2003
+++ edited/waitq.c	Wed Sep 24 15:48:30 2003
@@ -204,7 +204,7 @@
 		recalc_sigpending();
 		spin_unlock_irqrestore(&current->sighand->siglock, irqflags);
 
-		interruptible_sleep_on(&wq->queue);
+		wait_event_interruptible(wq->queue, wq->name == NULL);
 
 		spin_lock_irqsave(&current->sighand->siglock, irqflags);
 		current->blocked = oldset;

  parent reply	other threads:[~2003-09-24 15:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-24 13:01 [PATCH] autofs4 deadlock during expire - kernel 2.6 Ian Kent
2003-09-24 13:09 ` Arjan van de Ven
2003-09-24 13:38   ` Ian Kent
2003-09-24 13:57     ` Arjan van de Ven
2003-09-24 14:46       ` Ian Kent
2003-09-24 15:11         ` Arjan van de Ven
2003-09-24 15:54     ` Mike Waychison [this message]
2003-09-25  1:44       ` Ian Kent
2003-09-25  1:44         ` Ian Kent
2003-09-25 11:59         ` Ian Kent
2003-09-25 11:59           ` [autofs] " Ian Kent
  -- strict thread matches above, loose matches on Subject: below --
2003-09-23 13:47 Ian Kent
2003-09-23 15:31 ` Mike Waychison
2003-09-23 16:24   ` Ian Kent

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=3F71BE3D.6030501@sun.com \
    --to=michael.waychison@sun.com \
    --cc=arjanv@redhat.com \
    --cc=autofs@linux.kernel.org \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maneesh@in.ibm.com \
    --cc=raven@themaw.net \
    /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.