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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We can use reset_share_mode_entry() for this purpose. 32 lines less
code.
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 Aug 6 18:09:06 UTC 2021 on sn-devel-184
The "return" is unnecessary here, but in case the code changes later
on, it won't be forgotten. Also, we need to tell the callers that we
found an invalid record.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Looking at the logic of "ha[d|ve]_share_mode_entry" d->modified=true
can only happen if we remove the last share mode entry . Make this
more explicit, avoid booleans.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This situation should never happen!
The known trigger is fixed with the change to adouble_open_rsrc_fsp()
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
It's a bit shocking how many references we have to global
contexts. Make this a bit more obvious.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Nobody in share_mode_lock.c looked at that value anymore, so we don't
need to manually maintain it.
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 Dec 4 22:32:38 UTC 2020 on sn-devel-184
Rely on the truth in locking.tdb wrt existence of share entries
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Rely on the truth in the database whether we found share modes or
not, share_mode_data_store() has that information for free.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Take a struct file_id instead of a locking.tdb key,
share_mode_memcache_store() also operates on the implicit fid in
struct share_mode_data.
To do this, parse_share_modes() also needs to take file_id.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This makes "struct share_mode_lock" an opaque data structure opened up
only to the code in locking/. This makes it much safer to modify the
data structure with defined accessor functions in 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): Tue Nov 10 21:12:48 UTC 2020 on sn-devel-184
These routines parse and marshall the uint16 summary flag in
share_mode_data. open_file_ntcreate() and open_directory() are the
only real users of this. The user in oplock.c is just the lazy reset
of the "read lease exists somewhere" after asynchronously breaking
read oplocks after a write request.
This moves handling the flags into locking/ to consolidate data
structure handling of "share_mode_data" there.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is a special case for net tdb dump. The alternative would be to
change the net tdb dump behaviour.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This function is only called from
vfs_default_durable_reconnect(). It is really the lower-level routine
that triggers the write of the locking.tdb record.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reduce the complexity of share_mode_lock.c, scavenger.c is the only
user of this routine.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
To me this is then easier to figure out what is defined there, and
where it's exactly used.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
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>
