| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Only retry when ctdbd_persisten_update() failed.
Michael
(This used to be commit ff413a4614c8b272a34b2a9e56a329a8e8749a34)
|
|
store.
Michael
(This used to be commit eaf76c751f9bde2843174b400c109304831df83e)
|
|
as delete_rec operation from fetch_locked()
Michael
(This used to be commit f4aab595a0219305fbedf8890e787b690660a55a)
|
|
to reduce code duplication.
Michael
(This used to be commit 09a197e756459877cab7b4d09f534c6a41cfdd71)
|
|
This is because ctdbd can fail in performing the persistent_store
due to race conditions, and this does not mean it can't succeed
the next time.
To not loop infinitely, this makes use of a new parametric option:
"dbwrap ctdb:max store retries" (integer) which defaults to 5
and sets the upper limit for the number or repeats of the
fetch/store cycle.
Michael
(This used to be commit 2bcc9e6ecef876030e552a607d92597f60203db2)
|
|
in the persistent db_ctdb_store operation.
This is to prevent deadlocks in db_ctdb_persistent_store().
There is a tradeoff: Usually, the record is still locked
after db->store operation. This lock is usually released
via the talloc destructor with the TALLOC_FREE to
the record. So we have two choices:
- Either re-lock the record after the call to persistent_store
or cancel_persistent update and this way not changing any
assumptions callers may have about the state, but possibly
introducing new race conditions.
- Or don't lock the record again but just remove the
talloc_destructor. This is less racy but assumes that
the lock is always released via TALLOC_FREE of the record.
I choose the first variant for now since it seems less racy.
We can't guarantee that we succeed in getting the lock
anyways. The only real danger here is that a caller
performs multiple store operations after a fetch_locked()
which is currently not the case.
Michael
(This used to be commit d004c9a7281d2577c3ba2012c8f790cc198ea700)
|
|
Michael
(This used to be commit c939c55e5182258092faceefa58a7f328f18619e)
|
|
database in an inconsistent state if we crash during the operation
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
(This used to be commit 09329f1f9114af44fc4e5e4f29a7315912313125)
|
|
(This used to be commit 549db133df6782bcca7d033e8573e47716877cbd)
|
|
With the ctdb checkin dde9f3f006 tdb optimized out write lock checks for
write-enabled transaction. Sadly, this also removed the possibility to ever
remove dead records left over from tdb_delete calls within a transaction.
Tridge, please check this! Did dde9f3f006 have any reason beyond performance
optimizations?
Thanks,
Volker
(This used to be commit 3f884c4ae36f3260e63626bdd4989d9258ae6497)
|
|
Here is a patch to allow many subsystems to be re-initialized. The only
functional change I made was to remove the null context tracking, as the memory
allocated here is designed to be left for the complete lifetime of the program.
Freeing this early (when all smb contexts are destroyed) could crash other
users of talloc.
Jeremy.
(This used to be commit 8c630efd25cf17aff59448ca05c1b44a41964b16)
|
|
one of our virtualised functions, such as db_open(), but error is only
set when a system call fails, and it is not uncommon for us to fail a
function internally without ever making a system call. That led to us
passing back success when a function had in fact failed.
I found two places where we relied on map_nt_error_from_unix()
returning success when errno==0, but lots and lots of places where we
relied on the reverse, so I fixed those two places.
map_nt_error_from_unix() will now always return an error, returning
NT_STATUS_UNSUCCESSFUL if errno is 0
(cherry picked from commit 69d40ca4c1af925d4b0e59ddc69ef8c26e6501d1)
(This used to be commit 834684a524a24bb4eb46b4af583d39947dc87d95)
|
|
for one
(This used to be commit 469ba9b87103aa0053c371e481acc5acf0f98ac1)
|
|
Guenther
(This used to be commit 4fea49ae83510225c51c580a2bea2c664851bb39)
|
|
Guenther
(This used to be commit b2a413148e470e059c877f4e54955ab61559edee)
|
|
Guenther
(This used to be commit 01c4640b1ca66c3285fd23d447d08db12cf83b42)
|
|
Guenther
(This used to be commit bb52ba58e47364d7c7ed38862a007e8e3d9dc104)
|
|
Guenther
(This used to be commit bd31d8f9ec9a24ca68e1d5441c0cafd98132060f)
|
|
Guenther
(This used to be commit 53dc9a11810b93a1771304fbfbf4ae84f551612b)
|
|
Guenther
(This used to be commit d4a51bb01d33ad17db4e623085a89d258e91b57e)
|
|
Guenther
(This used to be commit 563fb06107d2d3279e08c5c801a940f03229131b)
|
|
Guenther
(This used to be commit a9c444a342968b539918c082b78af8640f8c87cd)
|
|
Guenther
(This used to be commit bb345187b7c62e9ad214037120545addd87a666d)
|
|
Guenther
(This used to be commit 7f7e6ca9091101aa7a3dc275c1d0258d97743f4b)
|
|
Guenther
(This used to be commit 316575b412e19008ecb6729f97e93b6103d8ba56)
|
|
Guenther
(This used to be commit b4c912bfbc62768ff4d7ecb39c02dc4a2a9825d2)
|
|
Guenther
(This used to be commit 5648145bec3bd24ecedea24a8834ac6768bfc640)
|
|
Guenther
(This used to be commit 99cc8f023b4ad9210b677e11371f404048752031)
|
|
Guenther
(This used to be commit 36f1e45e4ec295115f1ba39ec7ad3690a96dac3e)
|
|
(This used to be commit 3d4e7b29c235e329aaea4fa2c2078df0ce3e59eb)
|
|
(This used to be commit 59136544ec16b6ceb14a75259aedd22856832bf1)
|
|
Michael
(This used to be commit 742bedce417c666b5e91d8d0a7dc7682dc62eba2)
|
|
Michael
(This used to be commit 1b2dec93b635dfd23af78a370c223ea2dd486aa7)
|
|
subroutine in lib/replace/replace.c
(This used to be commit 13b1a232d2fe05ae3e924ea2503d05ff5084146e)
|
|
To be used later :-)
(This used to be commit 0d161d336ab9eeccd90d19ef1473646c3008864a)
|
|
auth_errors array initialization in client/smbspool.c
(This used to be commit b45e7fabc64e699e4fa013ef15f98a004dae3f32)
|
|
(This used to be commit 123fc3980a83d956bffaa689f3af81bbf81ce1c1)
|
|
Michael
(This used to be commit f8f21c8e3922806230e240cb54205fc2db7a3619)
|
|
This is a regression introduced by the change to dbwrap.
The replacement dbwrap_change_int32_atomic() does not
correctly mimic the behaviour of tdb_change_int32_atomic():
The intended behaviour is to use *oldval as an initial
value when the entry does not yet exist in the db and to
return the old value in *oldval.
The effect was that:
1. get_rand_seed() always returns sys_getpid() in *new_seed
instead of the incremented seed from the secrets.tdb.
2. the seed stored in the tdb is always starting at 0 instead
of sys_getpid() + 1 and incremented in subsequent calls.
In principle this is a security issue, but i think the danger is
low, since this is only used as a fallback when there is no useable
/dev/urandom, and this is at most called on startup or via
reinit_after_fork.
Michael
(This used to be commit bfc5d34a196f667276ce1e173821db478d01258b)
|
|
Michael
(This used to be commit 7edfb54c865ddcfd5cdcc8c2184b96aaac2d2ec0)
|
|
The race is a regression introduced by the change to dbwrap.
It might have led to two concurrent processes returning the same id.
This fix is achieved by changing dbwrap_change_uint32_atomic() to
match the original behaviour of tdb_change_uint32_atomic(), which
is the following: *oldval is used as initial value when
the value does not yet exist and that the old value should be
returned in *oldval.
dbwrap_change_uint32_atomic() is used (only) in idmap_tdb2.c,
to get new ids.
Michael
(This used to be commit 72bd83fea7572a6202027b200d192c05023aa633)
|
|
Guenther
(This used to be commit 7e9fa2c5396d3663e83ffbf90475473fdb509871)
|
|
Jeremy.
(This used to be commit 1db7e00a5400863fd5dbb81c1a4c6ea6092d0495)
|
|
Guenther
(This used to be commit 0298f7fe9e273a94d14b5b6ce3dbd5e6deee9ecb)
|
|
Guenther
(This used to be commit d31f822b79ed5344ec3c6795d66ceefd024b7d30)
|
|
GUenther
(This used to be commit 0b4e2687ae8fb48faacceb4078d61f9fd2acea9d)
|
|
Guenther
(This used to be commit 52218506d6ad51c4f340206d035f79272ba15e3b)
|
|
Guenther
(This used to be commit 80957bc1bc1462a2478b3eea64f5cb7a84d08677)
|
|
Guenther
(This used to be commit 97106199f1a2add886a14523aa7b402667d2cd89)
|
|
Guenther
(This used to be commit ff9bcd57738aa04c5e18e0e21dd0e788127317c4)
|
