IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This fixes one possible trigger for "PANIC: assert failed in get_lease_type()"
https://bugzilla.samba.org/show_bug.cgi?id=14428
This is no longer enough to remove the record:
d->have_share_modes = false;
d->modified = true;
Note that we can remove it completely from
share_mode_cleanup_disconnected() as
share_mode_forall_entries() already sets it
when there are no entries left.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14428
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
When cleanup_disconnected_lease() fails we should stop,
at least we do that if brl_cleanup_disconnected() fails.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14428
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
share_mode_entry_do(), share_mode_forall_entries() and
share_entry_forall() print the record before the callback is called
and when it was modified or deleted.
This makes it much easier to debug problems.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14428
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
It's not really clear why e.stale would be ignored if *modified is set
to true.
This matches the behavior of share_mode_entry_do()
This also makes sure we see the removed entry in level 10 logs again.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14428
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
This reproduces the origin of "PANIC: assert failed in get_lease_type()"
(https://bugzilla.samba.org/show_bug.cgi?id=14428).
share_mode_cleanup_disconnected() removes disconnected entries from
leases.tdb and brlock.tdb but not from locking.tdb.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14428
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Instead of a sequence number that gets incremented we just
need a value that's not reused.
The is a similar change like the commit before at the g_lock.c
layer.
I expect a similar performance improvement here, but
I don't know a specific benchmark test to check.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
detected by covscan:
source3/locking/share_mode_lock.c:1563:6: warning: Branch condition evaluates to a garbage value
Signed-off-by: Isaac Boukris <iboukris@samba.org>
Reviewed-by: David Mulder <dmulder@suse.com>
Autobuild-User(master): Isaac Boukris <iboukris@samba.org>
Autobuild-Date(master): Tue Jun 30 09:42:33 UTC 2020 on sn-devel-184
The "base on g_lock" patch is a slowdown because we do more tdb
operations. Getting share_entries.tdb back into locking.tdb tries to
speed things up again.
Now that we're based on g_lock we'll most likely use a different
method in order to spread the entries across multiple records.
It still maintains the sorted array of share modes within locking.tdb,
but not as part of the expensive ndr marshalling of the complete
array.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Fri May 15 02:27:49 UTC 2020 on sn-devel-184
This means we don't hold locking.tdb mutexes anymore while we do
filesystem-level operations. This has hurt ctdb quite a bit: A smbd hanging in
an unlink() syscall prevents ctdb from recovering locking.tdb.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is needed to prime the logic in share_mode_flags_restrict() for the
following scenario:
* (First) CREATE on a file with FILE_SHARE_NONE and
access_mask=FILE_READ_ATTRIBUTES (a stat-open).
* share_mode_flags_restrict() gets called with
share_mode_flags_restrict(flags=0,
access_mask=0x80,
share_mode=0,
lease_type=UINT32_MAX)
and returns a value where none of the FILE_SHARE_* flags is set.
As a result share_mode_data.flags doesn't reflect the share-modes in effect.
This doesn't change any current visible behaviour outside of open_mode_check(),
but it avoids calling share_mode_forall_entries() in open_mode_check_fn().
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14375
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Tue May 12 19:52:48 UTC 2020 on sn-devel-184
"num_share_modes" is passed separately, so "data.dsize" was not used
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Tue May 5 13:23:49 UTC 2020 on sn-devel-184
This has more lines, but it's a lot simpler: reset_share_mode_entry is
only called during durable reconnect, which only works with a single
share mode entry. See durable_reconnect_fn(). Thus we don't have to
keep the share mode array sorted, there is just a single entry.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
If we don't use a DATA_BLOB, we can more correctly state in the
prototype that the buffer we parse is constant.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Wed Dec 18 00:05:13 UTC 2019 on sn-devel-184
With the last commit we don't store the share mode entry count
anymore. With this commit we go one step further and avoid storing
it. If there's valid record in locking.tdb, there is a corresponding
record in share_entries.tdb, so there's no point storing that once
more explicitly.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is a micro-commit showing that we don't actually need
share_mode_data->num_share_modes as a number *counting* the share mode
entries in share_entries.tdb anymore. Instead, we are only using it as
an indication for share_mode_lock_destructor() to see whether share
entries are around or not, i.e. whether it's worth keeping or deleting
the record in locking.tdb.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This hides a use of share_mode_data->num_share_modes in
share_mode_lock.c
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
share_mode_data->num_share_modes will go away soon, count the values
directly while walking the array.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
mark_share_mode_disconnected_fn() will need this, the information is
easily available and should not hurt the other callers.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
In order to not write the share mode on every open/close, we need to get rid of
share_mode_data->num_share_modes. "net tdb" needs this information precisely
though, and it's pretty cheap to calculate.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We don't need to unparse the locking.tdb record, we just need to wake
up waiters when removing an oplock
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Mon Dec 16 20:27:59 UTC 2019 on sn-devel-184
If we set e->stale=true in the share_mode_forall_entries() callback,
the share entry will be removed directly. Thus further down
share_mode_forall_leases() won't find anything anymore. Only find
possibly still connected entries in the first walk, and then remove
the share_entries.tdb record straight away after the leases and
brlocks have been removed.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Dec 10 21:57:05 UTC 2019 on sn-devel-184
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Mon Dec 9 17:33:42 UTC 2019 on sn-devel-184
Hopefully dbwrap_tdb's dbwrap_exists is cheap enough for this to not
impact performance too much. I could not measure any difference in an
open/close benchmark, but at some point things might pile up and we
might have to make this a #ifdef DEVELOPER
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This implements two core changes:
* use NTTIME instead of struct timespec at the database layer
* use struct timespec { .tv_nsec = SAMBA_UTIME_OMIT } as special sentinel
value in smbd when processing timestamps
Using NTTIME at the database layer is only done to avoid storing the special
struct timespec sentinel values on disk. Instead, with NTTIME the sentinel value
for an "unset" timestamp is just 0 on-disk.
The NTTIME value of 0 gets translated by nt_time_to_full_timespec() to the
struct timespec sentinel value { .tv_nsec = SAMBA_UTIME_OMIT }.
The function is_omit_timespec() can be used to check this.
Beside nt_time_to_full_timespec(), there are various other new time conversion
functions with *full* in their name that can be used to safely convert between
different types with the changed sentinel value.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=7771
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The call to get_static_share_mode_data() is identical in the if/else branches,
so move it behind them.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Thu Dec 5 20:12:23 UTC 2019 on sn-devel-184
For now this is a simple wrapper around dbwrap_watched_watch_send()
that will make the direct db_record reference in struct
share_mode_data unnecessary.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This makes a copy of the record values TDB_DATA.
In this case, it is okay: We only do a dbwrap_record_storev modifying
the value that we retrieved from the share_mode_lock destructor.
This patch is necessary because the next commit will make the "value"
argument to the dbwrap_do_locked() callback the only source of the
record value. Thus for a nested share_mode_do_locked() call we have to
maintain the record value explicitly.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
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 <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
No callback used (and should not use) the record directly, this is all
handled within share_mode_lock.c
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Wed Nov 13 21:41:09 UTC 2019 on sn-devel-184
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Thu Oct 10 01:04:33 UTC 2019 on sn-devel-184
