* Deadlock/crash in 2.6.32.12 when copying large files
@ 2010-05-25 22:26 Leszek Urbanski
2010-05-25 22:43 ` Lukas Hejtmanek
0 siblings, 1 reply; 2+ messages in thread
From: Leszek Urbanski @ 2010-05-25 22:26 UTC (permalink / raw)
To: linux-nfs
Hi,
I've hit https://bugzilla.kernel.org/show_bug.cgi?id=15578 again with
2.6.32.12 on amd64.
I can reproduce it every time when copying large (>2G) files over NFS.
The call trace is at https://bugzilla.kernel.org/attachment.cgi?id=26519
Needless to say it results in a system crash (kswapd deadlock, network stack
failure because of memory allocation failure for SKBs, etc.).
Trond Myklebust closed this bug a while ago, but apparently it's not completely
fixed and needs to be re-opened.
--
Leszek Urbanski
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Deadlock/crash in 2.6.32.12 when copying large files
2010-05-25 22:26 Deadlock/crash in 2.6.32.12 when copying large files Leszek Urbanski
@ 2010-05-25 22:43 ` Lukas Hejtmanek
0 siblings, 0 replies; 2+ messages in thread
From: Lukas Hejtmanek @ 2010-05-25 22:43 UTC (permalink / raw)
To: Leszek Urbanski; +Cc: linux-nfs
Hi,
On Wed, May 26, 2010 at 12:26:57AM +0200, Leszek Urbanski wrote:
> I've hit https://bugzilla.kernel.org/show_bug.cgi?id=15578 again with
> 2.6.32.12 on amd64.
>
> I can reproduce it every time when copying large (>2G) files over NFS.
> The call trace is at https://bugzilla.kernel.org/attachment.cgi?id=26519
>
> Needless to say it results in a system crash (kswapd deadlock, network stack
> failure because of memory allocation failure for SKBs, etc.).
>
> Trond Myklebust closed this bug a while ago, but apparently it's not completely
> fixed and needs to be re-opened.
You could try this workaround, it works for me. Cherry picked from 2.6.34
vanila.
commit 3d7b08945e54a3a5358d5890240619a013cb7388
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Apr 22 15:35:55 2010 -0400
SUNRPC: Fix a bug in rpcauth_prune_expired
Don't want to evict a credential if cred->cr_expire == jiffies, since that
means that it was just placed on the cred_unused list. We therefore need to
use time_in_range() rather than time_in_range_open().
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
index f394fc1..95afe79 100644
--- a/net/sunrpc/auth.c
+++ b/net/sunrpc/auth.c
@@ -237,7 +237,7 @@ rpcauth_prune_expired(struct list_head *free, int
nr_to_scan)
list_for_each_entry_safe(cred, next, &cred_unused, cr_lru) {
/* Enforce a 60 second garbage collection moratorium */
- if (time_in_range_open(cred->cr_expire, expired, jiffies) &&
+ if (time_in_range(cred->cr_expire, expired, jiffies) &&
test_bit(RPCAUTH_CRED_HASHED, &cred->cr_flags) != 0)
continue;
--
Lukáš Hejtmánek
^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-05-25 22:43 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-25 22:26 Deadlock/crash in 2.6.32.12 when copying large files Leszek Urbanski
2010-05-25 22:43 ` Lukas Hejtmanek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).