s4/torture: port SMBv1 RAW-LOCK tests to SMBv2

Steven Danneman steven.danneman at isilon.com
Thu Nov 26 21:41:50 MST 2009


> -----Original Message-----
> From: Andrew Bartlett [mailto:abartlet at samba.org]
> Sent: Thursday, November 26, 2009 2:24 PM
> To: samba-technical at lists.samba.org
> Cc: Steven Danneman
> Subject: s4/torture: port SMBv1 RAW-LOCK tests to SMBv2
> 
> On Wed, 2009-11-25 at 14:56 -0600, Steven Danneman wrote:
> > The branch, master has been updated
> >        via  f66612f... s4/torture: port SMBv1 RAW-LOCK tests to
SMBv2
> >        via  7f14388... s4/libcli: rename previously reserved field
in
> SMB2 LOCK struct
> >        via  65a611e... s4/libcli: Initialize client PID for SMB2
> connections
> >       from  95108f1... s3-registry: fix REG_MULTI_SZ handling in
> registry_push_value.
> >
> > http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
> >
> >
> > - Log
> > -----------------------------------------------------------------
> > commit f66612f62e43b752cb7461da429efd26d1c47296
> > Author: Steven Danneman <steven.danneman at isilon.com>
> > Date:   Wed Nov 18 16:35:03 2009 -0800
> >
> >     s4/torture: port SMBv1 RAW-LOCK tests to SMBv2
> 
> Did you get Samba4's 'make test' to pass after you made these changes?
> 
> I'm getting failures that look very much like this work. (maximum
> runtime exceeded for smbtorture - terminating)
> 
> We must *always* have 'make test' passing in both trees, whenever
> torture changes are made.  It is not enough for changes to be
> 'correct', the server code it tests should be fixed, or at an absolute
> last resort, the tests marked up as knownfail.  In this case, the test
> hangs, which must be fixed regardless.
> 
> This troubles me particularly today because I'm trying to make a
Samba4
> alpha release.
> 
> Please fix or revert.
> 
> Thanks,
> 
> Andrew Bartlett

Hey Andrew,

I did run 'make test' on Samba 4 and saw the errors you're referring to.
They seem to be issues with:

a) Samba4 returning the wrong error code on byte range locks above
64-bit
b) Handling of STATUS_PENDING replies and SMB2_CANCEL requests.

I did not investigate or fix these errors before committing the tests as
I have zero context with the way Samba4 handles SMB2.  The tests do pass
against both W2K8 and W2K8R2 servers.

While I agree that keeping 'make test' passing 100% clean at all times
is a desirable goal, I think it's unwise to make this a pre-requisite to
committing new, useful torture tests.  If all torture tests authors are
required to fix bugs, possibly very complicated ones, in two different
file servers (Samba3 and Samba4) before making their tests public, I
think we've set the barrier to entry too high and will receive many
fewer test contributions.

I realize the addition of failing torture tests affects the Samba4 code
verification process greatly as source4 'make test' uses an opt-out test
model rather than an opt-in test model in source3 'make test'.

I'd like to make these tests public as soon as they're correct, but I
certainly don't want to hinder your verification as you're trying to get
a release together.  I think a good policy, and what I'll do is mark the
failing tests as knownfail and then file bugs for them in bugzilla so we
can track that the issue exists and remind ourselves to remove them from
the knownfail state when the server bugs have been addressed.

How's that sound?

-Steven


More information about the samba-technical mailing list