Releases, locking and ldb

[Stefan Metzmacher]

Am 27.06.2017 um 20:43 schrieb Andrew Bartlett via samba-technical:
> On Tue, 2017-06-27 at 22:06 +1200, Andrew Bartlett via samba-technical
> wrote:
>> On Tue, 2017-06-27 at 21:46 +1200, Andrew Bartlett via samba-technical
>> wrote:
>>> On Tue, 2017-06-27 at 08:24 +0200, Stefan Metzmacher via samba-
>>> technical wrote:
>>>>
>>>> The good thing is that due to LDB_MODULE_CHECK_VERSION()
>>>> Samba and sssd are only runtime compatible with the version
>>>> they're build against.
>>>>
>>>> Would "ldb:tdb: Ensure we correctly decrement ltdb->read_lock_count"
>>>> affect any old caller in any bad way?
>>>
>>> I presume you mean some other hypothetical application beyond Samba and
>>> SSSD?
>>>
>>> The primary change is that during the ldb callbacks, the DB is locked,
>>> rather than unlocked.  It is no longer possible to start a transaction
>>> (write operation) during an ldb callback.  Instead, as good practice
>>> would already dictate, you must start the transaction before the
>>> search. 
>>>
>>>> And what about "tdb: Remove locking from tdb_traverse_read()"?
>>>
>>> I'm not sure about this one.  As we can't have one without the other I
>>> don't know (and haven't studied) exactly what else it might impact. 
>>>
>>> I don't think this without the ldb patches is actively harmful however.
>>>
>>>> Whould something like this on the samba_dsdb module
>>>> in 4.6 work around the problems (and keep it only as broken as it
>>>> already is):
>>>> - always call ldb_handle_use_global_event_context()
>>>
>>> I don't think this case is worth worrying about.  It is rootdse
>>> modified over LDAP in the single process model (only). 
>>>
>>>> - overwrite read_lock/read_unlock() to be a no-op
>>>
>>> No, this gets us to the point I was at during SambaXP, with random
>>> LDB_ERR_BUSY / 'failed to upgrade hash locks', as we won't have a
>>> global lock order.
>>>
>>> I don't think it makes any difference to actually to have it pass the
>>> read_lock()/read_unlock() down to sam.ldb.
>>>
>>> I personally think we should just declare the incomparability, ideally
>>> at build time, and move on.  (I tried to create an #ifdef hack to
>>> detect this at build time, but wasn't able to build a reliable one
>>> yet). 
>>>
>>> I realise that everything that can happen will happen, but still: how
>>> likely are they to be mixed in the real world?
>>
>> I guess more likely than I care to admit.  Try the attached for a
>> compile-time way to prevent this.
> 
> Can I please get some feedback on what I need to do to make progress on
> this?

Can you prepare a branch on master with the required reverts?
It should be possible to copy the lib/ldb lib/tdb directories
to a 4.6 branch and let is pass autobuild.

I think once I know what's exactly required to be reverted,
I can try to think about a final solution.

metze


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170628/90d2762f/signature.sig>