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>
There're typically better ways to get the same information.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11897
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Günther Deschner <gd@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
This will contain a summary of the "most restrictive" share mode and
lease, i.e. intersection of all share_access entries and the union of
all access_mask and leases in the share mode array. This way
open_mode_check in the non-conflicting case will only have to look at
the summary and not walk the share mode array.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This moves share_modes[] from "struct share_mode_data" into a separate
share_entries.tdb with a sorted array of fixed-length (132 byte)
"struct share_mode_entry" entries.
I know it's one huge commit, but I did not see a way to keep both data
structures and associated code working together without a lot of code
duplication after having centralized all the code accessing the
share_modes[] array into a few routines.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Previously, we did this only when writing out the locking.tdb
record. That was because we had places where the index of a particular
share mode entry mattered while operating on the array. This is no
longer the case, so we can remove stale entries early.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Avoid the full fsp, this makes the indexing of the share mode array
clearer, and it makes the next commit easier
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Why? Next commit will make share_mode_forall_leases() use
share_mode_forall_entries(), and that does not necessarily have to
depend on "share_mode_lock". And as we can pass the required
information via "private_data", don't embed the "share_mode_lock"
reference into this lowlevel library routine.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Abstract away the fact that we store the share modes as an array inside
"struct share_mode_data".
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The same lease can be used via different TCP connections (yes, we have
tests for this!). At the end of downgrade_lease() we update all fsp's
with fsps_lease_update() that link to the lease that just was
changed. However, this is only in the local process, this is not
cross-smbd. So other smbds using the same lease can use stale
information and for example get the mandatory locking wrong.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Less explicit talloc. Right now dbwrap_rbt behind the scenes does a
dbwrap_fetch_locked(), but that will eventually change.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The routine isn't called find__delete_on_close_token. Also avoid
casts.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This allows the vfs backend to detect a retry and keep state between
the retries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14113
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Returning NT_STATUS_FILE_LOCK_CONFLICT is a SMB1 only detail
for delayed brlock requests, which is handled in
smbd_smb1_do_locks*().
The brlock layer should be consistent even for posix locks.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14113
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
They implement the logic from [MS-FSA].
The following commits will use these functions in other locations.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14113
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Directly initialized variables give compilers less reason to complain
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Böhme <slow@samba.org>
remove_lease_if_stale() does not have the check
if (e == e2) {
/* Not ourselves. */
continue;
}
that remove_share_mode_lease() had. However, remove_share_mode_lease()
has already set e->op_type=NO_OPLOCK, so that the
if (e->op_type != LEASE_OPLOCK) {
continue;
}
statement has the same effect.
Why? The next commit will need it for proper error path cleanup.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The fsp carries all required information also for leases. There's no
need to pass that as additional parameters
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Yes, this adds another peek from locking/ back into smbd/proto.h, but
locking/locking.c does the same already.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Makes the interface more obvious to me. Also, I want to remove
fsp->share_access, which is not really used anywhere after the fsp has
been fully established.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is not a real error, it happens when the share mode record is not
around.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Uri Simchoni <uri@samba.org>
This removes a kludgy implementation that worked around a locking
hierarchy problem: Setting a byte range lock had to contend the level2
oplocks, which are stored in locking.tdb/leases.tdb. We could not
access locking.tdb in the brlock.tdb code, as brlock.tdb might have
been locked first without locking.tdb, violating the locking hierarchy
locking.tdb->brlock.tdb. Now that that problem is gone (see the commit
wrapping do_lock() in share_mode_do_locked()), we can remove this
kludge.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
This caches share_mode_data->flags in the fsp, cache flush happening
on tdb_seqnum change.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
They are put at the beginning for easy parsing without reading the
full struct. First step to remove the number of read oplocks/leases
from brlock.tdb, where it does not belong.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
We need to maintain the locking hierarchy locking.tdb->brlock.tdb at
all times. vfs_fruit directly calls do_lock(), which might fail to
maintain the locking hierarchy: In brlock.c we call
contend_level2_oplocks_begin(), which will soon look at the
locking.tdb record.
For the SMB1 and SMB2 callers we already have the share mode locked,
we might want to watch that record for unlocks. For those callers
share_mode_do_locked() is practically free to call, we share the
underlying db_record.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
This is made for efficient locking of share mode records in
locking.tdb. Right now we already need that when accessing leases.tdb,
and soon it will be required for brlock.tdb as well. It does not give
direct access to the parsed share mode entry, but the record is
available for dbwrap_watched_wakeup() within downgrade_lease().
It can be freely nested with get_share_mode_lock calls, the record
will be shared and proper nesting should be checked.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
The next commit will introduce share_mode_do_locked(), which allocates
a share mode record on the stack. We have to expect nested
get_share_mode_lock() calls from within share_mode_do_locked() for
which we need to share a db_record.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Do explicit refcounting instead of talloc_reference(). A later patch
will introduce a share_mode_do_locked() routine that can be nested
arbitrarily with get_share_mode_lock(). To do sanity checks for proper
nesting, share_mode_do_locked needs to be aware of the reference
counts for "static_share_mode_lock".
Why is share_mode_memcache_delete() gone? In parse_share_modes() we
already move the data out of the cache, share_mode_lock_destructor()
we don't even bother re-adding the share_mode_data to the cache if
it does not have share entries, because the next opener will invent a
new seqnum anyway.
Also: Less talloc_reference(), less lines of code.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
This routine did a NO-GO: It returned something on talloc_tos(), for
later consumption by push_blocking_lock_request. This is now gone, no
caller uses the "struct byte_range_lock" returned anymore.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This should have been in f11c5887f4, sorry. We now always need
TDB_SEQNUM on brlock.tdb.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
This is not called anymore, bump the VFS version number in a separate
commit
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 Jun 20 18:34:20 UTC 2019 on sn-devel-184
This is now handled in smbd_smb1_do_locks_send/recv.
From here on for a few commits we won't survive make test.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Quite a few callers set "psmblctx" to NULL, and I could not really
follow 100% that brl_lock only assigns that in the blocking lock
case. Too many layers :-)
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Soon we will wait on a conflicting lock to become free via
dbwrap_watched_watch_send. That routine can take a server_id that
blocks us, watching it to go away. To use that, we need to know which
PID it is that blocks us.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Just reformatting, no behaviour change. This just looked too ugly to me.
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 May 28 22:22:28 UTC 2019 on sn-devel-184
With e7424897a1 we don't need this special case for clustering
anymore.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
