samba.git, branch talloc-2.0.0 Unnamed repository; edit this file 'description' to name the repository. report the location of the original talloc_free on double free 2009-09-04T04:40:51+00:00 Andrew Tridgell tridge@samba.org 2009-09-04T03:56:46+00:00 27b19eb9f61dec1c60d9c6abcf1fb2e12541f62a When we get a double free abort from talloc it is often hard to work out where the first free came from. This patch takes advantage of the fact that _talloc_free() now takes a location the free was called from to allow the double free abort code to print the location of the first free that conflicts. 
When we get a double free abort from talloc it is often hard to work
out where the first free came from. This patch takes advantage of the
fact that _talloc_free() now takes a location the free was called from
to allow the double free abort code to print the location of the first
free that conflicts.
wbinfo: fix various valgrind warnings and an invalid free. 2009-09-03T22:04:49+00:00 Günther Deschner gd@samba.org 2009-09-03T22:02:13+00:00 b35c627b92c0585f4fa3a1d92385a908f0e0cd5b Kai, please check. Guenther 
Kai, please check.

Guenther
s3-ntlm_auth: fix two segfaults in diagnostics mode. 2009-09-03T22:04:40+00:00 Günther Deschner gd@samba.org 2009-09-03T21:49:50+00:00 d9bdf2a02f2966720a573cfa933edb112bf6fe64 Guenther 
Guenther
Hopefully last part of the fix for bug 6651 - smbd SIGSEGV when breaking oplocks. 2009-09-03T14:40:48+00:00 Jeremy Allison jra@samba.org 2009-09-03T14:40:48+00:00 bdc7bdb0d3e02d04477906dbda8995bc5789ce22 This one is subtle. There is a race condition where a signal can be queued for oplock break, and then the file can be closed by the client before the signal can be processed. Currently if this occurs we panic (we can't match an incoming signal fd with a fsp pointer). Simply log the error (at debug level 10 right now, might be too much) and then return without processing the break request. It looks like there is another race condition with this fix, but here's why it won't happen. If the signal was pending (caused by a kernel oplock break from a local file open), and the client closed the file and then re-opened another file which happened to use the same file descriptor as the file just closed, then theoretically the oplock break requests could be processed on the wrong fd. Here's why this should be very rare.. Processing a pending signal always take precedence over an incoming network request, so as long as the client close request is non-chained then the break signal should always be harmlessly processed *before* the open can be called. If the open is chained onto the close, and the fd on the new open is the same as the old closed fd, then it's possible this race will occur. However, all that will happen is that we'll lose the oplock on this file. A shame, but not a fatal event. Jeremy. 
This one is subtle. There is a race condition where a signal can be
queued for oplock break, and then the file can be closed by the client
before the signal can be processed. Currently if this occurs we panic
(we can't match an incoming signal fd with a fsp pointer). Simply log
the error (at debug level 10 right now, might be too much) and then
return without processing the break request. It looks like there is
another race condition with this fix, but here's why it won't happen.
If the signal was pending (caused by a kernel oplock break from a
local file open), and the client closed the file and then re-opened
another file which happened to use the same file descriptor as the
file just closed, then theoretically the oplock break requests could
be processed on the wrong fd. Here's why this should be very rare..
Processing a pending signal always take precedence over an incoming
network request, so as long as the client close request is non-chained
then the break signal should always be harmlessly processed *before*
the open can be called. If the open is chained onto the close, and
the fd on the new open is the same as the old closed fd, then it's
possible this race will occur. However, all that will happen is that
we'll lose the oplock on this file. A shame, but not a fatal event.
Jeremy.
Another part of the fix for bug 6651 - smbd SIGSEGV when breaking oplocks. 2009-09-03T14:38:21+00:00 Jeremy Allison jra@samba.org 2009-09-03T14:38:21+00:00 c97698e762b1ea8d7133f04ae822225676a6f135 SA_INFO_QUEUE_COUNT *MUST* be a power of 2, in order for the ring buffer wrap to work correctly at the 32 bit boundary. Thanks to Petr Vandrovec <petr@vandrovec.name> for this. 
SA_INFO_QUEUE_COUNT *MUST* be a power of 2, in order for the ring buffer
wrap to work correctly at the 32 bit boundary. Thanks to Petr
Vandrovec <petr@vandrovec.name> for this.
First attempt to implement dcesrv_drsuapi_DsGetNCChanges 2009-09-03T09:10:49+00:00 Anatoliy Atanasov anatoliy.atanasov@postpath.com 2009-09-02T14:39:28+00:00 38995d7cbb0c3143eb1fea0215863321349c7bbe So far it returns the ctr6 responce without proper linked attributes support and metadata. A couple of improvements are the filter in the search uses '(uSNChanged>=N)', added extended dn search support, non-replicated attributes are excluded from the result. 
So far it returns the ctr6 responce without proper linked attributes
support and metadata. A couple of improvements are the filter in the search
uses '(uSNChanged>=N)', added extended dn search support, non-replicated attributes
are excluded from the result.
Fix the dsdb_syntax_OID_ldb_to_drsuapi function 2009-09-03T09:10:42+00:00 Anatoliy Atanasov anatoliy.atanasov@postpath.com 2009-09-02T14:20:16+00:00 957a9285c22c5f4412154bd84a82d66fe759b0f5 This replace the dsdb_syntax_FOOBAR_ldb_to_drsuapi function, which was left as a TODO code. Implementation in both added functions is completely identical and probably should differ in the future. 
This replace the dsdb_syntax_FOOBAR_ldb_to_drsuapi function,
which was left as a TODO code. Implementation in both added functions
is completely identical and probably should differ in the future.
Ignoring generated files: 2009-09-03T09:09:50+00:00 Kamen Mazdrashki kamen.mazdrashki@postpath.com 2009-08-21T11:39:09+00:00 47dfe78142c89fd8798d22d5837d9b3be356ae78 libcli/smb/smb_common_proto.h source4/torture/ntp/proto.h 
libcli/smb/smb_common_proto.h
source4/torture/ntp/proto.h
another large change to the linked_attribute module 2009-09-03T08:36:10+00:00 Andrew Tridgell tridge@samba.org 2009-09-03T08:36:02+00:00 d3d6713c599fa74f5fdd890bd00ab0dd721749d8 This one copes with deleted objects where linked attributes have been set on the module. We hit this when we do the ldb wipe at the start of a provision, which trigers linked attribute updates, but for objects that have disappeared. We need to ensure that the linked attribute updates only happen on the right object, and if the object gets re-created (as happens with a provision) then it is not the right object. To cope with this we record the GUID of the object when the operation that triggered the linked attribute update comes in, and then find the DN by suing that GUID when we apply the change in the prepare commit hook. 
This one copes with deleted objects where linked attributes have been
set on the module. We hit this when we do the ldb wipe at the start of
a provision, which trigers linked attribute updates, but for objects
that have disappeared. We need to ensure that the linked attribute
updates only happen on the right object, and if the object gets
re-created (as happens with a provision) then it is not the right
object.

To cope with this we record the GUID of the object when the operation
that triggered the linked attribute update comes in, and then find the
DN by suing that GUID when we apply the change in the prepare commit
hook.
hook on prepare_commit instead of transaction_end 2009-09-03T08:36:10+00:00 Andrew Tridgell tridge@samba.org 2009-09-03T08:33:17+00:00 b72b8f6e7d6a83999153b71edd6f50a1803eff95 This allows for safe transaction end aborts 
This allows for safe transaction end aborts