> -----Original Message-----
> From: stef...@apache.org [mailto:stef...@apache.org]
> Sent: vrijdag 2 mei 2014 16:08
> To: comm...@subversion.apache.org
> Subject: svn commit: r1591919 - in /subversion/trunk/subversion: include/
> include/private/ libsvn_fs/ libsvn_fs_base/bdb/ libsvn_fs_fs/ libsvn_fs_x/
> libsvn_ra_svn/ libsvn_subr/ svnserve/ tests/ tests/libsvn_fs_fs/
> 
> Author: stefan2
> Date: Fri May  2 14:07:40 2014
> New Revision: 1591919
> 
> URL: http://svn.apache.org/r1591919
> Log:
> APR mutexes don't support recursive locking on all platforms.
> As a result, trying to take out the same lock twice in the
> same thread will cause a lock up under e.g. Linux.  This patch
> adds an option to svn_mutex__t that detects recursive locking
> attempts in most cases and returns a proper error.
> 
> The idea is simply to store the thread ID of the lock OWNER
> along the actual mutex object.  If that matches the current
> thread's ID, there is a violation.  As the current thread
> cannot race with itself and because any other thread uses a
> different thread ID, setting and comparing this aux. info can
> be done safely.
> 
> Also, we may allow for false negatives here since we only try
> to detect code sequences that are already illegal in the first
> place.  We also don't make that check mandatory as access to
> thread IDs and their comparison may be somewhat expensive on
> some systems - which would impair the futex-like behavior that
> we assume in some places like the caches.
> 
> A more detailed description has been added to the source code.
> A FSFS-based test is added as that has been the origin of the
> feature request.
> 
> Current users will be updated as follows.  FS level locks and
> library / module initialization will enable recursion detection.
> Potentially runtime critical, internal use disables it.
> 
> * subversion/include/svn_error_codes.h
>   (SVN_ERR_RECURSIVE_LOCK): Define a new error code for invalid
>                             locking schemes.
> 
> * subversion/include/private/svn_mutex.h
>   (svn_mutex__t): Our mutex is now a struct as we add aux.
>                   data to it.
>   (svn_mutex__init): Add the CHECKED option.
> 
> * subversion/libsvn_subr/mutex.c
>   (svn_mutex__t): Define the mutex structure and and document
>                   the aux. data extensively.
>   (svn_mutex__init): Update constructor.
>   (svn_mutex__lock): Optionally, check for recursive locking attempts
>                      and update the associtated aux. data.
>   (svn_mutex__unlock): Optionally, update the aux. data for recursive
>                        lock detection.
> 
> * subversion/tests/libsvn_fs_fs/fs-fs-pack-test.c
>   (never_reached,
>    lock_again): Callback functions required by the new test.
>   (recursive_locking): New test expecting an SVN_ERR_RECURSIVE_LOCK.
>   (test_funcs): Register the new test.

This new test currently causes a deadlock on Windows and a test failure on 
OpenBSD.

OpenBSD:
[[[
subversion/tests/libsvn_fs_fs/fs-fs-pack-test.c:1159,
subversion/libsvn_fs_fs/fs_fs.c:424,
subversion/libsvn_fs_fs/fs_fs.c:248,
subversion/libsvn_fs_fs/fs_fs.c:236,
subversion/libsvn_fs_fs/fs_fs.c:248,
subversion/libsvn_fs_fs/fs_fs.c:236,
subversion/libsvn_fs_fs/fs_fs.c:248,
subversion/libsvn_fs_fs/fs_fs.c:236,
subversion/tests/libsvn_fs_fs/fs-fs-pack-test.c:1148: 
(apr_err=SVN_ERR_TEST_FAILED)
svn_tests: E200006: Expected error SVN_ERR_RECURSIVE_LOCK but got SVN_NO_ERROR
FAIL:  fs-fs-pack-test 15: prevent recursive locking
]]]

Windows:
Hang in
[[[
>       libapr-1.dll!apr_file_lock(apr_file_t * thefile, int type) Line 35      
> C
        fs-fs-pack-test.exe!svn_io_lock_open_file(apr_file_t * lockfile_handle, 
int exclusive, int nonblocking, apr_pool_t * pool) Line 2137    C
        fs-fs-pack-test.exe!svn_io_file_lock2(const char * lock_file, int 
exclusive, int nonblocking, apr_pool_t * pool) Line 2239      C
        fs-fs-pack-test.exe!get_lock_on_filesystem(const char * lock_filename, 
apr_pool_t * pool) Line 115      C
        fs-fs-pack-test.exe!with_some_lock_file(with_lock_baton_t * baton) Line 
202     C
        fs-fs-pack-test.exe!with_lock(void * baton, apr_pool_t * pool) Line 248 
C
        fs-fs-pack-test.exe!svn_fs_fs__with_all_locks(svn_fs_t * fs, 
svn_error_t * (void *, apr_pool_t *) * body, void * baton, apr_pool_t * pool) 
Line 424     C
        fs-fs-pack-test.exe!lock_again(void * baton, apr_pool_t * pool) Line 
1148       C
        fs-fs-pack-test.exe!with_some_lock_file(with_lock_baton_t * baton) Line 
230     C
        fs-fs-pack-test.exe!with_lock(void * baton, apr_pool_t * pool) Line 248 
C
        fs-fs-pack-test.exe!with_some_lock_file(with_lock_baton_t * baton) Line 
230     C
        fs-fs-pack-test.exe!with_lock(void * baton, apr_pool_t * pool) Line 248 
C
        fs-fs-pack-test.exe!with_some_lock_file(with_lock_baton_t * baton) Line 
230     C
        fs-fs-pack-test.exe!with_lock(void * baton, apr_pool_t * pool) Line 248 
C
        fs-fs-pack-test.exe!svn_fs_fs__with_all_locks(svn_fs_t * fs, 
svn_error_t * (void *, apr_pool_t *) * body, void * baton, apr_pool_t * pool) 
Line 424     C
        fs-fs-pack-test.exe!recursive_locking(const svn_test_opts_t * opts, 
apr_pool_t * pool) Line 1159        C
        fs-fs-pack-test.exe!test_thread(apr_thread_t * thread, void * data) 
Line 519    C
        libapr-1.dll!dummy_worker(void * opaque) Line 79        C
]]]

        Bert
 


Reply via email to