The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.
Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.
With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.
Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.
The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.
Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.
With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.
Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.
In that compilation variant, TRUE is defined to 255, to see whether all
boolean expressions evaluate to either 1 or 0. The field If.doNot in
cond.c doesn't do this since it uses the actual value of TRUE.
Therefore, change the evaluation slightly to also handle this case.
* dhcpcd: Backticks have been removed from quoting filenames
* dhcpcd: Only manipulate stdin, stdout and stderr if they are valid
* duid: Adjust option so the type can be specified
* logerr: Don't leak logfile fd to scripts
* privsep: Run the launcher process in the sandbox
* BSD: Use `ifi_link_state` as the single source of truth about carrier
* BSD: Ignore vether(4) devices by default
Even with ``memcmp fix'', GCC 9.4 miscompiles this function for -O[12].
But the situation was slightly changed from that with GCC 8.3:
* -O0 and -O1 work but -O2 fails for 68060 and 68040 (real hardware)
* -O0 and -O2 work but -O1 fails for 68020 and 68010 (TME)
In IPsec Tx side, one Security Association can be used by multiple CPUs.
On the other hand, in IPsec Rx side, one Security Association is used
by only one CPU.
XXX pullup-{8,9}
fonts included as part of X11 that are also included as scalable fonts
as part of macOS.
Many websites will attempt to select these fonts, which results in
very strange, poor quality rendering.
This should keep legacy X11 applications that want the old "Helvetica"
and "Times" fonts working, but prevent them from being selected by
applications that want scalable fonts.
It should not prevent "Helvetica" or "Times" from being selected
if the user installs a scalable version.
ubc_fault_page(): Ignore PG_RDONLY flag and always pmap_enter() the page
with the permissions of the original access_type.
It is the file system's responsibility to allocate blocks that is being
modified by write(), before calling into UBC to fill the pages for that
range. KASSERT() is added there to confirm that no clean page is mapped
writable.
Fix infinite loop in uvm_fault_internal(), observed on 16KB-page systems,
where it continues to try to make a partially-backed page writable.
No regression in ATF and KASSERT() does not fire on several architectures,
as far as I can see.
Fix suggested by chs. Thanks!
This is probably an edge case that nobody will ever stumble upon, since
.CURDIR is usually regarded as a read-only variable.
The other variable that is affected by this code path is .MAKE.EXPORTED,
and for this variable as well, it would be unusual to assign it a value
from a shell command.
Interface arrival, departure and link state changes will sync
and if different will be actioned.
Currently we do not track addresses, so any changes there are still lost.
