[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
>
>
>
>
- Re: libpager deadlock,
Sergio Lopez <=
- Re: libpager deadlock, Samuel Thibault, 2010/04/07
- Re: libpager deadlock, Sergio Lopez, 2010/04/08
- Re: libpager deadlock, Samuel Thibault, 2010/04/08
- Re: libpager deadlock, Sergio Lopez, 2010/04/08
- Re: libpager deadlock, Samuel Thibault, 2010/04/08
- Re: libpager deadlock, Sergio Lopez, 2010/04/09
- MIG documentation (was: libpager deadlock), Thomas Schwinge, 2010/04/09
- Re: MIG documentation (was: libpager deadlock), Samuel Thibault, 2010/04/09
- Re: MIG documentation, Thomas Schwinge, 2010/04/09