Releases, locking and ldb (was: Re: [PATCH] [ldb_modules ABI break] Re: [WIP][PATCH] Safe LDB locking for better replication)

Andrew Bartlett abartlet at
Sat Jun 24 07:02:56 UTC 2017

On Sat, 2017-06-24 at 08:32 +1200, Andrew Bartlett via samba-technical
> On Fri, 2017-06-23 at 13:25 +0200, Stefan Metzmacher wrote:
> > 
> > > For the 1.1.30 ldb version, the even context changes require this in
> > > Samba (less important, only hits -M single):
> > > 
> > > commit 7259661467776a76c4fa3aabaf1ae8a3d531e506
> > > Author: Andrew Bartlett <abartlet at>
> > > Date:   Fri May 12 01:55:45 2017 +0200
> > > 
> > >     dsdb: Use ldb_handle_use_global_event_context for rootdse modifies
> > >     
> > >     The modify operations on the rootDSE turn into IRPC messages, and
> > > these need
> > >     to be handled on the global event context, not the per-operation
> > > context
> > 
> > Would it help to introduce an
> > ldb_set_allow_private_event_context() that's called by a new Samba
> > release. And other callers get the old behavior?
> > 
> > It would still leave us with unusable 1.1.30 and 1.1.31,
> > but 1.2.0 would be usable again.
> No, I don't think that is wise.  That just invites other operations
> (possibly writes) to happen during a read lock, and that invites
> LDB_ERR_BUSY (unable to upgrade hash locks). 

I'm not really worried about this use case, in that the only thing that
happens is that rootDSE modifies against -M single (not the default,
and not really that workable) DCs would fail. 

However the change in behaviour is only needed with the locking
patches, so we could:
 - fork a new ldb 1.1 branch in the repo
 - release ldb 1.1.32 with this change reverted

This would give us a basis to make backported fixes to ldb that may be
required by Samba 4.6 and earlier, which can't take ldb 1.2.0.

The locking change is like an ABI break, but only really impacts Samba
the the full extent because of the way we use the partitions module. 

I'm not sure we want to enforce a full ABI break for this (ldb-2.0.0),
as it would just make backporting this even more difficult. 

Let's continue to work on this.  

So we don't find ourselves under artificial deadlines here, can we
agree not to fork 4.7 without this resolved?  

I know this is a big ask, and totally against our procedures, but I'm
really uncomfortable proceeding with a release with this unresolved,
but resolving it isn't just technically difficult, it is about
balancing competing interests, something best done without time

For others trying to follow the thread, the summary is here: and


Andrew Bartlett
Andrew Bartlett             
Authentication Developer, Samba Team
Samba Developer, Catalyst IT

More information about the samba-technical mailing list