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 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.