[PATCHES] Increase file descriptor limits in the responders
by Stephen Gallagher
Fixes https://fedorahosted.org/sssd/ticket/1197
Patch 0001 (master and sssd-1-8):
Allow increasing the file-descriptor limit
This patch will increase the file descriptor limit to 8k or the
limits.conf maximum, whichever is lesser.
Patch 0002 (master only):
Make the file descriptor limit configurable.
This code will now attempt first to see if it has privilege to set
the value as specified, and if not it will fall back to the
previous behavior. So on systems with the CAP_SYS_RESOURCE
capability granted to SSSD, it will be able to ignore the
limits.conf hard limit.
11 years, 1 month
sssd to renew user's Kerberos tickets automagically
by Ondrej Valousek
Hi List,
Is it planned for sssd to allow it to renew user's Kerberos cache in /tmp/krb5cc_XXXXXX automatically (i.e. much like what the lsass.exe
service does in Windows)?
For this to happen, we would need to cache user's plaintext password in memory I know, but could be handy in some situations....
Thanks,
Ondrej
11 years, 1 month
[PATCH] Always include all manpage XML files in the distribution tarball
by Stephen Gallagher
This fixes the build breakage we were seeing after the "SSH: Build man
pages conditionally" patch.
The problem is that EXTRA_DIST was not evaluated properly at tarball
creation time unless --with-ssh or --enable-all-experimental-features
had been specified in the "configure" run that preceded 'make dist'.
This was because EXTRA_DIST was composed of only those XML files that
were specified by man_MANS during this run.
We now always add all manpage XML files to the EXTRA_DIST variable so
that they are always included in the tarball.
11 years, 1 month
talloc pool
by Pavel Březina
Hi guys,
while working of my thesis I've notice two features of talloc that we
might use to make sssd faster with only a little effort.
The first one is about decreasing malloc() calls. We should certainly
do some measures here but I don't doubt that malloc() is a big issue in
sssd. We use it almost everywhere + we use it indirectly with talloc
which is about 10% slower (manpage).
Samba team run to this issue as well and therefore they created a new
context type - talloc pool. The documentation says:
"A talloc pool is a pure optimization for specific situations. In the
release process for Samba 3.2 we found out that we had become
considerably slower than Samba 3.0 was. Profiling showed that malloc(3)
was a large CPU consumer in benchmarks. For Samba 3.2 we have
internally converted many static buffers to dynamically allocated ones,
so malloc(3) being beaten more was no surprise. But it made us slower."
The great thing about this is that it is completely transparent. The
context can be created with talloc_pool(ctx, size) and it works this
way:
- if we are allocating data on a pool context, it takes the desirable
amount of space from the pool,
- if the context is a descendant of the pool context, it takes the space
from the pool as well,
- if the pool is out of memory, it creates a new, normal context,
- if we change the parent of a child of talloc pool to a parent that is
outside of this pool, the whole pool memory will not be freed until
the child is freed.
Example:
/* allocate 1KiB in a pool */
TALLOC_CTX *pool_ctx = talloc_pool(NULL, 1024);
/* take 512B from the pool, 512B left */
void *ptr = talloc_size(pool_ctx, 512);
/* 1024B > 512B, this will create new talloc chunk */
void *ptr2 = talloc_size(ptr, 1024);
/* the pool still contains 512 free bytes
* this will take 200B from them */
void *ptr3 = talloc_size(ptr, 200);
/* this will destroy context 'ptr3' but the memory
* is not freed, the available space in the pool
* will increase to 512B */
talloc_free(ptr3);
/* this works as usual :) */
talloc_free(pool_ctx);
Basically we can create large pool context for each responder/dp request
and create temporary context on the pool context or its descendants.
That's all that would need to change.
I will send a description of the other feature in another mail.
11 years, 1 month
talloc_*_append_buffer
by Pavel Březina
Hi guys,
here is the second part of nice talloc features.
talloc_*_append(dest, src) works in O(n^2) complexity as it needs to do
strlen(dest) and strlen(src). Talloc also provides an alternative
talloc_*_append_buffer(dest, src) which uses size of the dest context
to determine the length of the string. Its complexity is O(n) as it
runs only strlen(src).
Let me show it on an example. One part of the sysdb filter creation for
sudo contains:
for (i=0; groupnames[i] != NULL; i++) {
filter = talloc_asprintf_append(filter, "(%s=%%%s)",
SYSDB_SUDO_CACHE_AT_USER,
groupnames[i]);
NULL_CHECK(specific_filter, ret, done);
}
groupnames contains all groups that a user is member of.
Let's say he's a member of 100 groups where each group name consist of
10 characters. We will run strlen(filter) 100 times with total of
sum[i=1..100](10*i) = 50 500 iterations but we can simply make it 0 if
we replace talloc_*_append with talloc_*_append_buffer.
11 years, 1 month