process shared robust mutexes for tdb

[Volker Lendecke]

On Mon, May 27, 2013 at 02:19:17PM +0200, Stefan (metze) Metzmacher wrote:
> here's the current patchset including configure checks and runtime
> checks for robust mutexes.
> 
> I think there's only one thing left that needs a bit more work,
> it's the error path handling in tdb_allrecord_upgrade().
> 
> For the non mutex case we do this:
> 
>      ret = tdb_brlock_retry(tdb, F_WRLCK, FREELIST_TOP,
>                             tdb->hash_size * 4,
>                             TDB_LOCK_WAIT|TDB_LOCK_PROBE);
> 
>      ret = tdb_brlock_retry(tdb, F_WRLCK, lock_offset(tdb->hash_size), 0,
>                             TDB_LOCK_WAIT|TDB_LOCK_PROBE);
> 
> while we locked the whole range with one call before.
> 
> The error path to cleanup the first lock if the 2nd fails does this
> currently:
> 
>         ret = tdb_brlock(tdb, F_RDLCK, FREELIST_TOP,
>                          tdb->hash_size * 4, TDB_LOCK_WAIT);
> 
> Wouldn't the following be the more correct way to undo the first lock?
> 
>      ret = tdb_brunlock(tdb, F_WRLCK, FREELIST_TOP, tdb->hash_size * 4)
> 
> instead of doing an additional read lock?

We did have a read lock for all hash chains. Shouldn't we do
the downgrade to what was there before in the error case?

> For the mutex case we'd also need to undo tdb_mutex_allrecord_upgrade().

I don't think this is fixable. We have upgraded the
allrecord lock. If we had people in between queue up for the
readonly allrecord mutex lock while we errouneously had the
allrecord lock upgraded, we don't have a chance to wake them
up after we downgraded again.

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de