Bugzilla – Bug 335
XFS Oops with 2.6.7-rc3
Last modified: 2004-06-15 11:41:18 CDT
during copying with MidnightCommander (curses based filemanager) an Oops showed up on the console, but the machine is still working. no lockups, i can still access/umount/mount the fs. xfs_check did not reveal any errors. the machine is a p3/500, debian/unstable (xfsprogs 2.6.11-1), glibc 2.3.2.ds1-12, mount/umount utils from loop-aes-utils package, if this matters. more info available, of course. mc: page allocation failure. order:5, mode:0x50 ~ [<c0130556>] __alloc_pages+0x2d6/0x320 ~ [<c01305bf>] __get_free_pages+0x1f/0x40 ~ [<c0133669>] kmem_getpages+0x19/0xc0 ~ [<c0134188>] cache_grow+0x98/0x1f0 ~ [<c0134452>] cache_alloc_refill+0x172/0x220 ~ [<c01dc3e4>] xfs_log_release_iclog+0x14/0x50 ~ [<c013499c>] __kmalloc+0x6c/0x80 ~ [<c01d47fb>] xfs_iread_extents+0x6b/0x160 ~ [<c01b11ea>] xfs_bunmapi+0xdfa/0xe80 ~ [<c01e7625>] xfs_mod_incore_sb_batch+0x45/0xb0 ~ [<c01ea974>] xfs_trans_unreserve_and_mod_sb+0x174/0x180 ~ [<c01f9392>] pagebuf_rele+0xf2/0x100 ~ [<c01ecc09>] xfs_trans_unlock_chunk+0x99/0xf0 ~ [<c01dcc19>] xlog_assign_tail_lsn+0x19/0x70 ~ [<c01df05a>] xlog_state_release_iclog+0x1a/0xd0 ~ [<c01dc3e4>] xfs_log_release_iclog+0x14/0x50 ~ [<c01de7d2>] xlog_grant_log_space+0x122/0x370 ~ [<c01d50c8>] xfs_itruncate_finish+0x1d8/0x3b0 ~ [<c01ec5ab>] xfs_trans_ijoin+0x2b/0x80 ~ [<c01f1d75>] xfs_inactive+0x435/0x490 ~ [<c0200688>] vn_rele+0xd8/0xf0 ~ [<c01ff17f>] linvfs_clear_inode+0xf/0x20 ~ [<c015e414>] clear_inode+0x94/0xa0 ~ [<c015f16c>] generic_delete_inode+0xcc/0xf0 ~ [<c015f343>] iput+0x53/0x70 ~ [<c0155e04>] sys_unlink+0xf4/0x120 ~ [<c014700f>] filp_close+0x4f/0x80 ~ [<c0103d0b>] syscall_call+0x7/0xb Unable to handle kernel NULL pointer dereference at virtual address 00000000 ~ printing eip: c01aed85 *pde = 00000000 Oops: 0002 [#1] PREEMPT Modules linked in: loop_twofish loop ipt_REJECT ipt_state ipt_multiport ipt_MASQUERADE ip_nat_ftp iptable_nat ip_conntrack_ftp ip_conntrack iptable_filter ip_tables nfsd exportfs lockd sunrpc ppp_deflate zlib_deflate zlib_inflate bsd_comp parport_pc lp parport ppp_async ipv6 ppp_generic slhc 8250 serial_core 3c59x rtc CPU: 0 EIP: 0060:[<c01aed85>] Not tainted EFLAGS: 00010202 (2.6.7-rc3) EIP is at xfs_bmap_read_extents+0x2f5/0x490 eax: 540f0000 ebx: 007d2635 ecx: 00000000 edx: e01b60aa esi: c6e56018 edi: 00000000 ebp: 00000000 esp: c17b5cf4 ds: 007b es: 007b ss: 0068 Process mc (pid: 27049, threadinfo=c17b4000 task=c6e2edd0) Stack: 00000000 c17b5d4c 00000002 00000050 cfffce60 00000000 f1a77b00 000000a4 ~ 000000a4 000000a4 007d2635 00000000 cf81a040 00001066 c4795808 cf856c00 ~ 00000000 ce225aa0 00000001 c6e56000 ce225a50 c5fe9a64 cf81a040 ce225aa0 Call Trace: ~ [<c01d481b>] xfs_iread_extents+0x8b/0x160 ~ [<c01b11ea>] xfs_bunmapi+0xdfa/0xe80 ~ [<c01e7625>] xfs_mod_incore_sb_batch+0x45/0xb0 ~ [<c01ea974>] xfs_trans_unreserve_and_mod_sb+0x174/0x180 ~ [<c01f9392>] pagebuf_rele+0xf2/0x100 ~ [<c01ecc09>] xfs_trans_unlock_chunk+0x99/0xf0 ~ [<c01dcc19>] xlog_assign_tail_lsn+0x19/0x70 ~ [<c01df05a>] xlog_state_release_iclog+0x1a/0xd0 ~ [<c01dc3e4>] xfs_log_release_iclog+0x14/0x50 ~ [<c01de7d2>] xlog_grant_log_space+0x122/0x370 ~ [<c01d50c8>] xfs_itruncate_finish+0x1d8/0x3b0 ~ [<c01ec5ab>] xfs_trans_ijoin+0x2b/0x80 ~ [<c01f1d75>] xfs_inactive+0x435/0x490 ~ [<c0200688>] vn_rele+0xd8/0xf0 ~ [<c01ff17f>] linvfs_clear_inode+0xf/0x20 ~ [<c015e414>] clear_inode+0x94/0xa0 ~ [<c015f16c>] generic_delete_inode+0xcc/0xf0 ~ [<c015f343>] iput+0x53/0x70 ~ [<c0155e04>] sys_unlink+0xf4/0x120 ~ [<c014700f>] filp_close+0x4f/0x80 ~ [<c0103d0b>] syscall_call+0x7/0xb Code: 89 4d 00 83 c6 10 89 c1 89 7d 04 89 d7 0f c9 0f cf 87 cf 89
This is a failure on XFS's part to handle low memory situations gracefully. There's a patch coming shortly that should increase our resilience there, and we'll get that merged into the mainline kernels as soon as we can. cheers.
The allocator rework that should fix this is in now.