On Thu, 2012-12-20 at 14:24 +0100, Jakub Hrozek wrote:
On Thu, Dec 20, 2012 at 12:30:17PM +0100, Pavel Březina wrote:
> On 12/20/2012 06:10 AM, Simo Sorce wrote:
> >The function that reclaims free slots of memory was not very robust and
> >I think is the root cause of a segfault Jakub can easily reproduce as of
> >late. It is augmented by the fact the new functions I introduced that
> >invalidate records did not actually free the space they used in the
> >free slots table.
> >
> >I split the fixes in 3 small patches that should make it easier to review.
> >I did some quick testing on my machine and it seem ok.
> >
> >Simo.
> >
> >
> >Simo Sorce (3):
> > Update free table when records are invalidated.
> > Carefully check records when forcibly invalidating
> > mmap cache: invalidate cache on fatal error
> >
> > src/responder/nss/nsssrv_cmd.c | 4 +-
> > src/responder/nss/nsssrv_mmap_cache.c | 177
+++++++++++++++++++++++++++------
> > src/responder/nss/nsssrv_mmap_cache.h | 4 +-
> > src/util/mmap_cache.h | 6 +-
> > 4 files changed, 153 insertions(+), 38 deletions(-)
> >
> >_______________________________________________
> >sssd-devel mailing list
> >sssd-devel(a)lists.fedorahosted.org
> >https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> >
>
> Hi,
> how should I test those patches?
For me it was enough to run:
for i in `getent group someverylargegroup | tr ',' ' '`; do id $i; done
The patches fixed the crash for me, but I had to remove the fastcache files
that I had on the system from the previous run. I guess it's expected that
the memcache files got corrupt. I think we should do the same on upgrades
in the specfile, then.
Doesn't the patch automatically detect it an re-init the cache ?
That's what the third patch is about.
Did it fail to do that ?
We can't do it in the spec file, cache files must be properly
invalidated or client apps will be stuck reading from a unlinked file.
Simo.
--
Simo Sorce * Red Hat, Inc * New York