[2.6.4] Bad swap file entry, then kernel BUG at mm/shmem.c:475
And, occasional oopses with 2.6.4, and 2.4.24-1.
I installed Debian (sarge) a few weeks ago, and it came with
kernel 2.4.24-1. It was my first time with Debian, so I was mostly
poking around with the Debian-specific management tools. The kernel
oopsed a few times, but since I don't have any baseline of what to
expect from Debian binary kernels, I decided to get a vanilla 2.6.4
for myself.
It's been a couple of weeks ago now since I compiled 2.6.4, and
I've had probably had oopses or BUGs every day or so since then.
Twice, it oopsed during bootup, but usually I'm running X, and the
symptom is simply a hard lockup.
I've been pulling the oopses out of the logs and looking for
patterns, but every oops seems so different. With so much variety of
oopses, (plus the fact that 2.4.24-1 had oopsed), I began to suspect
bad RAM, even though the machine has served me well for several years,
and I haven't found evidence of off-by-bit errors. However, 2 days
running memtest86 with all tests, gave no errors. (BTW, does anyone
have a suggestion of a more rigorous general hardware stress-test for
detecting flakiness?) If my hardware is bad it's pretty intermittent
(I can go days with no problem) and doesn't seem to be as stressed by
other OSes. I'd be reassured in my investigation if someone could
tell me that at least one of my oopses is definitely _not_ bad
hardware.
I don't see the common trait among the oopses, but I'm pretty new
to this type of search, so I thought I would post (down below) just a
couple of them (just ask if you want more) and see if anyone can point
me in the right direction. I realize that if it's not my hardware,
then the oopses from 2.4.24-1 and 2.6.4 are probably unrelated and
don't belong in the same post, but just in case...
I also realize 2.6.4 isn't the bleeding edge newest, but I didn't
see any csets since then that looked like they'd fix my problems. I'm
willing to test patches, and I can provide any additional info
requested.
Sorry for the long post, and thanks for reading. It's all
cut-n-pastes from here on, with a few interspersed observations.
Please cc me; I'm not subscribed.
Thanks,
Chris Shoemaker
Ok, for starters here's one I call:
[2.6.4] Bad swap file entry, then kernel BUG at mm/shmem.c:475
<snipped a dozen or so more of these swap_free: Bad swap file entry>
swap_free: Bad swap file entry 3c000000
swap_free: Bad swap file entry 100026be
------------[ cut here ]------------
kernel BUG at mm/shmem.c:475!
invalid operand: 0000 [#1]
PREEMPT DEBUG_PAGEALLOC
CPU: 0
EIP: 0060:[shmem_truncate+1225/1904] Not tainted
EFLAGS: 00013282
EIP is at shmem_truncate+0x4c9/0x770
eax: 0000002e ebx: c10757d8 ecx: 06797000 edx: fffffff7
esi: 00000000 edi: cb3c0000 ebp: c67c5e54 esp: c67c5e00
ds: 007b es: 007b ss: 0068
Process XFree86 (pid: 1107, threadinfo=c67c4000 task=c67df9e0)
Stack: c67c5ebc c02bb587 00013540 c67c5ec8 00003286 c2d66d4c 00000000 c67c4000
00000000 00000000 00000000 00080000 00000037 00000000 cb3cddc8 cb3cde3c
406356f9 18145460 cbff99a0 cb3cde3c cb3cddc8 c67c5e84 c01706d0 00000000
Call Trace:
[sock_sendmsg+199/208] sock_sendmsg+0xc7/0xd0
[shmem_delete_inode+688/848] shmem_delete_inode+0x2b0/0x350
[shmem_delete_inode+0/848] shmem_delete_inode+0x0/0x350
[generic_delete_inode+244/816] generic_delete_inode+0xf4/0x330
[filp_dtor+0/400] filp_dtor+0x0/0x190
[iput+86/112] iput+0x56/0x70
[dput+503/1824] dput+0x1f7/0x720
[__fput+186/288] __fput+0xba/0x120
[__fput+194/288] __fput+0xc2/0x120
[unmap_vma+117/128] unmap_vma+0x75/0x80
[unmap_vma_list+26/48] unmap_vma_list+0x1a/0x30
[do_munmap+461/688] do_munmap+0x1cd/0x2b0
[rcu_process_callbacks+405/592] rcu_process_callbacks+0x195/0x250
[timer_interrupt+378/1008] timer_interrupt+0x17a/0x3f0
[sys_shmdt+193/336] sys_shmdt+0xc1/0x150
[tasklet_action+67/112] tasklet_action+0x43/0x70
[sys_ipc+672/736] sys_ipc+0x2a0/0x2e0
[__fput+194/288] __fput+0xc2/0x120
[profile_hook+28/48] profile_hook+0x1c/0x30
[syscall_call+7/11] syscall_call+0x7/0xb
Code: 0f 0b db 01 06 45 34 c0 e9 16 fd ff ff 8b 55 e4 8b 42 5c e8
<6>note: XFree86[1107] exited with preempt_count 1
Debug: sleeping function called from invalid context at include/linux/rwsem.h:43
in_atomic():1, irqs_disabled():0
Call Trace:
[__might_sleep+172/224] __might_sleep+0xac/0xe0
[profile_exit_task+35/96] profile_exit_task+0x23/0x60
[do_exit+117/2480] do_exit+0x75/0x9b0
[die+594/608] die+0x252/0x260
[search_exception_tables+37/48] search_exception_tables+0x25/0x30
[do_invalid_op+0/160] do_invalid_op+0x0/0xa0
[do_invalid_op+154/160] do_invalid_op+0x9a/0xa0
[shmem_truncate+1225/1904] shmem_truncate+0x4c9/0x770
[swap_free+39/80] swap_free+0x27/0x50
[error_code+45/56] error_code+0x2d/0x38
[release_pages+555/928] release_pages+0x22b/0x3a0
[shmem_truncate+1225/1904] shmem_truncate+0x4c9/0x770
[sock_sendmsg+199/208] sock_sendmsg+0xc7/0xd0
[shmem_delete_inode+688/848] shmem_delete_inode+0x2b0/0x350
[shmem_delete_inode+0/848] shmem_delete_inode+0x0/0x350
[generic_delete_inode+244/816] generic_delete_inode+0xf4/0x330
[filp_dtor+0/400] filp_dtor+0x0/0x190
[iput+86/112] iput+0x56/0x70
[dput+503/1824] dput+0x1f7/0x720
[__fput+186/288] __fput+0xba/0x120
[__fput+194/288] __fput+0xc2/0x120
[unmap_vma+117/128] unmap_vma+0x75/0x80
[unmap_vma_list+26/48] unmap_vma_list+0x1a/0x30
[do_munmap+461/688] do_munmap+0x1cd/0x2b0
[rcu_process_callbacks+405/592] rcu_process_callbacks+0x195/0x250
[timer_interrupt+378/1008] timer_interrupt+0x17a/0x3f0
[sys_shmdt+193/336] sys_shmdt+0xc1/0x150
[tasklet_action+67/112] tasklet_action+0x43/0x70
[sys_ipc+672/736] sys_ipc+0x2a0/0x2e0
[__fput+194/288] __fput+0xc2/0x120
[profile_hook+28/48] profile_hook+0x1c/0x30
[syscall_call+7/11] syscall_call+0x7/0xb
bad: scheduling while atomic!
Call Trace:
[schedule+2311/2320] schedule+0x907/0x910
[rwsem_down_read_failed+300/592] rwsem_down_read_failed+0x12c/0x250
[syscall_call+7/11] syscall_call+0x7/0xb
[dump_stack+23/32] dump_stack+0x17/0x20
[.text.lock.exit+107/215] .text.lock.exit+0x6b/0xd7
[die+594/608] die+0x252/0x260
[search_exception_tables+37/48] search_exception_tables+0x25/0x30
[do_invalid_op+0/160] do_invalid_op+0x0/0xa0
[do_invalid_op+154/160] do_invalid_op+0x9a/0xa0
[shmem_truncate+1225/1904] shmem_truncate+0x4c9/0x770
[swap_free+39/80] swap_free+0x27/0x50
[error_code+45/56] error_code+0x2d/0x38
[release_pages+555/928] release_pages+0x22b/0x3a0
[shmem_truncate+1225/1904] shmem_truncate+0x4c9/0x770
[sock_sendmsg+199/208] sock_sendmsg+0xc7/0xd0
[shmem_delete_inode+688/848] shmem_delete_inode+0x2b0/0x350
[shmem_delete_inode+0/848] shmem_delete_inode+0x0/0x350
[generic_delete_inode+244/816] generic_delete_inode+0xf4/0x330
[filp_dtor+0/400] filp_dtor+0x0/0x190
[iput+86/112] iput+0x56/0x70
[dput+503/1824] dput+0x1f7/0x720
[__fput+186/288] __fput+0xba/0x120
[__fput+194/288] __fput+0xc2/0x120
[unmap_vma+117/128] unmap_vma+0x75/0x80
[unmap_vma_list+26/48] unmap_vma_list+0x1a/0x30
[do_munmap+461/688] do_munmap+0x1cd/0x2b0
[rcu_process_callbacks+405/592] rcu_process_callbacks+0x195/0x250
[timer_interrupt+378/1008] timer_interrupt+0x17a/0x3f0
[sys_shmdt+193/336] sys_shmdt+0xc1/0x150
[tasklet_action+67/112] tasklet_action+0x43/0x70
[sys_ipc+672/736] sys_ipc+0x2a0/0x2e0
[__fput+194/288] __fput+0xc2/0x120
[profile_hook+28/48] profile_hook+0x1c/0x30
[syscall_call+7/11] syscall_call+0x7/0xb
swap_free: Bad swap file entry 34000000
swap_free: Bad swap file entry 1800269e
<snipped another BUG at mm/shmem.c:475! immediately following and not
so different from above>
[And here's one from Debian's 2.4.24-1:]
Unable to handle kernel paging request at virtual address cc046080
printing eip:
c012af63
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[kmem_cache_free_one+48/145] Not tainted
EFLAGS: 00010046
eax: 20ffffff ebx: cbffcdc4 ecx: c3e46000 edx: 00000000
esi: 0208001a edi: c3e46a80 ebp: c10a5b1c esp: cbc77f10
ds: 0018 es: 0018 ss: 0018
Process kswapd (pid: 4, stackpage=cbc77000)
Stack: 00000202 c3e46a80 c3e46a80 c012aa00 cbffcdc4 c3e46a80 c3e46a80 c0133b65
cbffcdc4 c3e46a80 c01356da c3e46a80 c3e46a80 00000000 c10a5b1c 0000001b
000001d0 c012b4ba c10a5b1c 000001d0 00000c80 00001cd0 c023c978 00000020
Call Trace:
[kmem_cache_free+17/23] [__put_unused_buffer_head+41/85]
[try_to_free_buffers+94/207] [shrink_cache+450/780] [shrink_caches+46/55]
[try_to_free_pages_zone+67/193] [kswapd_balance_pgdat+74/145]
[kswapd_balance+20/40] [kswapd+148/173] [rest_init+0/39]
[arch_kernel_thread+35/45] [kswapd+0/173]
Code: 89 44 b1 18 8b 51 10 8d 42 ff 85 c0 89 71 14 89 41 10 75 23
<1>Unable to handle kernel paging request at virtual address cc046018
printing eip:
c012af63
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[kmem_cache_free_one+48/145] Not tainted
EFLAGS: 00013046
eax: 20ffffff ebx: cbffcdc4 ecx: c3e46000 edx: 00000000
esi: 02080000 edi: c3e460c0 ebp: c1096d68 esp: c91addf0
ds: 0018 es: 0018 ss: 0018
Process XFree86 (pid: 990, stackpage=c91ad000)
Stack: 00003202 c3e460c0 c3e460c0 c012aa00 cbffcdc4 c3e460c0 c3e460c0 c0133b65
cbffcdc4 c3e460c0 c01356da c3e460c0 c3e460c0 00000000 c1096d68 00000004
000001d2 c012b4ba c1096d68 000001d2 00000c80 00001cfd c023c978 00000020
Call Trace: [kmem_cache_free+17/23] [__put_unused_buffer_head+41/85]
[try_to_free_buffers+94/207] [shrink_cache+450/780] [shrink_caches+46/55]
[try_to_free_pages_zone+67/193] [balance_classzone+65/446]
[__alloc_pages+321/504] [do_anonymous_page+64/214]
[handle_mm_fault+82/183] [do_page_fault+311/1018]
[af_packet:__insmod_af_packet_O/lib/modules/2.4.24-1-386/kernel/net/pa+-1114493/96][restore_sigcontext+268/293] [sys_sigreturn+155/194]
[do_page_fault+0/1018] [error_code+52/60]
Code: 89 44 b1 18 8b 51 10 8d 42 ff 85 c0 89 71 14 89 41 10 75 23
Again, just ask if you want more, they're all special in their own way! :)
Just for completeness, and in case it's relevent, I have also attached
a file containing the following, from the 2.6.4 configuration. Some
stuff (like the module info) would obviously be slightly different in
the 2.4.24-1 configuration (ask if you want that, too):
[7.1.] Software (add the output of the ver_linux script here)
[7.2.] Processor information (from /proc/cpuinfo):
[7.3.] Module information (from /proc/modules):
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
[7.5.] PCI information ('lspci -vvv' as root)
[7.6.] SCSI information (from /proc/scsi/scsi)
[7.7.] My .config
On Friday 02 April 2004 02:27, Chris Shoemaker wrote:
> and I haven't found evidence of off-by-bit errors. However, 2 days
> running memtest86 with all tests, gave no errors. (BTW, does anyone
> have a suggestion of a more rigorous general hardware stress-test for
> detecting flakiness?) If my hardware is bad it's pretty intermittent
cpuburn.
Also try to slightly underclock your hardware,
downgrade DMA mode, etc (although it seems you use SCSI...).
Stop using modules you don't absolutely need.
> Debug: sleeping function called from invalid context at
> include/linux/rwsem.h:43 in_atomic():1, irqs_disabled():0
> bad: scheduling while atomic!
Some of them are not oopses, just debug.
--
vda
On Fri, Apr 02, 2004 at 08:38:09AM +0300, Denis Vlasenko wrote:
> On Friday 02 April 2004 02:27, Chris Shoemaker wrote:
> > and I haven't found evidence of off-by-bit errors. However, 2 days
> > running memtest86 with all tests, gave no errors. (BTW, does anyone
> > have a suggestion of a more rigorous general hardware stress-test for
> > detecting flakiness?) If my hardware is bad it's pretty intermittent
>
> cpuburn.
Thanks for the tip. I ran burnBX, burnP5, and burnMMX overnight. No
problems at all. But at least I'll know about cpuburn next time I want
to test a CPU.
>
> Also try to slightly underclock your hardware,
> downgrade DMA mode, etc (although it seems you use SCSI...).
Actually, the SCSI drives aren't active. root and swap are on a 13GB
Fujitsu IDE drive. That got me thinking though... it seems maybe there
is a common thread to my oopses. I think they tend to happen during
disk i/o. Either I'm loading a program, or closing X or even during
boot-up ( 3 times oopsed during boot now. ) -- all i/o activities.
My disk is using udma2 mode, according to 'hdparm -I'. I guess it's
getting set that way from the BIOS, which is set to Auto for the PIO/DMA
mode. I'll follow your suggestion and try to force it lower in the
BIOS, but first I checked more carefully over the CONFIG options related
to IDE and found some things that maybe shouldn't have been set:
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_IDEDISK_STROKE=y
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_IDE_TASK_IOCTL=y
CONFIG_IDE_TASKFILE_IO=y
CONFIG_BLK_DEV_IDEPNP=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_IDEDMA_ONLYDISK=y
As far as I can tell, I don't really need any of those. So, I
disabled all of the above. I'm running with this new config for a few
hours now. If it oopses, I'll try the lower dma mode.
-Chris
>
> vda
In summary, I'm still getting an oops almost every day, and none of the
following have helped:
- testing for flakiness w/ memtest and cpuburn (no faults)
- reducing dma mode w/ hdparm nor BIOS
- recompiling with conservative CONFIG_(ide_stuff) settings
- decreasing number of loaded modules
[For background, you can refer to my last post of April 3rd.]
The oopses are consistently concurrent with IDE I/O, but I still
don't know if that's symptom or cause. Last week, I noticed the
following oops with such a short call trace, so I disassembled to see
what I could learn. Here's what I found:
The instruction at EIP (8b 50 2c) is mov 0x2c(%eax),%edx marked
below at address 1d3f. It corresponds to the second part of the test
"if (filp->f_op && filp->f_op->flush)". Now, %ebx (0xc36f7f5c) still
contains filp, which is probably valid, since filp->f_error was zero
(still in %esi). %eax (0x46388060) is _supposed_ to contain filp->f_op,
but it seems to actually be causing the page_fault instead.
If I guess that this is a regular inode-backed filp (afterall,
the oops _was_ during disk activity) then f_op would have come from
ext3_{file|dir}_operations, and my ext3 is built-in, not a module. So,
is it reasonable to find filp->f_op so "far" from filp (0x46388060 vs
0xc36f7f5c)? I guessed not, and after poking around the code some more,
I tried:
$ grep 388060 /boot/System.map
c0388060 D ext3_file_operations
AHA! So it _was_ a file, and %eax was supposed to be c0388060.
So how does filp->f_op go from c0388060 to 46388060? 3 RAM bit-errors?
That seems unlikely, especially since memtest86 runs for days with no
problems.
So now I'm looking for something that would corrupt the high
byte of filp->f_op. So far, this has taken me about one week (I'm
slow ;) I wanted to check back in with the list in case I'm on the
wrong track.
Any debugging advice? If you were I, would you keep looking for
more info about this oops, or would you move to another oops? My goal
is to eventually test (or submit) a patch that makes these oopses go
away. Thanks!
- Chris Shoemaker
Here's the oops:
Apr 4 17:16:12 peace kernel: Unable to handle kernel paging request at virtual address 4638808c
Apr 4 17:16:12 peace kernel: printing eip:
Apr 4 17:16:12 peace kernel: c017c46f
Apr 4 17:16:12 peace kernel: *pde = 00000000
Apr 4 17:16:12 peace kernel: Oops: 0000 [#1]
Apr 4 17:16:12 peace kernel: PREEMPT DEBUG_PAGEALLOC
Apr 4 17:16:12 peace kernel: CPU: 0
Apr 4 17:16:12 peace kernel: EIP: 0060:[filp_close+47/128] Not tainted
Apr 4 17:16:12 peace kernel: EFLAGS: 00013206
Apr 4 17:16:12 peace kernel: EIP is at filp_close+0x2f/0x80
Apr 4 17:16:12 peace kernel: eax: 46388060 ebx: c36f7f5c ecx: 089a1950 edx: c5e4ee44
Apr 4 17:16:12 peace kernel: esi: 00000000 edi: c5e4ee44 ebp: c5e31fbc esp: c5e31fac
Apr 4 17:16:12 peace kernel: ds: 007b es: 007b ss: 0068
Apr 4 17:16:12 peace kernel: Process XFree86 (pid: 1124, threadinfo=c5e30000 task=c5e4f9e0)
Apr 4 17:16:12 peace kernel: Stack: c0381664 00000026 089a1950 40187c40 c5e30000 c010a00b 00000026 089a1950
Apr 4 17:16:12 peace kernel: 4018f110 089a1950 40187c40 00000000 00000006 0000007b 0000007b 00000006
Apr 4 17:16:12 peace kernel: 401262f7 00000073 00003286 bffff4b4 0000007b
Apr 4 17:16:12 peace kernel: Call Trace:
Apr 4 17:16:12 peace kernel: [syscall_call+7/11] syscall_call+0x7/0xb
Apr 4 17:16:12 peace kernel:
Apr 4 17:16:12 peace kernel: Code: 8b 50 2c 85 d2 75 2a 89 fa 89 d8 e8 41 bb 02 00 89 d8 89 fa
Here's the output of ksymoops:
ksymoops 2.4.9 on i686 2.6.4. Options used
-v /usr/src/linux-2.6.4/vmlinux (specified)
-K (specified)
-l /proc/modules (default)
-o /lib/modules/2.6.4/ (default)
-m /boot/System.map-2.6.4 (default)
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Apr 4 17:16:12 peace kernel: Unable to handle kernel paging request at virtual address 4638808c
Apr 4 17:16:12 peace kernel: c017c46f
Apr 4 17:16:12 peace kernel: *pde = 00000000
Apr 4 17:16:12 peace kernel: Oops: 0000 [#1]
Apr 4 17:16:12 peace kernel: CPU: 0
Apr 4 17:16:12 peace kernel: EIP: 0060:[filp_close+47/128] Not tainted
Apr 4 17:16:12 peace kernel: EFLAGS: 00013206
Apr 4 17:16:12 peace kernel: eax: 46388060 ebx: c36f7f5c ecx: 089a1950 edx: c5e4ee44
Apr 4 17:16:12 peace kernel: esi: 00000000 edi: c5e4ee44 ebp: c5e31fbc esp: c5e31fac
Apr 4 17:16:12 peace kernel: ds: 007b es: 007b ss: 0068
Apr 4 17:16:12 peace kernel: Stack: c0381664 00000026 089a1950 40187c40 c5e30000 c010a00b 00000026 089a1950
Apr 4 17:16:12 peace kernel: 4018f110 089a1950 40187c40 00000000 00000006 0000007b 0000007b 00000006
Apr 4 17:16:12 peace kernel: 401262f7 00000073 00003286 bffff4b4 0000007b
Apr 4 17:16:12 peace kernel: Call Trace:
Apr 4 17:16:12 peace kernel: Code: 8b 50 2c 85 d2 75 2a 89 fa 89 d8 e8 41 bb 02 00 89 d8 89 fa
Using defaults from ksymoops -t elf32-i386 -a i386
>>eax; 46388060 <__crc_skb_ip_make_writable+92257/186203>
>>ebx; c36f7f5c <__crc_filp_close+1e1a27/317acd>
>>ecx; 089a1950 <__crc_vlan_ioctl_set+3efe4f/56407d>
>>edx; c5e4ee44 <__crc_xfrm_policy_get_afinfo+fedcb/2d3b6a>
>>edi; c5e4ee44 <__crc_xfrm_policy_get_afinfo+fedcb/2d3b6a>
>>ebp; c5e31fbc <__crc_xfrm_policy_get_afinfo+e1f43/2d3b6a>
>>esp; c5e31fac <__crc_xfrm_policy_get_afinfo+e1f33/2d3b6a>
Code; 00000000 Before first symbol
00000000 <_EIP>:
Code; 00000000 Before first symbol
0: 8b 50 2c mov 0x2c(%eax),%edx
Code; 00000003 Before first symbol
3: 85 d2 test %edx,%edx
Code; 00000005 Before first symbol
5: 75 2a jne 31 <_EIP+0x31>
Code; 00000007 Before first symbol
7: 89 fa mov %edi,%edx
Code; 00000009 Before first symbol
9: 89 d8 mov %ebx,%eax
Code; 0000000b Before first symbol
b: e8 41 bb 02 00 call 2bb51 <_EIP+0x2bb51>
Code; 00000010 Before first symbol
10: 89 d8 mov %ebx,%eax
Code; 00000012 Before first symbol
12: 89 fa mov %edi,%edx
Here's the source code of filp_close() in fs/open.c:
/*
* "id" is the POSIX thread ID. We use the
* files pointer for this..
*/
int filp_close(struct file *filp, fl_owner_t id)
{
int retval;
/* Report and clear outstanding errors */
retval = filp->f_error;
if (retval)
filp->f_error = 0;
if (!file_count(filp)) {
printk(KERN_ERR "VFS: Close: file count is 0\n");
return retval;
}
if (filp->f_op && filp->f_op->flush) {
int err = filp->f_op->flush(filp);
if (!retval)
retval = err;
}
dnotify_flush(filp, id);
locks_remove_posix(filp, id);
fput(filp);
return retval;
}
EXPORT_SYMBOL(filp_close);
and here's the objdump output for filp_close:
1d10 <filp_close>:
1d10: 55 push %ebp
1d11: 89 e5 mov %esp,%ebp
1d13: 83 ec 10 sub $0x10,%esp
1d16: 89 5d f4 mov %ebx,0xfffffff4(%ebp)
1d19: 89 c3 mov %eax,%ebx
1d1b: 89 7d fc mov %edi,0xfffffffc(%ebp)
1d1e: 89 d7 mov %edx,%edi
1d20: 89 75 f8 mov %esi,0xfffffff8(%ebp)
1d23: 8b 70 44 mov 0x44(%eax),%esi
1d26: 85 f6 test %esi,%esi
1d28: 74 07 je 1d31 <filp_close+0x21>
1d2a: c7 40 44 00 00 00 00 movl $0x0,0x44(%eax)
1d31: 8b 43 14 mov 0x14(%ebx),%eax
1d34: 85 c0 test %eax,%eax
1d36: 74 48 je 1d80 <filp_close+0x70>
1d38: 8b 43 10 mov 0x10(%ebx),%eax
1d3b: 85 c0 test %eax,%eax
1d3d: 74 07 je 1d46 <filp_close+0x36>
1d3f: 8b 50 2c mov 0x2c(%eax),%edx
1d42: 85 d2 test %edx,%edx
1d44: 75 2a jne 1d70 <filp_close+0x60>
1d46: 89 fa mov %edi,%edx
1d48: 89 d8 mov %ebx,%eax
1d4a: e8 fc ff ff ff call 1d4b <filp_close+0x3b>
1d4f: 89 d8 mov %ebx,%eax
1d51: 89 fa mov %edi,%edx
1d53: e8 fc ff ff ff call 1d54 <filp_close+0x44>
1d58: 89 d8 mov %ebx,%eax
1d5a: e8 fc ff ff ff call 1d5b <filp_close+0x4b>
1d5f: 89 f0 mov %esi,%eax
1d61: 8b 5d f4 mov 0xfffffff4(%ebp),%ebx
1d64: 8b 75 f8 mov 0xfffffff8(%ebp),%esi
1d67: 8b 7d fc mov 0xfffffffc(%ebp),%edi
1d6a: 89 ec mov %ebp,%esp
1d6c: 5d pop %ebp
1d6d: c3 ret
1d6e: 89 f6 mov %esi,%esi
1d70: 89 d8 mov %ebx,%eax
1d72: ff d2 call *%edx
1d74: 85 f6 test %esi,%esi
1d76: 0f 44 f0 cmove %eax,%esi
1d79: eb cb jmp 1d46 <filp_close+0x36>
1d7b: 90 nop
1d7c: 8d 74 26 00 lea 0x0(%esi,1),%esi
1d80: c7 04 24 00 01 00 00 movl $0x100,(%esp,1)
1d87: e8 fc ff ff ff call 1d88 <filp_close+0x78>
1d8c: eb d1 jmp 1d5f <filp_close+0x4f>
1d8e: 89 f6 mov %esi,%esi