public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Vladimir Serov <vserov@infratel.com>
Cc: trond.myklebust@fys.uio.no, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] nfs client stuck in D state in linux 2.4.17 - 2.4.21-pre5
Date: Wed, 21 May 2003 10:29:23 +0100	[thread overview]
Message-ID: <20030521102923.B17709@flint.arm.linux.org.uk> (raw)
In-Reply-To: <3EC8DA1B.50304@infratel.com>; from vserov@infratel.com on Mon, May 19, 2003 at 05:20:27PM +0400

On Mon, May 19, 2003 at 05:20:27PM +0400, Vladimir Serov wrote:
> My current kernel is 2.4.21-pre6 based with patches from 2.4.19-rmk7 
> applied (well partially, except ide and pci cause i don't have them, 
> board is mostly brutus). I'm using HARD mounted nfs
> volume now !!! The tail of dmesg is following.

Looking back on stuff which happened a long time ago, there's a
possibility that there's an ordering issue with set_current_state.

Please note that this is affects _all_ 2.4 architectures.

I think this was discussed about 6 months ago, so I'm surprised this
hasn't made it into the 2.4.2x kernel (or no one else has seen the
problem.)

Please note that since I don't track 2.4 kernels currently, I've no
idea whether 2.4.21-pre/rc has this fix.  (This means if Marcelo
drops or ignores the fix, it won't get re-sent.)  Certainly gcc 3
requires this patch.  I've not heard of gcc 2.95.x tripping over
this problem though.

The problem area is:

#define __set_task_state(tsk, state_value)              \
        do { (tsk)->state = (state_value); } while (0)
#ifdef CONFIG_SMP
#define set_task_state(tsk, state_value)                \
        set_mb((tsk)->state, (state_value))
#else
#define set_task_state(tsk, state_value)                \
        __set_task_state((tsk), (state_value))
#endif

#define __set_current_state(state_value)                        \
        do { current->state = (state_value); } while (0)
#ifdef CONFIG_SMP
#define set_current_state(state_value)          \
        set_mb(current->state, (state_value))
#else
#define set_current_state(state_value)          \
        __set_current_state(state_value)
#endif

As they currently stand, there is no guarantee that the assignment to
"->state" occurs before the condition in wait_event is processed.

The attached patch should fix your problem.  It should be applied to
2.4.2x.  All architectures which do not provide set_mb() need to be
fixed.

--- ref/include/linux/sched.h	Wed Mar 19 15:54:45 2003
+++ linux/include/linux/sched.h	Wed May 14 09:45:31 2003
@@ -94,23 +94,13 @@
 
 #define __set_task_state(tsk, state_value)		\
 	do { (tsk)->state = (state_value); } while (0)
-#ifdef CONFIG_SMP
 #define set_task_state(tsk, state_value)		\
 	set_mb((tsk)->state, (state_value))
-#else
-#define set_task_state(tsk, state_value)		\
-	__set_task_state((tsk), (state_value))
-#endif
 
 #define __set_current_state(state_value)			\
 	do { current->state = (state_value); } while (0)
-#ifdef CONFIG_SMP
 #define set_current_state(state_value)		\
 	set_mb(current->state, (state_value))
-#else
-#define set_current_state(state_value)		\
-	__set_current_state(state_value)
-#endif
 
 /*
  * Scheduling policies
--- ref/include/asm-arm/system.h	Wed Sep 11 17:30:52 2002
+++ linux/include/asm-arm/system.h	Wed May 14 09:46:20 2003
@@ -46,6 +46,8 @@
 #define mb() __asm__ __volatile__ ("" : : : "memory")
 #define rmb() mb()
 #define wmb() mb()
+#define set_mb(var, value)  do { var = value; mb(); } while (0)
+#define set_wmb(var, value) do { var = value; wmb(); } while (0)
 #define nop() __asm__ __volatile__("mov\tr0,r0\t@ nop\n\t");
 
 #define prepare_to_switch()    do { } while(0)


-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

  parent reply	other threads:[~2003-05-21  9:16 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-18 14:57 kernel nfsd Stephan von Krawczynski
2003-03-18 15:31 ` Trond Myklebust
2003-03-18 15:42   ` Stephan von Krawczynski
2003-03-18 16:07     ` Oleg Drokin
2003-03-18 16:28       ` Stephan von Krawczynski
2003-03-18 16:41         ` Stephan von Krawczynski
2003-03-18 16:46           ` Stephan von Krawczynski
2003-03-18 17:28       ` Bernd Schubert
2003-03-19  6:43         ` Oleg Drokin
2003-03-19 11:51           ` Bernd Schubert
2003-03-18 22:09     ` Neil Brown
2003-03-19 11:01       ` Stephan von Krawczynski
2003-03-20 16:22 ` [BUG] nfs client stuck in D state in linux 2.4.17 - 2.4.21-pre5 Vladimir Serov
2003-03-20 16:29   ` Trond Myklebust
2003-03-21  9:31     ` Vladimir Serov
2003-03-21 11:16       ` Trond Myklebust
     [not found]         ` <3E7B0051.8060603@infratel.com>
     [not found]           ` <15995.578.341176.325238@charged.uio.no>
     [not found]             ` <3E7B10DF.5070005@infratel.com>
     [not found]               ` <15995.5996.446164.746224@charged.uio.no>
     [not found]                 ` <3E7B1DF9.2090401@infratel.com>
     [not found]                   ` <15995.10797.983569.410234@charged.uio.no>
2003-05-07 14:42                     ` Vladimir Serov
2003-05-07 15:06                       ` Trond Myklebust
2003-05-08 13:15                         ` Vladimir Serov
2003-05-13 21:11                           ` Trond Myklebust
2003-05-19 13:20                     ` Vladimir Serov
2003-05-20  2:09                       ` Trond Myklebust
2003-05-20 12:07                         ` Vladimir Serov
2003-05-20 12:34                           ` Trond Myklebust
2003-05-21  9:29                       ` Russell King [this message]
2003-05-21  9:43                         ` Russell King
2003-05-21 14:58                           ` Nicolas Pitre
2003-05-21 13:36                         ` Vladimir Serov

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=20030521102923.B17709@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    --cc=vserov@infratel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox