xfs-masters
[Top] [All Lists]

[xfs-masters] [Bug 3118] another crash on my nfs-server

To: xfs-masters@xxxxxxxxxxx
Subject: [xfs-masters] [Bug 3118] another crash on my nfs-server
From: bugme-daemon@xxxxxxxx
Date: Sun, 1 Aug 2004 19:54:23 -0700
Reply-to: xfs-masters@xxxxxxxxxxx
Sender: xfs-masters-bounce@xxxxxxxxxxx
http://bugme.osdl.org/show_bug.cgi?id=3118

sandeen@xxxxxxx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trond.myklebust@xxxxxxxxxx



------- Additional Comments From sandeen@xxxxxxx  2004-08-01 19:54 -------
I'm going to go with "it's a stack problem."

Trond - cc'ing you, please see below....

If I trust the script kaos wrote a while ago, and if we trust the stack
from the oops, here's the stack usage:

0x20 cache_flusharray
0x20 kmem_cache_free
0x10 xfs_finish_reclaim
0x8 vn_reclaim
0x44 vn_purge
0x4c xfs_inactive
0x8 free_block
0x20 free_block
0x28 vn_remove
0x8 linvfs_clear_inode
0x4 clear_inode
0xc dispose_list
0x14 prune_icache
0x4 shrink_icache_memory
0x34 shrink_slab
0x2c try_to_free_pages
0x38 __alloc_pages
0xac xfs_da_do_buf
0x8 __get_free_pages
0x4 kmem_getpages
0x18 cache_grow
0x20 cache_alloc_refill
0x10 kmem_cache_alloc
0xc kmem_zone_alloc
0x50 xfs_dir2_leaf_lookup_int
0x14 kmem_zone_zalloc
0x2c xfs_iread
0x4c xfs_iget_core
0x38 xfs_iget
0x2c xfs_dir_lookup_int
0x2c xfs_lookup
0x24 linvfs_lookup
0x18 __lookup_hash
0x18 lookup_one_len
0x18 compose_entry_fh
0x214 encode_entry
0x70 linvfs_readdir
0x10 permission
0x8 open_private_file
0x18 vfs_readdir
0xb4 nfsd_readdir
0x54 svcauth_unix_accept
0x24 nfsd3_proc_readdirplus
0xc nfs3svc_decode_readdirplusargs
0xc nfsd_dispatch
0x14 svc_authenticate
0x3c svc_process
0x2c nfsd
0x2c nfsd

If I added this up right, it's around 7k of stack...  Even allowing for
incorrect entries or sizes in there, it's a very long stack.

Note that encode_entry is using 0x213 (532 decimal), or > 25% of your 4k stack
in a single function.  Due in large part to the struct svc_fh plopped in the
middle of the (nfs) function.

nfsd_readdir is also taking 180 bytes off the stack...

On the xfs side, xfs_da_do_buf is using 172 bytes, linvfs_readdir is using 
112...

Those seem to be the big hitters.

If this is a stack issue, not sure where to file the "bug" - or if it even
is one.  I'm not a big fan of 4KSTACKS :)

-Eric Sandeen

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

<Prev in Thread] Current Thread [Next in Thread>