1
0
mirror of https://github.com/samba-team/samba.git synced 2024-12-23 17:34:34 +03:00
Commit Graph

130188 Commits

Author SHA1 Message Date
Joseph Sutton
b423c370b9 CVE-2022-2031 s4:kpasswd: Account for missing target principal
This field is supposed to be optional.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15047
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15049
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15074

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
2022-07-27 10:52:36 +00:00
Joseph Sutton
2872ccc931 CVE-2022-2031 third_party/heimdal: Check generate_pac() return code
If the function fails, we should not issue a ticket missing the PAC.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15047

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
9881491023 CVE-2022-32745 s4/dsdb/util: Correctly copy values into message element
To use memcpy(), we need to specify the number of bytes to copy, rather
than the number of ldb_val structures.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15008

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
aa728dfcc9 CVE-2022-32745 s4/dsdb/util: Don't call memcpy() with a NULL pointer
Doing so is undefined behaviour.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15008

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
4a31c48057 CVE-2022-32745 s4/dsdb/util: Use correct value for loop count limit
Currently, we can crash the server by sending a large number of values
of a specific attribute (such as sAMAccountName) spread across a few
message elements. If val_count is larger than the total number of
elements, we get an access beyond the elements array.

Similarly, we can include unrelated message elements prior to the
message elements of the attribute in question, so that not all of the
attribute's values are copied into the returned elements values array.
This can cause the server to access uninitialised data, likely resulting
in a crash or unexpected behaviour.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15008

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
4ec784e0a9 CVE-2022-32745 s4/dsdb/samldb: Check for empty values array
This avoids potentially trying to access the first element of an empty
array.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15008

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Andrew Bartlett
f4eb4e6478 CVE-2022-32746 ldb: Release LDB 2.6.1
* CVE-2022-32746 Use-after-free occurring in database audit logging module (bug 15009)

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009

Signed-off-by: Andrew Bartlett <abartlet@samba.org>
2022-07-27 10:52:36 +00:00
Joseph Sutton
0a3aa5f908 CVE-2022-32746 ldb: Make use of functions for appending to an ldb_message
This aims to minimise usage of the error-prone pattern of searching for
a just-added message element in order to make modifications to it (and
potentially finding the wrong element).

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
df487eb2d7 CVE-2022-32746 ldb: Add functions for appending to an ldb_message
Currently, there are many places where we use ldb_msg_add_empty() to add
an empty element to a message, and then call ldb_msg_add_value() or
similar to add values to that element. However, this performs an
unnecessary search of the message's elements to locate the new element.
Moreover, if an element with the same attribute name already exists
earlier in the message, the values will be added to that element,
instead of to the intended newly added element.

A similar pattern exists where we add values to a message, and then call
ldb_msg_find_element() to locate that message element and sets its flags
to (e.g.) LDB_FLAG_MOD_REPLACE. This also performs an unnecessary
search, and may locate the wrong message element for setting the flags.

To avoid these problems, add functions for appending a value to a
message, so that a particular value can be added to the end of a message
in a single operation.

For ADD requests, it is important that no two message elements share the
same attribute name, otherwise things will break. (Normally,
ldb_msg_normalize() is called before processing the request to help
ensure this.) Thus, we must be careful not to append an attribute to an
ADD message, unless we are sure (e.g. through ldb_msg_find_element())
that an existing element for that attribute is not present.

These functions will be used in the next commit.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
a2bb5beee8 CVE-2022-32746 ldb: Ensure shallow copy modifications do not affect original message
Using the newly added ldb flag, we can now detect when a message has
been shallow-copied so that its elements share their values with the
original message elements. Then when adding values to the copied
message, we now make a copy of the shared values array first.

This should prevent a use-after-free that occurred in LDB modules when
new values were added to a shallow copy of a message by calling
talloc_realloc() on the original values array, invalidating the 'values'
pointer in the original message element. The original values pointer can
later be used in the database audit logging module which logs database
requests, and potentially cause a crash.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
7efe8182c1 CVE-2022-32746 ldb: Add flag to mark message element values as shared
When making a shallow copy of an ldb message, mark the message elements
of the copy as sharing their values with the message elements in the
original message.

