[SSSD] [PATCHES] sss_userdel and sss_groupdel should invalidate mmap cache

Michal Židek mzidek at redhat.com
Wed Nov 21 14:56:23 UTC 2012


On 11/21/2012 02:31 PM, Simo Sorce wrote:
> On Tue, 2012-11-20 at 14:29 +0100, Michal Židek wrote:
>> On 11/20/2012 02:22 PM, Michal Židek wrote:
>>> Patch 1: sss_cache refactor. See patch description for more details.
>>> Patch 2: Remove mmap cache properly in sss_userdel and sss_groupdel
>
> It looks a bit excessive to remove the whole cache when you change 1
> user, would be probably better to fix this by a slightly more complex
> construct.
>
> After you delete the data from the ldb cache you could query sssd_nss
> for the user name. And make sure that sssd_nss also searches the mc
> cache and remove the entry if it is found there on user lookup failure
> (we can later on use this feature to implement negative caching at the
> mc layer).
>
> Simo.
>

Hmm... we would still need to handle the situation when sssd_nss is not 
running. I guess removing the entire mmap cache here is just fine.

But, to the case when sssd_nss is running. Does sss_nss_make_request() 
only ldb requests? Or first mc then ldb? I am looking at the client code 
now and it looks like this function is called when mc lookup did not 
succeeded... so my guess is, that it only requests for ldb data. If so, 
then this would be the function to use here.

It would be like:
... in the tool's code ...
sss_nss_make_request(SSS_NSS_GETPWNAM, ...);

... somewhere inside sssd_nss code ...
if (no_results_in_ldb) {
     invalidate rec in mc
}

Since the invalidation takes place inside sssd_nss process, no new 
synchronization between processes should be needed (the barriers are 
already there). But this would only work if sss_nss_make_request 
communicates with ldb only (which I think it does).

Was this your suggestion?

Thanks
Michal




More information about the sssd-devel mailing list