Padding byte in cifs readx response

[Christof Schmitt]

On Fri, Aug 08, 2014 at 12:46:00PM -0700, Jeremy Allison wrote:
> On Thu, Aug 07, 2014 at 04:16:45PM -0700, Christof Schmitt wrote:
> > > VL: Question: Is it possible to leave alone and in the higher levels
> > > calling this just let it allocate one more byte? This only affects read&x,
> > > all others are unchanged, right?
> > 
> > I changed this in the new patch series by creating a new function to add
> > the padding byte. This only affects two codepaths for the readx
> > response.
> 
> Yes - but aren't these *REALLY HOT* codepaths....
> 
> Doing a talloc_realloc() to add one more byte
> here will have to be carefully benchmarked to
> make sure we don't kill our readX performance.
> 
> OK, I'm going to ask a heretical question here.
> 
> Do we really need to do this ? Just to match
> a spec that the Windows client doesn't actually
> care about (as our Read code path works against
> Windows) ?
> 
> Can't we add your test and mark Samba as
> knownfail and move on with our lives unless
> we can find a way to fix this without performance
> problems ?

The original report is from an actual client failure. So far my plan is
to get this patchset ready and see if it fixes the reported problem. It
should only be included in master, once i can confirm that.

If this whole thing does not work out, then i agree, we can just add a
test and mark it as known fail.

Christof