This flag value will be heeded in the next commit.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
3e4439565b CVE-2022-32746 s4/registry: Use LDB_FLAG_MOD_TYPE() for flags equality check
Now unrelated flags will no longer affect the result.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
e8ebdb9936 CVE-2022-32746 s4/dsdb/tombstone_reanimate: Use LDB_FLAG_MOD_TYPE() for flags equality check
Now unrelated flags will no longer affect the result.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
e3b0026413 CVE-2022-32746 s4/dsdb/repl_meta_data: Use LDB_FLAG_MOD_TYPE() for flags equality check
Now unrelated flags will no longer affect the result.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
41b1fe6d4a CVE-2022-32746 ldb:rdn_name: Use LDB_FLAG_MOD_TYPE() for flags equality check
Now unrelated flags will no longer affect the result.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
99b805e4cb CVE-2022-32746 s4/dsdb/acl: Fix LDB flags comparison
LDB_FLAG_MOD_* values are not actually flags, and the previous
comparison was equivalent to

(el->flags & LDB_FLAG_MOD_MASK) == 0

which is only true if none of the LDB_FLAG_MOD_* values are set, so we
would not successfully return if the element was a DELETE. Correct the
expression to what it was intended to be.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
64258fd8b1 CVE-2022-32746 s4:torture: Fix LDB flags comparison
LDB_FLAG_MOD_* values are not actually flags, and the previous
comparison was equivalent to

(el->flags & LDB_FLAG_MOD_MASK) == 0

which is only true if none of the LDB_FLAG_MOD_* values are set. Correct
the expression to what it was probably intended to be.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
d178a06140 CVE-2022-32746 s4/dsdb/partition: Fix LDB flags comparison
LDB_FLAG_MOD_* values are not actually flags, and the previous
comparison was equivalent to

(req_msg->elements[el_idx].flags & LDB_FLAG_MOD_MASK) != 0

which is true whenever any of the LDB_FLAG_MOD_* values are set. Correct
the expression to what it was probably intended to be.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
852a79c63c CVE-2022-32746 s4:dsdb:tests: Add test for deleting a disallowed SPN
If an account has an SPN that requires Write Property to set, we should
still be able to delete it with just Validated Write.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Joseph Sutton
a45ba89182 CVE-2022-32746 s4/dsdb/objectclass_attrs: Fix typo
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009

Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
2022-07-27 10:52:36 +00:00
Stefan Metzmacher
d5c7e2e273 s3:dbwrap_watch: call dbwrap_watched_trigger_wakeup() outside of the low level record lock
This gives a nice speed up, as it's unlikely for the waiters to hit
contention.

The following test with 256 commections all looping with open/close
on the same inode (share root) is improved drastically:

  smbtorture //127.0.0.1/m -Uroot%test smb2.create.bench-path-contention-shared \
     --option='torture:bench_path=' \
     --option="torture:timelimit=60" \
     --option="torture:nprocs=256"

From some like this:

   open[num/s=8800,avslat=0.021445,minlat=0.000095,maxlat=0.179786]
   close[num/s=8800,avslat=0.021658,minlat=0.000044,maxlat=0.179819]

to:

   open[num/s=10223,avslat=0.017922,minlat=0.000083,maxlat=0.106759]
   close[num/s=10223,avslat=0.017694,minlat=0.000040,maxlat=0.107345]

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>

Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Tue Jul 26 14:32:35 UTC 2022 on sn-devel-184
2022-07-26 14:32:35 +00:00
Stefan Metzmacher
9d99911663 s3:dbwrap_watch: only notify the first waiter
In case of a highly contended record we will have a lot of watchers,
which will all race to get g_lock_lock() to finish.

If g_lock_unlock() wakes them all, e.g. 250 of them, we get a thundering
herd, were 249 will only find that one of them as able to get the lock
and re-add their watcher entry (not unlikely in a different order).

