Re: v2 [PATCH 4/4] nsswitch: use new internal API

[Carlos O'Donell <carlos@redhat.com>]

On 7/1/20 8:32 PM, DJ Delorie via Libc-alpha wrote:
> Stitch new ABI and types throughout all NSS callers and providers.

I have applied your 4 patches to Fedora Rawhide and booted a system
and started testing things out.

The system works perfectly fine, but in the tests I ran the /etc/nsswitch.conf
doesn't reload.

It doesn't reload because of code like this:

 59   if (DATABASE_NAME_SYMBOL == NULL
 60       && __nss_database_lookup2 (DATABASE_NAME_STRING, ALTERNATE_NAME_STRING,
 61                                  DEFAULT_CONFIG, &DATABASE_NAME_SYMBOL) < 0)
 62     return -1;
 63 
 64   *ni = DATABASE_NAME_SYMBOL;
 65 
 66   return __nss_lookup (ni, fct_name, fct2_name, fctp);

and this:

 723           if (__nss_hosts_database == NULL)
 724             no_more = __nss_database_lookup2 ("hosts", NULL,
 725                                               "dns [!UNAVAIL=return] files",
 726                                               &__nss_hosts_database);
 727           else
 728             no_more = 0;
 729           nip = __nss_hosts_database;

Which cache the database lookup.

This is OK for setent/getent/endent where you want a consistent database for
the iterations.

This is not OK for getaddrinfo where subsequent calls should return the new
data for long lived applications.

To me this means that we still have some work to do here, and I would like to
see the following tests added:

(1) Test covering changing data after reload for host interfaces.

* New container test case that has 2 NSS services for hosts providing
  different data.
* Start the test with one set of data and call:
  * gethostbyname
  * gethostbyname_r
  * gethostbyname2
  * gethostbyname2_r
  * gethostbyaddr
  * getaddrinfo
  * getnameinfo
* Collect results.
* Switch interfaces.
* Call functions again.
* Collect results.
* Compare expected vs. observed.

(2) Test covering non-changing reload for setent/getent/endent for hosts.

* New container test case that has 2 NSS services for hosts providing
  different data.
* Start the test with one set of data and call:
  * setent
  * getent ...
* Change the file mid enumeration.
* More of:
  * getent ...
  * endent
* Verify results match first service data (service not changed and cached
  until endent).
* Start a second iteration of:
  * setent
  * getent
  * endent
* Verify results match second service data.

That should be enough to validate the reloading.

We should be on the lookout for this pattern of database caching.

Yes, it means we will stat /etc/nsswitch.conf for every API call, but that
is in the noise compared to the network costs of going to DNS/LDAP or
parsing files. I don't think the added stat cost will make much of a difference
compared to reading and parsing lines from files.

-- 
Cheers,
Carlos.