samba.git/lib/dbwrap/dbwrap.c, branch talloc-2.4.0

lib/dbwrap: allow dbwrap_merge_dbufs() to update an existing buffer

2022-09-20T00:34:35+00:00

This will be useful in future...

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

Signed-off-by: Stefan Metzmacher 
Reviewed-by: Jeremy Allison

lib/dbwrap: reset deleted record to tdb_null

2021-11-04T19:49:47+00:00

This allows the calling the following sequence of dbwrap functions:

  dbwrap_delete_record(rec);
  data = dbwrap_record_get_value(rec);

without triggering the assert rec->value_valid inside dbwrap_record_get_value().

Note that dbwrap_record_storev() continues to invalidate the record, so this
change somewhat blurs our semantics.

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

Signed-off-by: Ralph Boehme 
Reviewed-by: Volker Lendecke 

Autobuild-User(master): Jeremy Allison 
Autobuild-Date(master): Thu Nov  4 19:49:47 UTC 2021 on sn-devel-184

dbwrap: Remove unused dbwrap_try_fetch_locked()

2021-06-04T16:47:34+00:00

Small simplification, this has not been used since 2014 when the
notifyd went in. Can easily be added if needed again.

Signed-off-by: Volker Lendecke 
Reviewed-by: Jeremy Allison

dbwrap: Make dbwrap_lock_order_[un]lock() public

2020-05-15T00:48:32+00:00

Signed-off-by: Volker Lendecke 
Reviewed-by: Jeremy Allison

dbwrap: Simplify dbwrap_lock_order_[un]lock()

2020-05-15T00:48:32+00:00

Directly pass the database name and lock order to the core functions,
avoid passing struct db_context.

In the next steps these functions will become public: locking.tdb will
be based on g_lock.c to avoid holding a tdb-level locking.tdb mutex
while doing complex file system operations like unlink() which can
take ages on FAT for example.

This means that g_lock.c will participate in the dbwrap lock order
protection and needs access to dbwrap_lock_order_[un]lock() without
providing a direct db_context.

Signed-off-by: Volker Lendecke 
Reviewed-by: Jeremy Allison

dbwrap: Don't set rec->value in dbwrap_do_locked()

2019-11-22T23:57:46+00:00

We pass that via the callback now

Signed-off-by: Volker Lendecke 
Reviewed-by: Jeremy Allison

dbwrap: Protect against invalid db_record->value

2019-11-22T23:57:46+00:00

After dbwrap_record_storev()/delete(), dbwrap_record_get_value()
information is stale. Assert on the attempt to re-fetch data after it
became stale. This can't protect against someone copying the result
from dbwrap_record_get_value() somewhere else, but it's better than
nothing.

Signed-off-by: Volker Lendecke 
Reviewed-by: Jeremy Allison

dbwrap: Pass "value" to dbwrap_do_locked() callback

2019-11-22T23:57:46+00:00

I want to reduce dbwrap_record_get_value(). It makes the caller believe it can
make a copy of the TDB_DATA returned and that the value remains constant. It's
not, as you can always do a dbwrap_record_store().

This patch removes one requirement for getting the value out of a
db_record via dbwrap_record_get_value(). You can still make a copy, but from an
API perspective to me it's more obvious that "value" as a parameter to the
callback has a limited lifetime.

Signed-off-by: Volker Lendecke 
Reviewed-by: Jeremy Allison

dbwrap: Initialize state in dbwrap_delete()

2019-09-10T23:14:31+00:00

Probably not required, but looks safer and gives static checkers less
reason to complain about potentially uninitialized variable reads

Signed-off-by: Volker Lendecke 
Reviewed-by: Jeremy Allison

lib/dwrap: Fix 'Null pointer passed as an argument to a 'nonnull' parameter '

2019-06-26T10:30:23+00:00

Fixes:

lib/dbwrap/dbwrap.c:645:4: warning: Null pointer passed as an argument to a 'nonnull' parameter <--[clang]
                        memcpy(p, dbufs[i].dptr, thislen);

Signed-off-by: Noel Power 
Reviewed-by: Gary Lockyer