With this commit we only wake the first watcher and let it remove
itself once it no longer wants to monitor the record content
(at that time it will wake the new first watcher).

It means the woken watcher doesn't have to race with all others
and also means order of watchers is kept, which means that we
most likely get a fair latency distribution for all watchers.

The following test with 256 commections all looping with open/close
on the same inode (share root) is improved drastically:

  smbtorture //127.0.0.1/m -Uroot%test smb2.create.bench-path-contention-shared \
     --option='torture:bench_path=' \
     --option="torture:timelimit=60" \
     --option="torture:nprocs=256"

From some like this:

   open[num/s=80,avslat=2.793862,minlat=0.004097,maxlat=46.597053]
   close[num/s=80,avslat=2.387326,minlat=0.023875,maxlat=50.878165]

to:

   open[num/s=8800,avslat=0.021445,minlat=0.000095,maxlat=0.179786]
   close[num/s=8800,avslat=0.021658,minlat=0.000044,maxlat=0.179819]

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
6e701d02ee s3:smbXsrv_session: only change the dbwrap_watch instance when the record has changed
This will become important in the following commits when the
dbwrap_watch layer will only wake up one watcher at a time
and each woken watcher will wakeup the next one.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
98269bd5f3 s3:smbXsrv_session: introduce smb2srv_session_close_previous_cleanup()
This makes sure we cleanup the locked record in all cases.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
67af3586d9 s3:smbXsrv_client: only change the dbwrap_watch instance when the record has changed
This will become important in the following commits when the
dbwrap_watch layer will only wake up one watcher at a time
and each woken watcher will wakeup the next one.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
e33143099b s3:g_lock: try to keep the watch instance during g_lock_watch_data()
Unless the unique_lock_epoch changes via g_lock_lock()/g_lock_unlock()
we try to keep our existing watch instance alive while waiting
for unique_data_epoch to change.

This will become important in the following commits when the
dbwrap_watch layer will only wake up one watcher at a time
and each woken watcher will wakeup the next one. Without this
commit we would trigger an endless loop as none of the watchers
will ever change unique_data_epoch.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
20f3fd0219 s3:g_lock: remember an unique_lock_epoch similar to unique_data_epoch
It changes with every lock and unlock.

This will be needed in future in order to differentiate between
lock and data changed.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
2e92267920 s3:g_lock: avoid a lot of unused overhead using the new dbwrap_watch features
The key points are:

1. We keep our position in the watcher queue until we got what
   we were waiting for. It means the order is now fair and stable.

2. We only wake up other during g_lock_unlock() and only if
   we detect that an pending exclusive lock is able to make progress.
   (Note: read lock holders are never waiters on their own)

This reduced the contention on locking.tdb records drastically,
as waiters are no longer woken 3 times (where the first 2 times were completely useless).

The following test with 256 commections all looping with open/close
on the same inode (share root) is improved drastically:

  smbtorture //127.0.0.1/m -Uroot%test smb2.create.bench-path-contention-shared \
     --option='torture:bench_path=' \
     --option="torture:timelimit=60" \
     --option="torture:nprocs=256"

From some like this:

   open[num/s=50,avslat=6.455775,minlat=0.000157,maxlat=55.683846]
   close[num/s=50,avslat=4.563605,minlat=0.000128,maxlat=53.585839]

to:

   open[num/s=80,avslat=2.793862,minlat=0.004097,maxlat=46.597053]
   close[num/s=80,avslat=2.387326,minlat=0.023875,maxlat=50.878165]

Note the real effect of this commit will releaved together
with a following commit that only wakes one waiter at a time.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
5272051699 s3:g_lock: always call g_lock_cleanup_shared() before getting stuck on lck.num_shared != 0
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
b865bb28ab s3:g_lock: avoid calling g_lock_store() from g_lock_cleanup_dead()
This matches the behavior of g_lock_cleanup_shared(), which also
only operates on the in memory struct g_lock.

We do a g_lock_store() later during g_lock_trylock() anyway
when we make any progress.

