Re: 2.25 freeze - a little more than the holiday fortnight to go

[Torvald Riegel <triegel at redhat dot com>]

On Thu, 2016-12-22 at 14:12 +0100, Florian Weimer wrote:
> On 12/21/2016 09:19 PM, Torvald Riegel wrote:
> > On Tue, 2016-12-13 at 21:13 +0530, Siddhesh Poyarekar wrote:
> >> I had proposed tunables as a blocker for 2.25 during Cauldron and I want
> >> to stick with that position unless someone has a good reason to delay it
> >> for yet another release.  If there is anything else that needs attention
> >> but is not getting it then please ping early and ping often so that it
> >> gets the desired attention.
> >
> > I've added the new condvar and rwlock as blockers.  We've been testing
> > them for several weeks in Rawhide and haven't heard any complaints so
> > far.  Carlos has reviewed the patches, basically.
> 
> The condvar layout change breaks on-disk Berkeley DB database 
> environments.  The breakage is persistent across reboots.  Depending on 
> the application which uses Berkeley DB, there might not be an easy way 
> to recover affected database environments because the usual.
> 
>    <https://bugzilla.redhat.com/show_bug.cgi?id=1394862>
> 
> This is arguably a bug in Berkeley DB

My statement regarding "complaints" did not include buggy user programs.
Sorry if that wasn't clear.

Carlos' RFC about this, in which he said that he thinks this is a user
bug, only got one reply so far, in which Mike Frysinger agreed with
Carlos.  In the absence of further opinions to the contrary, I think we
have consensus that this is a bug in Berkeley DB.

> (after a reboot, the first thing 
> applications have to do is to reinitialize synchronization objects 
> because there definitely are no processes which map the objects left)

That's something a correct DB would do when recovering a database that
contains third-party synchronization primitives (eg, glibc condvars),
whose internals are supposed to be internals and not a public interface.

> Note that I'm *not* saying we need to fix this in glibc through a compat 
> symbol or with the help of flags.  We just need to offer *any* solution 
> whatsoever.

So what do you think this means for accepting the new condvar in 2.25?
Is having "something" a blocker for the condvar?  I would like to not
set the precedent that single buggy programs can affect glibc's
development; the emacs case was unfortunate enough.

We should also remember that not including the new condvar in 2.25 will
cause all users to have to use the old condvar which is not fully
conforming to POSIX.  Fixing them bug for them in a timely fashion seems
more important than giving Berkeley DB more time to fix its bug.