samba.git/lib/tdb/common, branch talloc-2.4.3

tdb: allow tracing of internal tdb

2024-07-27T22:47:39+00:00

This will trace internal databases to files like this:

tdb_0x5da896b51870.trace.267290

We avoid strlen(name) because name could be NULL in this case (which
works fine with glibc but feels bad).

Signed-off-by: Douglas Bagnall 
Reviewed-by: Stefan Metzmacher

tdb: fix compilation with TDB_TRACE=1

2024-07-27T22:47:39+00:00

../../lib/tdb/common/tdb.c: In function ‘tdb_trace_record’:
../../lib/tdb/common/tdb.c:1224:22: error: ‘snprintf’ output truncated before the last format character [-Werror=format-truncation=]
 1224 |                 p += snprintf(p, 2, %02x, rec.dptr[i]);
      |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/tdb/common/tdb.c:1224:22: note: ‘snprintf’ output 3 bytes into a destination of size 2
cc1: all warnings being treated as errors

Signed-off-by: Douglas Bagnall 
Reviewed-by: Stefan Metzmacher

tdb: Update times in tdb_transaction_commit per fd, not per name

2024-06-24T16:21:32+00:00

We might have a relative filename in tdb->name, so we might do the
wrong thing here. And as we have the fd, why not use it...

We call futimens in vfs_default without #ifdef and it's Posix 2018 or
before. So I don't think we need to check for it.

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

tdb: Fix a typo

2024-06-24T16:21:32+00:00

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

tdb: Do not pass non–null‐terminated strings to strcmp() (CID 1449485)

2023-10-13T02:18:30+00:00

Signed-off-by: Joseph Sutton 
Reviewed-by: Andrew Bartlett

tdb: Fix code spelling

2023-09-11T02:42:41+00:00

Signed-off-by: Joseph Sutton 
Reviewed-by: Andrew Bartlett

lib:tdb: Fix code spelling

2023-04-14T05:25:33+00:00

Signed-off-by: Andreas Schneider 
Reviewed-by: Joseph Sutton

tdb: Move 160 bytes from R/W data segment to R/O text

2022-12-15T21:52:34+00:00

The linker has to relocate the pointers in the array at startup, save
that. I know we have bigger .data blobs, but every bit counts :-)

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

tdb: Use atomic operations for tdb_[increment|get]_seqnum

2021-12-15T00:15:33+00:00

With locking.tdb now based on g_lock.c code, we change locking.tdb a
lot more often. I have a customer case where LDX tortures smbd very
hard with 800+ concurrent connections, which now completely falls over
where 4.12 still worked fine. Some debugging showed a thundering herd
on fcntl locking.tdb index 48 (TDB_SEQNUM_OFS). We still use fcntl for
the seqnum, back when we converted the chainlocks to mutexes we did
not consider it to be a problem. Now it is, but all we need to do with
the SEQNUM is to increment it, so an __atomic_add_fetch() of one is
sufficient.

I've taken a look at the C11 standard atomics, but I could not figure
out how to use them properly, to me they seem more general to be
initialized first etc. All we need is a X86 "lock incl 48(%rax)" to be
emitted, and the gcc __atomic_add_fetch seems to do this.

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

lib:tdb: Fix a memory leak on error

2021-07-08T09:30:40+00:00

Found by covscan.

Signed-off-by: Andreas Schneider 
Reviewed-by: Stefan Metzmacher