s3: smbd: POSIX ACLs. Remove incorrect check for SECINFO_PROTECTED_DACL in incoming security_information flags in posix_get_nt_acl_common().

Tidy-up of code obsoleted by fixes for bug #10773 (SECINFO_PROTECTED_DACL is not ignored).
We now never pass SECINFO_PROTECTED_DACL in security_information flags to this layer.

Bug: https://bugzilla.samba.org/show_bug.cgi?id=10773

Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>

Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Fri Aug 22 11:26:57 CEST 2014 on sn-devel-104
brlock: Do auto-cleanup at conflict time

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>
brlock: Remove validate_lock_entries

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>
torture: Run the cleanup2 test against 2 nodes

This enables testing the brlock cleanup across ctdb

Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
torture: Fix cleanup2 to utilize on-demand cleanup

Now we check the cleanup when conflicts happen, not when we first open
the file. This means we don't have to re-open the connection to make
cleanup happen.

Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
selftest/Samba4: avoid warnings about 'path' not specified on 'ntvfs handler = cifs' shares

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
messaging3: Add msg_sink/source -- perftest

With this pair of programs I did some performance tests of the messaging
system. Guess what -- I found two bugs :-)

See the subsequent patches.

With 1500 msg_source processes I can generate message overload: A

Intel(R) Xeon(R) CPU           L5640  @ 2.27GHz

can receive roughly 100k messages per second. When using
messaging_read_send/recv user/system time is roughly even, a bit more
work done in user space. When using messaging_register, due to less
malloc activity, user space chews a lot less.

By the way: 1.500 helper threads in a blocking sendto() against a single
datagram socket reading as fast as it can (with epoll_wait in between)
only drove the loadavg to 12 on a 24-core machine. So I guess unix domain
datagram sockets are pretty well protected against overload. No thundering
herd or so. Interestingly "top" showed msg_sink at less than 90% CPU,
although it was clearly the bottleneck. But that must be a "top" artifact.

Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
pthreadpool: Slightly serialize jobs

Using the new msg_source program with 1.500 instances against a single
msg_sink I found the msg_source process to spawn two worker threads for
synchronously sending the data towards the receiving socket. This should
not happen: Per destination node we only create one queue. We strictly
only add pthreadpool jobs one after the other, so a single helper thread
should be perfectly sufficient.

It turned out that under heavy overload the main sending thread was
scheduled before the thread that just had finished its send() job. So
the helper thread was not able to increment the pool->num_idle variable
indicating that we don't have to create a new thread when the new job
is added.

This patch moves the signalling write under the mutex. This means that
indicating readiness via the pipe and the pool->num_idle variable happen both
under the same mutex lock and thus are atomic. No superfluous threads anymore.

Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
lib: Introduce server_id_same_process()

Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
messaging3: Avoid messaging_is_self_send

This was a bad API, and it was used in a buggy way: In
messaging_dispatch_rec we always did the defer, we referenced the
destination pid, not the source. In messaging_send_iov this is the right
thing to do to reference the destination, but when we have arrived in
messaging_dispatch_rec we should compare source and destination.

Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Don't discard result of checking grouptype

The pdb_samba_dsdb_getgrfilter() function first determines the security type
of a group and sets map->sid_name_use accordingly. A little later, this
variable is set again, undoing the previous work.

https://bugzilla.samba.org/show_bug.cgi?id=10777

Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Simo Sorce <idra@samba.org>

Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Sat Aug 23 02:48:52 CEST 2014 on sn-devel-104