truncate_list_pages() page lock confusion and BUG

I'm getting BUG()s from page_alloc.c:109 in 2.5.6-pre2

truncate_list_pages() contains

failed = TryLockPage(page);

The page should always be locked when I get past there

shortly after this, truncate_complete_page() can be called

truncate_complete_page() calls:

        remove_inode_page(page);
             if (!PageLocked(page))
                PAGE_BUG(page);
followed immediately by
        page_cache_release(page);
            calls __free_pages_ok(page, 0);
                if (PageLocked(page))
                   BUG();

So, it appears that when truncate_complete_page() is called, it is a BUG if the page is unlocked in remove_inode_page(), or locked in page_cache_release(). What am I missing? Actual bug follows:

kernel BUG at page_alloc.c:109!

invalid operand: 0000
CPU:    1
EIP:    0010:[<c012f27c>]    Not tainted
EFLAGS: 00010202
eax: 01000001   ebx: c13ba15c   ecx: c13ba15c   edx: c13ba15c
esi: 00000000   edi: db5aff20   ebp: 00000000   esp: db5afe90
ds: 0018   es: 0018   ss: 0018
Stack: c13ba15c 00000000 db5aff20 00000000 c13ba15c c13ba15c 00000000 c13ba15c
       00000000 db5aff20 00000000 c012717a c13ba15c 00000000 c012fb05 
c13ba15c
       c01271c2 c13ba15c c13ba15c c0127326 c13ba15c 00000000 db5aff20 
00000018
Call Trace: [<c012717a>] [<c012fb05>] [<c01271c2>] [<c0127326>] [<c01273db>]
   [<c0125192>] [<c012a49d>] [<c01361fb>] [<c0108a23>]
Code: 0f 0b 6d 00 60 89 24 c0 8b 4c 24 10 8b 41 18 a8 40 74 08 0f

Trace; c012717a <do_flushpage+26/2c>
Trace; c012fb05 <page_cache_release+2d/30>
Trace; c01271c2 <truncate_complete_page+42/48>
Trace; c0127326 <truncate_list_pages+15e/1c4>
Trace; c01273db <truncate_inode_pages+4f/80>
Trace; c0125192 <vmtruncate+be/154>
Trace; c012a49d <generic_file_write+62d/6f8>
Trace; c01361fb <sys_write+8f/10c>
Trace; c0108a23 <syscall_call+7/b>
Code; c012f27c <__free_pages_ok+6c/29c>
00000000 <_EIP>:
Code; c012f27c <__free_pages_ok+6c/29c> <=====
0: 0f 0b ud2a <=====
Code; c012f27e <__free_pages_ok+6e/29c>
2: 6d insl (%dx),%es:(%edi)
Code; c012f27f <__free_pages_ok+6f/29c>
3: 00 60 89 add %ah,0xffffff89(%eax)
Code; c012f282 <__free_pages_ok+72/29c>
6: 24 c0 and $0xc0,%al
Code; c012f284 <__free_pages_ok+74/29c>
8: 8b 4c 24 10 mov 0x10(%esp,1),%ecx
Code; c012f288 <__free_pages_ok+78/29c>
c: 8b 41 18 mov 0x18(%ecx),%eax
Code; c012f28b <__free_pages_ok+7b/29c>
f: a8 40 test $0x40,%al
Code; c012f28d <__free_pages_ok+7d/29c>
11: 74 08 je 1b <_EIP+0x1b> c012f297
<__free_pages_ok+87/29c>
Code; c012f28f <__free_pages_ok+7f/29c>
13: 0f 00 00 sldt (%eax)

Dave Hansen
[email protected]

The page should not be actually freed by truncate_complete_page(). See how truncate_list_pages() has bumped its refcount?

If the page is successfully truncated then the actual freeing occurs in the page_cache_release() in truncate_list_pages(), after the page has been unlocked.

Looks like the page refcount has suffered an extra decrement somewhere. You're hitting this on the not-very-tested generic_file_write() error path. But it all looks to be OK.

2.5.6 is awfully ancient.

-

Netscape was just complaining about being offline and evidently send some messages that it shouldn't have. That message was really old, like from the 2.5.6-pre2 days (guess how I figured that out). Just ignore it.

Dave Hansen
[email protected]