`Hint' here means nonzero addr, but no MAP_FIXED or MAP_TRYFIXED.
This is suboptimal -- we could teach uvm_mmap to do a fancier search
using the address as a hint. But this should do for now.
Candidate fix for PR kern/55533.
ok chs@
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
says that in order to make a makefile POSIX-conforming, its first
non-comment line must be the special dependency line '.POSIX:' without
any source dependencies.
Previously, make switched to POSIX mode even if such a line occurred
anywhere else, which was allowed by POSIX but was deep in the
"unspecified behavior" area. For NetBSD make, there is no big
difference since it doesn't ship any <posix.mk> file, this change mainly
affects the bmake distribution.
Previously, makefiles that contain '.POSIX:' somewhere in the middle
could fail due to <posix.mk> resetting .SUFFIXES, among other things.
Suggested by Simon J. Gerraty, who also reviewed an earlier version of
this change.
'tools/elftoolchain/common' has been built.
This change aligns the 'tools' build with the regular build.
Subsequent commits will change 'tools/libctf' and
'tools/cft{merge,convert}' to use the new build paths.
(the job number, given jp a pointer to a jobs table entry)
used open coded previously in many places (mostly in DEBUG mode
trace messages, so not included in most shells, but there are
a few others).
Make the type of JNUM() be int rather than the ptrdiff_t the
open coded version became ... which when used in some printf()
type function arg list was cast to some other arbitrary (but not
consistent) int type for which there is a standard %Xd type
format conversion. Now we can (and do) just use %d for this.
If the number of jobs ever exceeds the range of an int, we would
have far more serious problems than the broken output this would
cause.
While here improve a comment or two, and use JOBRUNNING instead
of 0 where the intent is the former (JOBRUNNING is #defined as 0).
NFCI.
Validate lengths and types before barging ahead.
Not sure exactly which missing validation syzbot tripped on here, but
I'm pretty sure I caught all the cases.
Reported-by: syzbot+60f0a25c077b67547f57@syzkaller.appspotmail.com
Descriptors in the USB spec all start with bLength and
bDescriptorType. bDescriptorSubtype is only for certain
class-specific descriptors. Many descriptors, such as
usb_device_descriptor_t, _do not_ have bDescriptorSubtype, so using a
structure that has bDescriptorSubtype for such descrpitors is wrong.
There is some history here:
- Back in 1998, when augustss@ introduced the USB stack, the type
usb_descriptor_t was erroneously defined with a bDescriptorSubtype
member.
- In 2007, drochner@ removed this member to accurately reflect the
USB spec.
- In 2018, khorben@ appeared to have accidentally reintroduced it
while importing the umb(4) driver from OpenBSD, which still has the
erroneous bDescriptorSubtype member in usb_descriptor_t.
The umb(4) driver has since been adjusted to correctly use
usb_cdc_descriptor_t instead of usb_descriptor_t (and I have now
restored umidi_cs_descriptor_t which I had removed last month before
I realized this history of usb_descriptor_t), so this member is no
longer necessary.
Had been previously deleted under the misapprehension that
usb_descriptor_t is appropriate here, but it's not -- it should not
have the bDescriptorSubtype member.
This isn't riskier than before -- previously we took kprintf_lock
inside each separate printf/vprintf call here. Now we just take it
once around access to panicstr and printing the message.
With any luck, this should help avoid interleaving panic messages
with each other and with other output -- and maybe cut down on the
number of syzkaller duplicates.
The flags do not describe the left operand of the node but both, as for
most operators, either none or both operands are in test context or in
value context.
The one exception is the operator '?' from the '?:' conditional, for
which the left operand is in test context and the right operand is in
value context.
No binary change.
Noticed in lex.c, in the macro kwdef, where lint complains about the
condition containing '||' but not about the conditions containing only
'>' or '=='.
The C11 keywords had been listed as being C99 keywords. Instead of
initializing the individual fields separately, merge them by specifying
the year of the standard in which they appeared.
No binary change, except for line numbers in assertions.
In msg_259_ilp32.c 1.6 from 2022-04-15, I removed the option -S from the
test in order to keep the message 259, but I forgot to fix the C99-style
comment as well.
In platform_int.c, the default lint option -S no longer generated
warning 259, so remove that option.
There is only one specialized keyword that is also a GCC attribute, it's
"section". All other keywords passed 0 in that macro argument.
No binary change.
vput(vp) also unlocks vp, thus unlocking happens twice in error flow
causing kernel to panic with failed assertion lktype != LK_NONE
in vfs_vnode.c#778. Thanks riastradh with finding the issue.
Calculating the severity as a simple sum removes the condition sequence
'a && !b, or else a || !b', which can quickly become a brain twister,
especially when negations are involved.
No functional change.
rillig