xfs
[Top] [All Lists]

[Bug 311] ioctl hang in 2.6.x kernels with quota support

To: xfs-master@xxxxxxxxxxx
Subject: [Bug 311] ioctl hang in 2.6.x kernels with quota support
From: bugzilla-daemon@xxxxxxxxxxx
Date: Thu, 1 Apr 2004 23:45:45 -0800
Sender: linux-xfs-bounce@xxxxxxxxxxx
http://oss.sgi.com/bugzilla/show_bug.cgi?id=311





------- Additional Comments From steven.wilton@xxxxxxxxxxxxxx  2004-01-04 23:45 
PDT -------
OK, unfortunately the debug messages only show up on the console, and I can't
have the server offline for long enough to copy the complete backtrace. The
backtrace of the hung process has the following command sequence:

io_schedule
__lock_page
find_lock_page
_find_or_create_page
_pagebuf_lookup_pages
pagebuf_get

No surprises here, the hung process is trying to lock a page, failing and
calling the scheduler.

Possibly related to this is the error message that I get in the kernel log
(pagebuf_get: warning, failed to lookup pages).  This error only occurs in the
pagebuf_get() function (fs/xfs/linux/xfs_buf.c).  I added some more printk
statements, and discovered that the source of this error is a ENOMEM, returned
from the _pagebuf_lookup_pages() function (fs/xfs/linux/xfs_buf.c).  

The reason that ENOMEM is returned from _pagebuf_lookup_pages() is because
find_or_create_page() (in mm/filemap.c) returns NULL (line 12 of the function -
explicit return NULL).  This occurs because alloc_pages returns NULL 2 lines 
above.

I can't see why this would leave a stale lock, but I am looking through the code
to see if I can see anything else.  Can I do anything else?



------- 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>