Use the pte bit that says whether this is a PMAP_WIRED page, not the
bit that says whether this is a non-global page.
(Forgot to git commit --amend before exporting to CVS, sorry!)
Pages mapped with pmap_kenter_pa are necessarily unmanaged, so there
are no P->V records, and pmap_kenter_pa leaves pp->pp_pv.pv_va zero
with no modified/referenced state.
However, pmap_protect erroneously examined pp->pp_pv.pv_va to
ascertain the modified/referenced state -- and if the page was not
marked referenced, pmap_protect would clear the LX_BLKPAG_AF bit
(Access Flag), with the effect that subsequent uses of the page fault
and require a detour through pmap_fault_fixup.
This caused problems for the kernel module loader:
- When loading the text section, kobj_load first allocates kva with
uvm_km_alloc(UVM_KMF_WIRED|UVM_KMF_EXEC), which creates ptes with
pmap_kenter_pa. These ptes are writable, so we can copy the text
section into them, and have LX_BLKPAG_AF set so there will be no
fault when they are used by the kernel.
- But then kobj_affix makes the text section read/execute-only (and
nonwritable) with uvm_km_protect(VM_PROT_READ|VM_PROT_EXECUTE),
which updates the ptes with pmap_protect. This _should_ leave
LX_BLKPAG_AF set, but by inadvertently treating the page as managed
when it should be unmanaged, pmap_protect cleared it instead.
- Most of the time, clearing LX_BLKPAG_AF caused no problem, because
pmap_fault_fixup would silently resolve it. But if a hard
interrupt handler tried to use any page in the module's text (or
rodata, I suspect) that was not yet fixed up, the CPU would fault
and enter pmap_fault_fixup -- which would promptly crash (or hang)
by trying to take the pmap lock in interrupt context, which is
forbidden.
I observed this by loading dtrace.kmod early at boot and trying to
dtrace hard interrupt handlers.
With this change, pmap_protect now recognizes wired mappings (as
created by pmap_kenter_pa) before consulting pp->pp_pv.pv_va, and
preserves then LX_BLKPAG_AF bit in that case.
ok skrll
release, but didn't make it into the tzdata2022fgtz fork that
we use - and nor did the original zone data come back.
Links seem adequate for these (and were all some of them ever were).
sh has been remembering the process group of a job for a while now, but
using that for almost nothing.
The old way to resume a job, was to try each pid in the job with a
SIGCONT (using it as the process group identifier via killpg()) until
one worked (or none did, in which case resuming would be impossible,
but that never actually happened). This wasn't as bad as it seems,
as in practice the first process attempted was *always* the correct
one. Why the loop was considered necessary I am not sure. Nothing
but the first could possibly work.
This worked until a fix for an obscure possible bug was added a
while ago - now a process which has already finished, and had its
zombie collected via wait*() is no longer ever considered to have
a pid which is a candidate for use in any system call. That's
because the kernel might have reassigned that pid for some newly
created process (we have no idea how much time might have passed
since the pid was returned to the kernel for reuse, it might have
happened weeks ago).
This is where the example in bin/57053 revealed a problem.
That PR is really about a quite different problem in zsh (from pksrc)
and should be pkg/57053, but as the test case also hit the problem
here, it was assumed (by some) they were the same issue.
The example is (in a small directory)
ls | less
which is then suspended (^Z), and resumed (fg). Since the directory
is small, ls will be finished, and reaped by sh - so the code would
now refuse to use its pid for the killpg() call to send the SIGCONT.
The (useless) loop would attempt to use less's pid for this purpose
(it is still alive at this point) but that would fail, as that pid
is not a process group identifier, of anything. Hence the job
could not be resumed.
Before the PR (or preceding mailing list discussion) the change here
had already been made (part of a much bigger set of changes, some of
which might follow - sometime). We now actually use the job's
remembered process group identifier when we want the process group
identifier, instead of trying to guess which pid it happens to be
(which actually never took any guessing, it was, and is always the
pid of the first process created for the job). A couple of minor
fixes to how the pgrp is obtained, and used, accompany the changes
to use it when appropriate.
also the process group identifier (that's a requirement from POSIX, and
is what we have always done - just not been explicit about in sh.1).
Add a note that this value and $! are not necessarily the same (currently,
and perhaps forever, never the same in a pipeline with 2 or more elements).
https://github.com/JodaOrg/global-tz/releases/download/2022fgtz/tzdata2022fgtz.tar.gz
Summary of changes in tzdata2022f (2022-10-28 18:04:57 -0700):
* Mexico will no longer observe DST after 2022, except for areas
near the US border that continue to observe US DST rules.
* Fiji will not observe DST in 2022/3.
* Simplify four Ontario zones, as most of the post-1970 differences
seem to have been imaginary.
The allwinner,sun8i-a33-codec binding spec has changed[1] to allow for
#sound-dai-cells to be either 0 or 1, to allow exporting multiple DAIs
from the codec.
This change updates the driver to allow #sound-dai-cells of either 0 or 1
while still only supporting AIF1 for the time being.
[1] 880e007f15
Arguments:
0: interrupt handler function
1: interrupt handler's private cookie argument
2: MD struct intrhand pointer
3: return value (true if relevant to this handler, false if not)
The MD struct intrhand pointer makes the first two arguments
redundant, but we might reuse the signature of the first two
arguments for an MI SDT probe to make it easy to write MI dtrace
scripts for monitoring interrupt handlers. The MD intrhand can be
used for getting more information about the interrupt like ih_level,
ih_pin, ih_slot, &c., which may not make sense as an MI API.
Changes to code
zic now supports links to links regardless of input line order.
For example, if Australia/Sydney is a Zone, the lines
Link Australia/Canberra Australia/ACT
Link Australia/Sydney Australia/Canberra
now work correctly, even though the shell commands
ln Australia/Canberra Australia/ACT
ln Australia/Sydney Australia/Canberra
would fail because the first command attempts to use a link
Australia/Canberra that does not exist until after the second
command is executed. Previously, zic had unspecified behavior if
a Link line's target was another link, and zic often misbehaved if
a Link line's target was a later Link line.
Fix line number in zic's diagnostic for a link to a link.
Fix a bug that caused localtime to mishandle timestamps starting
in the year 2438 when reading data generated by 'zic -b fat' when
distant-future DST transitions occur at times given in standard
time or in UT, not the usual case of local time. This occurs when
the corresponding .zi Rule lines specify DST transitions with TO
columns of 'max' and AT columns that end in 's' or 'u'. The
number 2438 comes from the 32-bit limit in the year 2038, plus the
400-year Gregorian cycle. (Problem reported by Bradley White.)
On glibc 2.34 and later, which optionally supports 64-bit time_t
on platforms like x86 where time_t was traditionally 32 bits,
default time_t to 64 instead of 32 bits. This lets functions like
localtime support timestamps after the year 2038, and fixes
year-2038 problems in zic when accessing files dated after 2038.
To continue to limit time_t to 32 bits on these platforms, use
"make CFLAGS='-D_TIME_BITS=32'".
In C code, do not enable large-file support on platforms like AIX
and macOS that no longer need it now that tzcode does not use
off_t or related functions like 'stat'. Large-file support is
still enabled by default on GNU/Linux, as it is needed for 64-bit
time_t support.
In C code, prefer C23 keywords to pre-C23 macros for alignof,
bool, false, and true. Also, use the following C23 features if
available: __has_include, unreachable.
zic no longer works around Qt bug 53071, as the relevant Qt
releases have been out of support since 2019. This change affects
only fat TZif files, as thin files never had the workaround.
zdump no longer modifies the environ vector when compiled on
platforms lacking tm_zone or when compiled with -DUSE_LTZ=0.
This avoid undefined behavior on POSIX platforms.
This code was a mess and full of unmaintainable SoC and board specific
ifdefs. A modern devicetree port for OMAP3530 and AM335x based boards
now lives in arch/arm/ti. If someone is interested in bringing back
support for any boards lost in this transition, feel free, but please
do so using the new devicetree based model.
andvar