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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
struct byte_range_lock *rw = NULL; will never change...
commit 1057240733 removed the
possible assigment of 'rw'.
So we can remove all code under if (rw != NULL) { ...
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Fri Oct 31 06:07:43 CET 2014 on sn-devel-104
This is now only called during brl_forall. It does not really hurt if we list
dead processes here. If the upper layers really care, they can filter it out
themselves. The real lock conflicts are not removed on-demand.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This avoids the need to do sweeping validate_lock_entries calls
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@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 Aug 6 03:27:36 CEST 2014 on sn-devel-104
Pass "struct lock_struct" as a parameter. This had to be destructured
before the call and re-constructed inside brl_locktest.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
It took me really long to grasp what's going on in this routine. I hope
its logic is easier to understand now
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
lck1 and lck2 are treated differently. They should carry more descriptive
names.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Consider:
lock = start=110,size=10
pend_lock = 100, size=10
Do not overlap. However,
(lock->start <= pend_lock->start + pend_lock->size)
110 100 10
is true, so it returns true (overlap).
lock->start <= pend_lock->start + pend_lock->size
should be:
lock->start < pend_lock->start + pend_lock->size
BUG: https://bugzilla.samba.org/show_bug.cgi?id=10685
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
Autobuild-User(master): Michael Adam <obnox@samba.org>
Autobuild-Date(master): Wed Jul 2 10:18:17 CEST 2014 on sn-devel-104
memmove calculations are never nice, and this is going to be used in
validate_lock_entries soon :-)
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We only print valid share mode entries, stale ones don't count. In
traverse, let the callback decide about staleness.
https://bugzilla.samba.org/show_bug.cgi?id=10680
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Fix several occurences of using printf conversion to fload when
printing offset and count variables in locking debug messages and
smbstatus.
Conversion to float may lead to wrong results with very large values.
Signed-off-by: Ralph Boehme <rb@sernet.de>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
In changes to come this will be possible for an INTERNAL_OPEN_ONLY.
The protection was already in place for some code paths, this
makes the coverage compete.
Bug 10564 - Lock order violation and file lost
https://bugzilla.samba.org/show_bug.cgi?id=10564
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@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): Fri Mar 21 21:22:24 CET 2014 on sn-devel-104
This might be the reason for a few flaky builds.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
Autobuild-User(master): Michael Adam <obnox@samba.org>
Autobuild-Date(master): Mon Mar 3 16:30:53 CET 2014 on sn-devel-104
brl_get_locks_readonly() currently returns NULL when it can't
find any byte range locks on the file. This is an error - it
should return a valid struct byte_range_lock containing num_locks == 0
so it can be cached.
Returning NULL when there are no locks causes POSIX lock
tests to fail returning NT_STATUS_NO_MEMORY (as it thinks
it can't allocate the struct) instead of NT_STATUS_OK.
Fixes bug:
Bug 10431 - STATUS_NO_MEMORY response from Query File Posix Lock request
https://bugzilla.samba.org/show_bug.cgi?id=10431
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <Volker.Lendecke@SerNet.DE>
This is in preparation to support handing flags to backends,
in particular activating read only record support for ctdb
databases. For a start, this does nothing but adding the
parameter, and all databases use DBWRAP_FLAG_NONE.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
This parameter was originally set for removal in 2007 in 28210588ed
Signed-off-by: Garming Sam <garming@catalyst.net.nz>
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Thu Jan 30 13:25:22 CET 2014 on sn-devel-104
This does two things: It gets rid of a talloc_stackframe in a hot
code path and to me it makes the code easier to understand. It makes
the talloc hierarchy more obvious to follow.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Looks scary, but the only effect of this bug is too many UNLOCK messages
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ira Cooper <ira@samba.org>
FAKE_LEVEL_II_OPLOCK was an indicator to break level2 oplock holders
on write. This information is now being held in brlock.tdb, which makes
the FAKE_LEVEL_II_OPLOCK type unnecessary.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This implements an idea by metze: Right now Samba does not grant level2
oplocks where it should: After an initial no-oplock open that has been
written to, we don't have the FAKE_LEVEL2_OPLOCK entry in locking.tdb
around anymore, this downgraded to NO_OPLOCK. Windows in this case will
grant level2 if being asked, we don't. Part of the reason for this
is that we don't have a proper mechanism to communicate the fact that
level2 needs to be broken to other smbds. Metze's insight was that we
have to look into brlock.tdb for every write anyway, so this might be
the right place to store this information.
My first reaction was that this is really hackish, but on further thought
this is not. oplocks depend on brlocks anyway, and we have the proper
mechanisms in place for brlocks.
The format for this change is to add one byte to the end of the brlock.tdb
record with value 1 if we have level2 oplocks around. Thus this patch
effectively reverts 8f41142 which I discovered while writing this
change. We now legally have unaligned records.
We can certainly talk about the format, but I'm not yet convinced we
need an idl for this yet. This is a potentially very hot code path,
and ndr marshalling has a cost.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
With the find_share_mode simplification we don't need fill_share_mode anymore.
So this coalesces add_share_mode as well.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
All callers used fill_share_mode_entry before calling
find_share_mode_entry. Remove that requirement.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
share_mode_stale_pid internally only has to deal with uint32_t. Make
the parameter match this.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
With the rewritten brl_get_lock_readonly we only set the destructor for
r/w lock records anyway.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Sun Oct 6 22:20:05 CEST 2013 on sn-devel-104
This is step 1 to get rid of brl_get_locks_internal with its complex readonly
business. It also optimizes 2 things: First, it uses dbwrap_parse_record to
avoid a talloc and memcpy, and second it uses talloc_pooled_object.
And -- hopefully it is easier to understand the caching logic with
fsp->brlock_rec and the clustering escape.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Without clustering, fsp->brlock_rec will never be set anyway. In the
clustering case we can't use the seqnum trick, so this is slow enough
that the additional if-statement does not matter in this case anyway. In
the non-clustered case it might. Have not measured it, but every little
bit helps I guess.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Sun Oct 6 15:49:43 CEST 2013 on sn-devel-104
If someone messes with brlock.tdb and inserts an invalid record length,
this will lead to memcpy overwriting a few bytes behind malloc'ed data.
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 Sep 12 03:26:45 CEST 2013 on sn-devel-104
There's no point checking the validity of the "entry" argument more
than once
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
The comment for this routine said:
> Modifies d->num_share_modes, watch out in routines iterating over
> that array.
Well, it turns out that *every* caller of this API got it wrong. So I
think it's better to change the routine.
This leaves the array untouched while iterating but filters out the
deleted ones while saving them back to disk.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
For a given file, clean share mode entries for a given persistent file id.
Pair-Programmed-With: Michael Adam <obnox@samba.org>
Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Gregor Beck <gbeck@sernet.de>
Signed-off-by: Michael Adam <obnox@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
For a given file, clean up brl entries belonging to a given persistent file id.
Signed-off-by: Gregor Beck <gbeck@sernet.de>
Reviewed-by: Michael Adam <obnox@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
We should not remove locks of disconnected opens just like that.
When getting the byte range lock record for a newly connected file
handle, we still do the clean up, because in that situation,
disconnected entries are not valid any more.
Signed-off-by: Gregor Beck <gbeck@sernet.de>
Reviewed-by: Michael Adam <obnox@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
...instead of checking each server-id separately which can
be expensive in a cluster.
Signed-off-by: Gregor Beck <gbeck@sernet.de>
Reviewed-by: Michael Adam <obnox@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
fsp->fnum and lock->fnum are uint64_t already and we should not truncate the value here.
Currently this doesn't matter as we only use 16-bit.
But as 'int' is int32_t and we later compare fnum with lock->fnum == fnum,
the cast from int32_t to uint64_t goes via int64_t instead of uint32_t.
This means even if fsp->fnum just uses 32-bit of the uint64_t
we'll get the wrong result, as the implicit cast from a negative int32_t
value to uint64_t adds 0xFFFFFFFF00000000.
metze
