[Bug 194025] New: [PATCH] nscd set query timeout properly

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194025

            Bug ID: 194025
           Summary: [PATCH] nscd set query timeout properly
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: Any
                OS: Any
            Status: Needs Triage
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: dpejesh at yahoo.com

Created attachment 147818
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147818&action=edit
set timeout properly

So, I've noticed nscd hasn't worked right for awhile now.  Since I
upgraded to 10.0 it never seemed to cache properly but I never bothered
to really dig into it until recently and here's what I've found.  In my
environment I have nsswitch set to use caching and LDAP as such:

group: files cache ldap
passwd: files cache ldap

The LDAP part works fine, but caching didn't on 10.0 for some reason.
On my 9.2 machines it works as expected though.  What I've found is in
usr.sbin/nscd/query.c

struct query_state *
init_query_state(int sockfd, size_t kevent_watermark, uid_t euid, gid_t
egid)
{
  ...
    memcpy(&retval->timeout, &s_configuration->query_timeout,
        sizeof(struct timeval));
  ...
}

s_configuration->query_timeout is an 'int' which is being memcpy'd into
a 'struct timeval' causing it to grab other parts of the s_configuration
struct along with the query_timeout value and polluting retval->timeout.
In this case it appears to be grabbing s_configuration->threads_num and
shoving that into timeout.tv_sec along with the query_timeout. This ends
up confusing nscd later on (instead of being 8 it ends up being set to
34359738376) and breaks it's ability to cache.  I've attached a patch to
set the retval->timeout properly and gets nscd working again.  I'm
guessing gcc was handling this differently from clang which is why it
wasn't a problem before 10.0.

-- 
You are receiving this mail because:
You are the assignee for the bug.