[SSSD] [PATCH 0/3] Improve robustness of mmap cache handling

Jakub Hrozek jhrozek at redhat.com
Thu Dec 20 18:39:59 UTC 2012


On Thu, Dec 20, 2012 at 08:31:32AM -0500, Simo Sorce wrote:
> 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 at 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.

The "Addiotinal protection against wild pointers" patch fixed the issue
for me. Sorry, at first I thought this patchset superseded that patch.

I wasn't able to see the segfault anymore after hammering the SSSD for
more than an hour with requests. Previously, the nss process died within
minutes at best.

Ack



More information about the sssd-devel mailing list