All of lore.kernel.org
 help / color / mirror / Atom feed
From: john cooper <john.cooper@timesys.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Oleg Nesterov <oleg@tv-sign.ru>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Olaf Kirch <okir@suse.de>, john cooper <john.cooper@timesys.com>
Subject: Re: RT and Cascade interrupts
Date: Mon, 30 May 2005 17:32:40 -0400	[thread overview]
Message-ID: <429B8678.1000706@timesys.com> (raw)
In-Reply-To: <1117352410.10788.29.camel@lade.trondhjem.org>

Trond Myklebust wrote:

> I've appended a patch that
> should check for strict compliance of the above rules. Could you try it
> out and see if it triggers any Oopses?

Yes, the assert in rpc_delete_timer() occurs just before
the cascade list corruption.  This is consistent with
what I have seen.  ie: the timer in a released rpc_task
is still active.

BTW, the patch from Oleg is relative to 2.6.12 and didn't
look to apply to the 2.6.11-derived base with which I'm
working (the RPC_IS_QUEUED() test at the head of rpc_delete_timer()
does not exist).  In any case the relocation of restarted: in
__rpc_execute() did not influence the failure.  I'd like to
move to a 2.6.12-based -RT patch however I'm dealing with
"code in the pipe" and unfortunately don't have that option.

Sorry I'm just responding new.  We're in the middle of a
long holiday weekend.  I will have more time come tomorrow
to analyze this further.

-john


> ------------------------------------------------------------------------
> 
>  sched.c |    8 ++++++++
>  1 files changed, 8 insertions(+)
> 
> Index: linux-2.6.12-rc4/net/sunrpc/sched.c
> ===================================================================
> --- linux-2.6.12-rc4.orig/net/sunrpc/sched.c
> +++ linux-2.6.12-rc4/net/sunrpc/sched.c
> @@ -135,6 +135,8 @@ __rpc_add_timer(struct rpc_task *task, r
>  static void
>  rpc_delete_timer(struct rpc_task *task)
>  {
> +	BUG_ON(test_bit(RPC_TASK_HAS_TIMER, &task->tk_runstate) == 0 &&
> +			timer_pending(&task->tk_timer));
>  	if (RPC_IS_QUEUED(task))
>  		return;
>  	if (test_and_clear_bit(RPC_TASK_HAS_TIMER, &task->tk_runstate)) {
> @@ -337,6 +339,8 @@ static void __rpc_sleep_on(struct rpc_wa
>  void rpc_sleep_on(struct rpc_wait_queue *q, struct rpc_task *task,
>  				rpc_action action, rpc_action timer)
>  {
> +	BUG_ON(test_bit(RPC_TASK_HAS_TIMER, &task->tk_runstate) != 0 ||
> +			timer_pending(&task->tk_timer));
>  	/*
>  	 * Protect the queue operations.
>  	 */
> @@ -594,6 +598,8 @@ static int __rpc_execute(struct rpc_task
>  			unlock_kernel();
>  		}
>  
> +		BUG_ON(test_bit(RPC_TASK_HAS_TIMER, &task->tk_runstate) != 0 ||
> +			timer_pending(&task->tk_timer));
>  		/*
>  		 * Perform the next FSM step.
>  		 * tk_action may be NULL when the task has been killed
> @@ -925,6 +931,8 @@ fail:
>  
>  void rpc_run_child(struct rpc_task *task, struct rpc_task *child, rpc_action func)
>  {
> +	BUG_ON(test_bit(RPC_TASK_HAS_TIMER, &task->tk_runstate) != 0 ||
> +			timer_pending(&task->tk_timer));
>  	spin_lock_bh(&childq.lock);
>  	/* N.B. Is it possible for the child to have already finished? */
>  	__rpc_sleep_on(&childq, task, func, NULL);


-- 
john.cooper@timesys.com

  reply	other threads:[~2005-05-30 21:35 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-27 16:47 RT and Cascade interrupts Oleg Nesterov
2005-05-27 23:37 ` john cooper
2005-05-28  8:52   ` Oleg Nesterov
2005-05-28 14:02     ` john cooper
2005-05-28 16:34       ` Oleg Nesterov
2005-05-28 17:48     ` john cooper
2005-05-28 20:35       ` Trond Myklebust
2005-05-29  3:12         ` john cooper
2005-05-29  7:40           ` Trond Myklebust
2005-05-30 21:32             ` john cooper [this message]
2005-05-31 23:09               ` john cooper
2005-06-01 14:22               ` Oleg Nesterov
2005-06-01 18:05                 ` john cooper
2005-06-01 18:31                   ` Trond Myklebust
2005-06-01 19:20                     ` john cooper
2005-06-01 19:46                       ` Trond Myklebust
2005-06-01 20:21                       ` Trond Myklebust
2005-06-01 20:59                         ` john cooper
2005-06-01 22:51                           ` Trond Myklebust
2005-06-01 23:09                             ` Trond Myklebust
2005-06-02  3:31                             ` john cooper
2005-06-02  4:26                               ` Trond Myklebust
2005-06-09 23:17                                 ` George Anzinger
2005-06-09 23:52                                   ` john cooper
2005-05-29 11:31         ` Oleg Nesterov
2005-05-29 13:58           ` Trond Myklebust
2005-05-30 14:50             ` Ingo Molnar
2005-05-28 22:17       ` Trond Myklebust
  -- strict thread matches above, loose matches on Subject: below --
2005-05-12 14:43 Daniel Walker
2005-05-13  7:44 ` Ingo Molnar
2005-05-13 13:12   ` john cooper
2005-05-24 16:32     ` john cooper
2005-05-27  7:25       ` Ingo Molnar
2005-05-27 13:53         ` john cooper

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=429B8678.1000706@timesys.com \
    --to=john.cooper@timesys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=okir@suse.de \
    --cc=oleg@tv-sign.ru \
    --cc=trond.myklebust@fys.uio.no \
    /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.