[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

libpager deadlock

From: Samuel Thibault
Subject: libpager deadlock
Date: Sat, 27 Mar 2010 00:39:19 +0100
User-agent: Mutt/1.5.12-2006-07-14


>From times to times, ext2fs deadlocks on the pager->interlock mutex.
This is an excerpt of what I could find in the process:

#2  0x08106e59 in memory_object_lock_request ()
#3  0x0806fdeb in _pager_lock_object (p=0x81c97b8, offset=0, size=827392, 
should_return=2, should_flush=0,
    lock_value=8, sync=0) at /var/tmp/hurd-20090404/./libpager/lock-object.c:68
#4  0x0806da18 in pager_sync (p=0x81c97b8, wait=0) at 
#9  0x0805a9ac in periodic_sync (interval=5) at 

This is the periodic sync, calling memory_object_lock_request() on the
pager.  Note that before doing this, _pager_lock_object takes

#3  0x08079662 in __mutex_lock_solid (ptr=0x81c97f0) at 
#4  0x0806f7ff in _pager_do_write_request (object=1305, seqno=413, 
control=1819, offset=618496, data=6467584, 
    length=98304, dirty=1, kcopy=1, initializing=0) at 
#5  0x0806f88a in _pager_seqnos_memory_object_data_return (object=1305, 
seqno=413, control=1819, 
    offset=618496, data=6467584, length=98304, dirty=1, kcopy=1)
    at /var/tmp/hurd-20090404/./libpager/data-return.c:272
#6  0x0806e65e in _Xmemory_object_data_return (InHeadP=0x1, OutHeadP=0x10fbf40) 
at memory_objectServer.c:837

This is a memory_object_data_return() call from the kernel, trying to
take the pager->interlock mutex, but waiting for the periodic sync
thread to free it.

I don't have the gdb under the hand any more so can't check it for sure,
but I do see in GNU Mach's source that memory_object_lock_request() may
make memory_object_data_return() calls on the objects of the pager to
be synced.  Since these calls will need to take the interlock mutex as
the trace above shows, this can not be but potentially deadlock.  Am I
missing something?

I haven't found any documentation about what interlock is exactly
supposed to protect, so I can't really decide what to do here, I guess
just releasing around the memory_object_lock_request() call is not safe
for instance. Any thoughts?

It is worth noting that by default, the kernel does not call
memory_object_data_return because by default use_old_pageout is
TRUE.  But as soon as pager_change_attributes() (thus Mach's
memory_object_change_attributes()) is called, it turns to FALSE. One way
to trigger it is to just call truncate() on a file, thus calling
ext2fs_truncate() which ends up calling pager_change_attributes at some


reply via email to

[Prev in Thread] Current Thread [Next in Thread]