samba.git/source3/locking, branch talloc-2.4.0

lib: Use tdb_data_dbg() where appropriate

2023-01-10T00:28:37+00:00

This changes the talloc hierarchy for a few callers, but as
talloc_tos() was initially designed exactly for this purpose (printing
SIDs in DEBUG), it should be okay.

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

smbd/locking: make use of the same tdb hash_size and flags for all SMB related tdb's

2022-12-19T16:40:15+00:00

It's good to have a consistent set of hash_size/flags for all aspects of
an open file handle. Currently we're using 4 databases:
smbXsrv_open_global.tdb, leases.tdb, locking.tdb and brlock.tdb.

While at it also crank up the hashsize if the smbXsrv_tcon and smbXsrv_session
TDBs. The default TDB hash size is insanely small and disk space is cheap these
days, by going with the much larger hash size we get O(1) lookup instead of O(n)
for moderate to large loads with a few thousand objects.

Signed-off-by: Stefan Metzmacher 
Reviewed-by: Ralph Boehme 

Autobuild-User(master): Stefan Metzmacher 
Autobuild-Date(master): Mon Dec 19 16:40:15 UTC 2022 on sn-devel-184

smbd: Remove source3/smbd/statcache.c

2022-12-14T22:54:29+00:00

After I found that nobody calls stat_cache_add() anymore, there was no
reason to keep the rest of statcache.c.

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

s3:locking: split out del_share_mode_open_id()

2022-12-09T23:11:38+00:00

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

s3/locking: Revert "s3:locking: Remove dead code"

2022-12-09T23:11:38+00:00

This reverts commit de493a3e3b5b8d54f62c45072e27f2fefd4af43a:

    s3:locking: Remove dead code

    Found by Coverity.

    Signed-off-by: Andreas Schneider 
    Reviewed-by: Isaac Boukris 

dbwrap_do_locked() correctly returns saved_errno which is a possible
errno returned by close() inside fd_close_posix_fn().

Signed-off-by: Ralph Boehme 
Reviewed-by: Jeremy Allison

s3:locking: re-add saved_errno handling to fd_close_posix()

2022-12-09T23:11:37+00:00

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

s3:locking: relax __SHARE_MODE_LOCK_SPACE check for 32bit platforms

2022-11-24T11:01:37+00:00

sizeof(struct share_mode_lock) is only 28 bytes instead of 32 bytes
on 32bit systems...

Signed-off-by: Stefan Metzmacher 
Reviewed-by: Volker Lendecke

s3:locking: remove unused get_share_mode_lock()

2022-09-20T01:34:55+00:00

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

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

Autobuild-User(master): Jeremy Allison 
Autobuild-Date(master): Tue Sep 20 01:34:55 UTC 2022 on sn-devel-184

s3:locking: add share_mode_entry_prepare_{lock,unlock}() infrastructure

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

When adding or deleting share mode entries elements, we typically
have a pattern like this:

1. get the g_lock via get_[existing_]share_mode_lock()
2. do some checking of the existing record
3. add/delete a share_mode_entry to the record
4. do some vfs operations still protected by the g_lock
5. (optional) cleanup of the record on failure
6. release the g_lock

We can optimize this to:

- Run 1-3. under a tdb chainlock
- Only protect vfs operations with the g_lock
  if a new file was created/will be deleted
- Regrab the g_lock for a cleanup.

The new share_mode_entry_prepare_lock()
allows the caller to run a function within a tdb chainlock
similar to share_mode_do_locked_vfs_denied() where vfs calls are denied
and the execution is done within a tdb chainlock.

But the callback function is allowed to decide if it wants to
keep the lock at the g_lock layer on return.

The decision is kept in struct share_mode_entry_prepare_state,
which is then passed to share_mode_entry_prepare_unlock()
with an optional callback to do some cleanup under the
still existing g_lock or a regrabed g_lock.

In the ideal case the callback function passed to
share_mode_entry_prepare_lock() is able to decide that
it can drop the g_lock and the share_mode_entry_prepare_unlock().
gets a NULL callback as there's nothing to cleanup.
In this case share_mode_entry_prepare_unlock() is a noop.

This will allow us to avoid fallbacks to the dbwrap_watch based
waiting for the g_lock in the SMB2 Create and Close code paths.

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

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

s3:locking: optimize share_mode_do_locked_vfs_denied() with g_lock_lock callback

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

It means that in callers function will run under a single tdb chainlock,
which means callers from the outside will never see the record being
locked at g_lock level, as the g_lock is only held in memory.
within the single tdb chainlock. As a result we'll very unlikely hit
the case where we need to wait for a g_lock using the dbwrap_watch
logic.

Review with: git show -w

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

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