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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
For type == ADOUBLE_META, fio->fake_fd is true so
writes are already synchronous, just call tevent_req_post().
For type == ADOUBLE_RSRC we know we are configured
with FRUIT_RSRC_ADFILE (because fruit_must_handle_aio_stream()
returned true), so we can just call SMB_VFS_NEXT_FSYNC_SEND()
after replacing fsp with fio->ad_fsp.
Remove knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15182
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Böhme <slow@samba.org>
Special handling of O_CREAT flag in SMB_VFS_OPENAT code path was the
only option to ensure correctness due to a bug in libgfapi as detailed
in issue #3838[1] from GlusterFS upstream. This has been fixed recently
so that O_CREAT is handled correctly within glfs_openat() enbaling us to
remove the corresponding special case from vfs_gluster_openat().
[1] https://github.com/gluster/glusterfs/issues/3838
Signed-off-by: Anoop C S <anoopcs@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Thu Oct 6 08:34:56 UTC 2022 on sn-devel-184
We use cli_smb2_qpathinfo_basic() for cli_resolve_path() before
calling cli_readlink(). This fails as it never tries with
FILE_OPEN_REPARSE_POINT, so we never get to the point where we
actually can issue the FSCTL_GET_REPARSE_POINT.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Instead of checking protocol correctness in every highlevel routine,
we should rely on the lowerlevel one in smbXcli_base.c to give the
INVALID_PARAMETER error return when running on SMB1
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Uses non-DFS names and DFS-names against a DFS share, shows that Windows
looks correctly at the DFS flag when SMB2 requests are
made on a DFS share. Passes against Windows 2022.
Mark as knownfail for smbd.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
Autobuild-User(master): Noel Power <npower@samba.org>
Autobuild-Date(master): Wed Sep 28 19:34:29 UTC 2022 on sn-devel-184
There is only one difference between Windows 2022 and Windows 2008.
Opening an empty ("") DFS path succeeds in opening the share
root on Windows 2008 but fails with NT_STATUS_INVALID_PARAMETER
on Windows 2022. Allow the test to cope with both.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
The function smbd_server_connection_terminate_done() does not free subreq
which is allocated in smbXsrv_connection_shutdown_send, this can be a
memory leakage if multi-channel is enabled.
Suggested fix by haihua yang <hhyangdev@gmail.com>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15174
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <noel.power@suse.com>
Autobuild-User(master): Noel Power <npower@samba.org>
Autobuild-Date(master): Fri Sep 23 09:51:20 UTC 2022 on sn-devel-184
In addition to b954d181cd2 we should also protect against timestamps
before the epoch.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=15151
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Christof Schmitt <cs@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Fri Sep 23 06:50:17 UTC 2022 on sn-devel-184
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Sep 20 01:34:55 UTC 2022 on sn-devel-184
This gives a nice speed up...
The following test with 256 commections all looping with open/close
on the same inode (share root) is improved drastically:
smbtorture //127.0.0.1/m -Uroot%test smb2.bench.path-contention-shared \
--option='torture:bench_path=' \
--option="torture:timelimit=60" \
--option="torture:nprocs=256" \
--option="torture:qdepth=1"
From something like this:
open[num/s=11536,avslat=0.011450,minlat=0.000039,maxlat=0.052707]
close[num/s=11534,avslat=0.010878,minlat=0.000022,maxlat=0.052342]
(only this commit with the close part reverted) to:
open[num/s=12722,avslat=0.009548,minlat=0.000051,maxlat=0.054338]
close[num/s=12720,avslat=0.010701,minlat=0.000033,maxlat=0.054372]
(with both patches) to:
open[num/s=37680,avslat=0.003471,minlat=0.000040,maxlat=0.061411]
close[num/s=37678,avslat=0.003440,minlat=0.000022,maxlat=0.051536]
So we are finally perform similar like we did in Samba 4.12,
which resulted in:
open[num/s=36846,avslat=0.003574,minlat=0.000043,maxlat=0.020378]
close[num/s=36844,avslat=0.003552,minlat=0.000026,maxlat=0.020321]
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This gives a nice speed up...
The following test with 256 commections all looping with open/close
on the same inode (share root) is improved drastically:
smbtorture //127.0.0.1/m -Uroot%test smb2.bench.path-contention-shared \
--option='torture:bench_path=' \
--option="torture:timelimit=60" \
--option="torture:nprocs=256" \
--option="torture:qdepth=1"
From some like this:
open[num/s=11536,avslat=0.011450,minlat=0.000039,maxlat=0.052707]
close[num/s=11534,avslat=0.010878,minlat=0.000022,maxlat=0.052342]
to:
open[num/s=13225,avslat=0.010504,minlat=0.000042,maxlat=0.054023]
close[num/s=13223,avslat=0.008971,minlat=0.000022,maxlat=0.053838]
But this is only half of the solution, the next commits will
add a similar optimization to the open code, at the end we'll
perform like we did in Samba 4.12:
open[num/s=37680,avslat=0.003471,minlat=0.000040,maxlat=0.061411]
close[num/s=37678,avslat=0.003440,minlat=0.000022,maxlat=0.051536]
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
It's good to have this in common as close_remove_share_mode()
and in the end we'll avoid get_existing_share_mode_lock()
and call them via share_mode_entry_prepare_{lock,unlock}(),
so that they can run under a tdb chainlock.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
close_share_mode_lock_prepare() will operates on share_mode_lock
in order to check if the object needs to be deleted or if
we can remove the share_mode_entry directly.
close_share_mode_lock_cleanup() will finish after the object
has been deleted.
We can reuse these function in close_directory() soon and
in the end we'll avoid get_existing_share_mode_lock()
and call them via share_mode_entry_prepare_{lock,unlock}(),
so that they can run under a tdb chainlock.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This inlines remove_oplock() into close_remove_share_mode() and
calls remove_share_oplock() and release_file_oplock() directly.
The idea is that we'll soon call remove_share_oplock()
under a tdb chainlock, while release_file_oplock() needs to be called outside.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The logic is now similar to close_remove_share_mode().
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We now use a goto done in order to skip the deletion part.
This means the code flow is now almost idential compared to
close_remove_share_mode().
It prepares to split common code to be shared by
close_remove_share_mode() and close_directory().
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This makes it much easier to understand the logic (at least for me).
It will make the following changes easier.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Now that we're using g_lock, it doesn't mean we're holding a tdb
chainlock.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
It will be used in close.c in the next commit.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Remember SMB2 Create is the only was to upgrade a lease.
The strategy is that opening of a file will always result
in storing the total lease bits.
But we're lazy clearing the flags on close.
We'll only clear them by traversing all entries when
we break a NONE or when opening a new handle.
We don't do any decision on SHARE_MODE_LEASE_{HANDLE,WRITE},
maybe we'll do in future, but at least it should be much more
sane for debugging now!
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This shows that the code in open_file_ntcreate() and
open_directory() is basically the same now, which
simplifies things a lot.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
It means we call open_mode_check() now only via handle_share_mode_lease()
and the fact that we never grant any directory leases (yet), means
that delay_for_oplocks() avoids the share_mode_forall_entries() loop.
This is a way into supporting directory leases, but that's not
the point for this commit, the point is that.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We don't support directory leases yet, so it should be
an noop for now.
The point is that we want to call
delay_for_oplock(oplock_request=NO_OPLOCK)
for directories soon.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The important part is the call to get a kernel oplock is deferred
until after set_share_mode(). The goal is to get the code
between get_share_mode_lock() and set_share_mode() free of any
blocking operation.
As we were optimistic to get the oplock that was asked for,
we need to remove_share_oplock() in order to set NO_OPLOCK
also in the share_mode entry.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This means we don't have to call remove_lease_if_stale() if
set_share_mode() fails. It's easier to cleanup the share mode entry.
And it makes the code flow easier to the following changes.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The aim is to call set_file_oplock() after set_share_mode(), so that we
only ask for kernel oplocks after set_share_mode().
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
It means delay_for_oplocks() is no longer asking for kernel oplocks.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
When adding or deleting share mode entries elements, we typically
have a pattern like this:
1. get the g_lock via get_[existing_]share_mode_lock()
2. do some checking of the existing record
3. add/delete a share_mode_entry to the record
4. do some vfs operations still protected by the g_lock
5. (optional) cleanup of the record on failure
6. release the g_lock
We can optimize this to:
- Run 1-3. under a tdb chainlock
- Only protect vfs operations with the g_lock
if a new file was created/will be deleted
- Regrab the g_lock for a cleanup.
The new share_mode_entry_prepare_lock()
allows the caller to run a function within a tdb chainlock
similar to share_mode_do_locked_vfs_denied() where vfs calls are denied
and the execution is done within a tdb chainlock.
But the callback function is allowed to decide if it wants to
keep the lock at the g_lock layer on return.
The decision is kept in struct share_mode_entry_prepare_state,
which is then passed to share_mode_entry_prepare_unlock()
with an optional callback to do some cleanup under the
still existing g_lock or a regrabed g_lock.
In the ideal case the callback function passed to
share_mode_entry_prepare_lock() is able to decide that
it can drop the g_lock and the share_mode_entry_prepare_unlock().
gets a NULL callback as there's nothing to cleanup.
In this case share_mode_entry_prepare_unlock() is a noop.
This will allow us to avoid fallbacks to the dbwrap_watch based
waiting for the g_lock in the SMB2 Create and Close code paths.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
It means that in callers function will run under a single tdb chainlock,
which means callers from the outside will never see the record being
locked at g_lock level, as the g_lock is only held in memory.
within the single tdb chainlock. As a result we'll very unlikely hit
the case where we need to wait for a g_lock using the dbwrap_watch
logic.
Review with: git show -w
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We'll soon make use of callback functions passed to g_lock_lock(),
during these callback function we'll only be allowed to
call 'g_lock_lock_cb_state' based functions.
Given that nesting of share_mode call, we need to
make it transparent to the callers and the detail
that we optimize using g_lock_lock() callbacks.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We now have only one code path that stores the fully
granted lock.
This is not change in behavior, but it will simplify further
changes.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This prepares some helper functions in order to
allow callers of g_lock_lock() to pass in a callback function
that will run under the tdb chainlock when G_LOCK_WRITE was granted.
The idea is that the callers callback function would run with
g_lock_ctx->busy == true and all key based function are not be allowed
during the execution of the callback function. Only the
g_lock_lock_cb_state based helper function are allowed to be used.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15125
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
