[Top][All Lists]

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

Re: libpager deadlock

From: Sergio Lopez
Subject: Re: libpager deadlock
Date: Wed, 7 Apr 2010 12:43:15 +0200

El Sat, 27 Mar 2010 00:39:19 +0100
Samuel Thibault <samuel.thibault@gnu.org> escribió:

> Hello,
> 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 /var/tmp/hurd-20090404/./libpager/pager-sync.c:31 ... #9
> 0x0805a9ac in periodic_sync (interval=5)
> at /var/tmp/hurd-20090404/./libdiskfs/sync-interval.c:119
> This is the periodic sync, calling memory_object_lock_request() on the
> pager.  Note that before doing this, _pager_lock_object takes
> pager->interlock.

AFAIK, m_o_lock_request is an asynchronous operation, so it should not
block in any case. Perhaps the cthreads package is behaving weird?

> #3  0x08079662 in __mutex_lock_solid (ptr=0x81c97f0)
> at /var/tmp/hurd-20090404/./libthreads/cprocs.c:955 #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 /var/tmp/hurd-20090404/./libpager/data-return.c:174 #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 point.
> Samuel

reply via email to

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