[PATCH] Fix an assertion check

[Anoop C S]

On Mon, 2018-07-30 at 16:20 -0700, Jeremy Allison wrote:
> On Mon, Jul 30, 2018 at 09:40:30AM +0200, Andreas Schneider wrote:
> > On Saturday, 28 July 2018 00:18:26 CEST Jeremy Allison via samba-
> > technical 
> > wrote:
> > > On Fri, Jul 27, 2018 at 12:17:05PM +0530, Anoop C S via samba-
> > > technical 
> > 
> > wrote:
> > > > Hi,
> > > > 
> > > > Attached patch fixes the assertion check while reducing the
> > > > lock reference
> > > > count. If it is the right thing to do we may also consider
> > > > changing the
> > > > assertion check while increasing the same lock reference count
> > > > inside
> > > > increment_lock_ref_count():
> > > > 
> > > > SMB_ASSERT(lock_ref_count < (INT32_MAX - 1))
> > > > 
> > > > Also the DEBUG statement[inside increment_lock_ref_count() and
> > > > decrement_lock_ref_count()] prints the old reference count
> > > > value instead
> > > > of the new one.
> > > > 
> > > > Thanks,
> > > > Anoop C S.
> > > 
> > > This patch is correct. Reviewed-by: Jeremy Allison <jra at samba.org
> > > >
> > > 
> > > Can I get a second Team reviewer ?
> > 
> > RB+, I guess we should open a bug for this and backport?
> 
> Hmmm. Maybe. This code has been in use for over 10 years
> and hasn't caused an issue.

I came across this difference in assertion check while tracking down a
back trace from https://bugzilla.samba.org/show_bug.cgi?id=13439#c1.
The very same panic was also reported internally for us. Unfortunately
we do not have a reproducer in both cases. I have asked for further
debugging information and/or any steps to follow which might lead to
this assertion failure.

Meanwhile I am trying to figure out if some sequence of lock and unlock
requests(with specific offset and size) together with close can result
in this assertion failure situation with current code.

> I'm OK with fixing on next release cycle.