In the case we where a pending exclusive lock holder
we now force a g_lock_store() if g_lock_cleanup_dead()
removed the dead blocker.

This will be useful for the following changes...

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
f62beaa2c2 s3:dbwrap_watch: allow callers of dbwrap_watched_watch_send/recv() to manage the watcher instances
The destructor triggered by dbwrap_watched_watch_recv() will
remove the watcher instance via a dedicated dbwrap_do_locked(),
just calling dbwrap_watched_watch_remove_instance() inside.

But the typical caller triggers a dbwrap_do_locked() again after
dbwrap_watched_watch_recv() returned. Which means we call
dbwrap_do_locked() twice.

We now allow dbwrap_watched_watch_recv() to return the existing
instance id (if it still exists) and removes the destructor.
That way the caller can pass the given instance id to
dbwrap_watched_watch_remove_instance() from within its own dbwrap_do_locked(),
when it decides to leave the queue, because it's happy with the new
state of the record. In order to get the best performance
dbwrap_watched_watch_remove_instance() should be called before any
dbwrap_record_storev() or dbwrap_record_delete(),
because that will only trigger a single low level storev/delete.

If the caller found out that the state of the record doesn't meet the
expectations and the callers wants to continue watching the
record (from its current position, most likely the first one),
dbwrap_watched_watch_remove_instance() can be skipped and the
instance id can be passed to dbwrap_watched_watch_send() again,
in order to resume waiting on the existing instance.
Currently the watcher instance were always removed (most likely from
the first position) and re-added (to the last position), which may
cause unfair latencies.

In order to improve the overhead of adding a new watcher instance
the caller can call dbwrap_watched_watch_add_instance() before
any dbwrap_record_storev() or dbwrap_record_delete(), which
will only result in a single low level storev/delete.
The returned instance id is then passed to dbwrap_watched_watch_send(),
within the same dbwrap_do_locked() run.

It also adds a way to avoid alerting any callers during
the current dbwrap_do_locked() run.

Layers above may only want to wake up watchers
during specific situations and while it's useless to wake
others in other situations.

This will soon be used to add more fairness to the g_lock code.

Note that this commit only prepares the api for the above to be useful,
the instance returned by dbwrap_watched_watch_recv() is most likely 0,
which means the watcher entry was already removed, but that will change
in the following commits.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
50163da309 s3:dbwrap_watch: remove a watcher via db_watched_record_fini()
The new dbwrap_watched_watch_remove_instance() will just remove ourself
from the in memory array and let db_watched_record_fini() call
dbwrap_watched_record_storev() in order to write the modified version
into the low level backend record.

For now there's no change in behavior, but it allows us to change it
soon....

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
2eb6a20949 s3:dbwrap_watch: use dbwrap_watched_record_storev() to add a new watcher
It means we only have one code path storing the low level record
and that's dbwrap_watched_record_storev on the main record.

It avoids the nested dbwrap_do_locked() and only uses
dbwrap_parse_record() and talloc_memdup() when needed.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
044e018e9a s3:dbwrap_watch: let dbwrap_watched_delete() call dbwrap_watched_record_storev(num_dbufs=0)
dbwrap_watched_record_storev() will handle the high level storev and
delete, it will find out if we can remove the record as there's no value
and also no watchers to be stored.

This is no real change for now as dbwrap_watched_record_wakeup() will
always exits with wrec->watchers.count = 0, but that will change in the next
commits.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
cc9c8b8e7e s3:dbwrap_watch: filter out records with empty payload during traverse
We will soon have records with just a number of watchers, but without
payload. These records should not be visible during traverse.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
1fb9db8c99 s3:dbwrap_watch: prepare dbwrap_watched_record_storev() to store watchers if requested
It will also delete the low level record in case there are no watchers
should be stored and no data buffers are given.

This is no real change for now as dbwrap_watched_record_wakeup() will
always exit with wrec->watchers.count = 0, but that will change in the next
commits.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
908eea1202 s3:dbwrap_watch: define/use DBWRAP_MAX_WATCHERS
dbwrap backends are unlikely to be able to store
UINT32_MAX*DBWRAP_WATCHER_BUF_LENGTH in a single record
and most likely also not with the whole database!

