313240 |
04-Feb-2017 |
ngie |
MFC r312332,r312446,r312451:
r312332:
Use SRCTOP where possible and use :H to manipulate .CURDIR to get rid of unnecessarily long relative path .PATH values with make
r312446 (by emaste):
libc: remove reference to nonexistent lib/locale directory
As far as I can tell this was introduced in r72406 and updated in several subsequent revisions, but the lib/locale directory it referenced never existed.
r312451:
Replace dot-dot relative pathing with SRCTOP-relative paths where possible
This reduces build output, need for recalculating paths, and makes it clearer which paths are relative to what areas in the source tree. The change in performance over a locally mounted UFS filesystem was negligible in my testing, but this may more positively impact other filesystems like NFS.
LIBC_SRCTOP was left alone so Juniper (and other users) can continue to manipulate lib/libc/Makefile (and other Makefile.inc's under lib/libc) as include Makefiles with custom options.
Discussed with: marcel, sjg |
301592 |
08-Jun-2016 |
truckman |
Don't leak addrinfo if ai->ai_addrlen <= minsiz test fails.
If the ai->ai_addrlen <= minsiz test fails, then freeaddrinfo() does not get called to free the memory just allocated by getaddrinfo(). Fix by moving ai->ai_addrlen <= minsiz to a separate nested if block, and keep freeaddrinfo() in the outer block so that freeaddrinfo() will be called whenever getaddrinfo() succeeds.
Reported by: Coverity CID: 1273652 Reviewed by: ume MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D6756
|
289837 |
23-Oct-2015 |
vangyzen |
resolver: abuse _res a little less
In the past, _res was a global variable. Now, it's multiple function calls. Several functions in the resolver use _res multiple times and therefore call the function(s) far more than necessary.
Fix those callers to store the result of _res in a local variable.
Add __noinline to the definition of res_init() to avoid the code bloat that these changes would have otherwise incurred. Thanks to jilles for noticing this.
Reviewed by: jilles MFC after: 1 week Sponsored by: Dell Inc. Differential Revision: https://reviews.freebsd.org/D3887
|
289315 |
14-Oct-2015 |
vangyzen |
resolver: automatically reload /etc/resolv.conf
On each resolver query, use stat(2) to see if the modification time of /etc/resolv.conf has changed. If so, reload the file and reinitialize the resolver library. However, only call stat(2) if at least two seconds have passed since the last call to stat(2), since calling it on every query could kill performance.
This new behavior is enabled by default. Add a "reload-period" option to disable it or change the period of the test.
Document this behavior and option in resolv.conf(5).
Polish the man page just enough to appease igor.
https://lists.freebsd.org/pipermail/freebsd-arch/2015-October/017342.html
Reviewed by: kp, wblock Discussed with: jilles, imp, alfred MFC after: 1 month Relnotes: yes Sponsored by: Dell Inc. Differential Revision: https://reviews.freebsd.org/D3867
|
167246 |
05-Mar-2007 |
jhb |
Only reject file descriptors higher than FD_SETSIZE if we are not using poll(2) or kqueue(2). Previously we rejected fd's higher than FD_SETSIZE for kevent(2), and larger than sysconf(_SC_OPEN_MAX) for poll(2). However, the check for poll(2) wasn't really needed. open(2) and socket(2) won't return an fd you can't pass to either poll(2) or kevent(2). This fixes a but where gethostbyname() would fail if you had more than 1023 files open in a process.
MFC after: 1 week Reviewed by: ume Found by: ps
|
160967 |
04-Aug-2006 |
ume |
Check if the filedes of kevent is expected one. Though our old resolver opened just one socket, BIND9's resolver may open more than one sockets. And, BIND9's resolver doesn't close the socket on timeout. So, we need this check.
Reported by: freebsd-cvs-src__at__oldach.net (Helge Oldach), bz Hinted by: rwatson
|
157308 |
30-Mar-2006 |
ume |
Expose res_update and friends again. At least, ports/mail/spamilter uses them. Now, we have res_nupdate and res_nmkupdate as well, but they are still based on our old resolver for binary backward compatibility. So, they don't provide new features such as TSIG support.
Reported by: pointyhat via kris
|