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
next prev 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