Patch for a memory leak issue in share mode locking.

[Jeremy Allison]

On Thu, May 26, 2016 at 12:31:49AM +0000, Saji VR wrote:
> Jeremy,
>  That exactly was my analysis too…
> 
>  Here is what I sent to Volker today morning trying to explain it…
> 
> ————————
> 
> Volker,
> 
> Thanks for the response, Hemanth posted this on my behalf as I am not active on samba (Yet!)
> Some more background and details as to why we end up in this state…
> 
> Lets look at the events on a timeline…
> 
> 
> 
> 1. Client opens object a : We create a share lock mode entry (as part of the very first open on that object), add the share lock data (my understanding is one record per lock/open)
> 2. At the end of open processing talloc free for the share lock mode is called, this triggers the destructor setup for the entry which moves the share lock mode to memcache also reparent
>     It to memcache. At that point, we also have the buffer used for marshaling the record entry hanging of (or parented to) the share lock mode entry.
> 3. Client triggers another open for the same object without closing the first one. As part of processing this, we pull the share lock mode from memcache rather than allocating a new one
>     (I still have to justify the rational here as the only savings we get is the allocation
> and initialization cost, but at the cost of fragmenting heap over a long lived connection). 

The reasoning behind this is to save the ndr unmarshalling
cost, which is large enough that it shows up in code profile
runs.

The idea behind this cache was initially from Volker, who
first saw the problem in production cases.

Cheers,

	Jeremy.