DBWRAP_MAX_WATCHERS = INT32_MAX/DBWRAP_WATCHER_BUF_LENGTH should be
enough and makes further changes easier as we don't need to care
about size_t overflows.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
2129d352ae s3:dbwrap_watch: remove unused dbwrap_watched_do_locked_state.status
This is never set...

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
8908af5695 s3:dbwrap_watch: let dbwrap_watched_watch_recv() use tevent_req_received()
At the end of the dbwrap_watched_watch_recv() all temporary state should
be destroyed. It also means dbwrap_watched_watch_state_destructor() was
triggered.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
1c84980d7c s3:dbwrap_watch: don't use talloc_tos() for messaging_filtered_read_recv()
Async function always have their 'state' context for temporary memory.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
39cdcec49c s3:dbwrap_watch: move db_record and db_watched_record to dbwrap_watched_do_locked()
This will help in the next commits.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
6b173bf156 s3:dbwrap_watch: split out a dbwrap_watched_watch_add_instance() helper
This will be used in other places soon.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
5021abff88 s3:dbwrap_watch: remove dbwrap_watched_record_wakeup_fn() indirection
This reduces quite some complexity and will make further changes
(which will follow soon) easier.

Review with git show --patience

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
6e45da1a38 s3:dbwrap_watch: also the fetch_locked case only needs to wake waiters just once
This is no change in behavior, because:

- The first dbwrap_do_locked(dbwrap_watched_record_wakeup_fn), is
  called at the start of dbwrap_watched_record_{storev,delete}().
  That means the nested dbwrap_do_locked() will pass the
  exact value same (unchanged) value to dbwrap_watched_record_wakeup_fn.

- After the first change we have either removed the whole backend
  record in dbwrap_watched_record_delete or dbwrap_watched_record_storev()
  removed all watchers and store num_watchers = 0.

- With that any further updates will have no watchers in the backend
  record, so dbwrap_do_locked(dbwrap_watched_record_wakeup_fn) will
  never do anything useful. It only burns cpu time any may cause memory
  fragmentation.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
726f468ccd s3:dbwrap_watch: split out db_watched_record_fini() from db_watched_record_destructor()
That makes it easier to understand that db_watched_record_init() and
db_watched_record_fini() wrap any caller activity on the record,
either during do_locked or between fetch_locked and the related
destructor.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
eb89748ee4 s3:dbwrap_watch: split out a db_watched_record_init() helper function
The code to construct a struct db_watched_record is mostly common
between dbwrap_watched_fetch_locked() and dbwrap_watched_do_locked_fn().

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
095fafbe0c s3:dbwrap_watch: remove unused dbwrap_watched_do_locked_{storev,delete}()
dbwrap_watched_do_locked_{storev,delete}() was now exactly the
same as dbwrap_watched_{storev,delete}().

We only need to know if dbwrap_watched_record_wakeup() is called from
within dbwrap_watched_do_locked_fn().

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
c0febbd3e1 s3:dbwrap_watch: move the do_locked optimization to dbwrap_watched_record_wakeup()
Both dbwrap_watched_record_storev() and dbwrap_watched_record_delete()
call dbwrap_watched_record_wakeup() as their first action.

So the behavior stays the same, but dbwrap_watched_do_locked_storev()
and dbwrap_watched_do_locked_delete() are not trivial and we
have the wakeup logic isolated in dbwrap_watched_record_wakeup() only.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
2342489f52 s3:dbwrap_watch: add db_record_get_watched_record() helper
This allows safe casting off rec->private_data to get
struct db_watched_record. And that works fetch_locked and do_locked

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00
Stefan Metzmacher
b3f6668f93 s3:dbwrap_watch: use backend.{rec,initial_value} instead of subrec[_value]
This makes it much clearer to me what it actually is.

Keeping the initial_value with struct db_watched_record will also
simplify further changes.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
2022-07-26 13:40:34 +00:00