This is for an upcoming change that fixes .depend handling in here.
It will cause some duplicate sources which need to be trimmed out.
MFC after: 2 weeks
Sponsored by: DellEMC
The man page claims that with O_FSYNC (aka O_SYNC) the kernel will not cache
written data. However, that's not true. Nor does POSIX require it.
Perhaps it was true when that section of the man page was written in r69336
(I haven't checked). But it's not true now. Now the effect is simply that
writes are sent to disk immediately and synchronously, but they're still
cached.
See also: https://pubs.opengroup.org/onlinepubs/9699919799/
See also: ffs_write in sys/ufs/ffs/ffs_vnops.c
Reviewed by: cem
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D20641
libunwind and openmp to the upstream release_80 branch r363030
(effectively, 8.0.1 rc2). The 8.0.1 release should follow this within a
week or so.
MFC after: 2 weeks
Sync libarchive with vendor.
Relevant vendor changes:
- check_symlinks_fsobj() without chdir() and fchdir()
- bsdtar.1 manpage fixes
- patches from OpenBSD to libarchive_fe/passphrase.c
- version bumped to 3.4.0
MFC after: 2 weeks
configuration descriptor reads early on to avoid issues with devices
that don't check for a valid USB configuration read request.
Submitted by: takahiro.kurosawa@gmail.com
PR: 238412
MFC after: 3 days
port number, properly access them by their IPv6 names.
This will make it easier to slice up and compile out address families
in the future.
No functional change intended.
MFC after: 6 weeks
To facilitate experimentation with LTO we require an ar that supports
LLVM IR, and to a lesser degree also an nm. As a first step always
install llvm-ar and llvm-nm.
Sponsored by: The FreeBSD Foundation
As depicted in the comment: jid 0 always exists, but the lookup will fail as
it does not appear in the kernel's alljails list being a special jail. Some
callers will expect/rely on this, and we have no reason to lie because it
does always exist.
Reported by: Stefan Hegnauer <stefan.hegnauer gmx ch>
MFC after: soon (regression, breaks inspecting jail host bits, partial
revert)
ASAN reports become a lot more useful with llvm-symbolizer in $PATH, and the
build is not much more time-consuming. The added benefit is that the
resulting reports will actually include symbol information; without, thread
trace information includes a bunch of addresses that immediately resolve to
an inline function in
^/contrib/compiler-rt/lib/sanitizer_common/sanitizer_common.h and take a
little more effort to examine.
Reviewed by: emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D20484
Ensure the expected result is stored first in a volatile variable with
the desired type. This makes all the tests succeed.
Slightly changed from the original pull request, but functionally the
same.
Obtained from: https://github.com/freebsd/freebsd/pull/401
Submitted by: Moritz Buhl <gh@moritzbuhl.de>
PR: 191676
MFC after: 3 days
lib/atf/libatf-c/tests/Makefile added the -Wno-duplicate-decl-specifier
due to an issue with an old version of ATF. ATF has long since been
updated to a version with the fix so the workaround is no longer
necessary.
Found during review for PR 236889.
PR: 236889
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Currently, if jail_getid(3) is passed in a numeric string, it assumes that
this is a jid string and passes it back converted to an int without checking
that it's a valid/existing jid. This breaks consumers that might use
jail_getid(3) to see if it can trivially grab a jid from a name if that name
happens to be numeric but not actually the name/jid of the jail. Instead of
returning -1 for the jail not existing, it'll return the int version of the
input and the consumer will not fallback to trying other methods.
Pass the numeric input to jail_get(2) as the jid for validation, rather than
the name. This works well- the kernel enforces that jid=name if name is
numeric, so doing the safe thing and checking numeric input as a jid will
still DTRT based on the description of jail_getid.
Reported by: Wes Maag
Reviewed by: jamie, Wes Maag
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D20388
- Triple DES has been formally deprecated in Kerberos (RFC 8429)
and is soon to be deprecated in IPsec (RFC 8221).
- Blowfish is deprecated. FreeBSD doesn't support its successor
(Twofish).
- MD5 is generally considered a weak digest that has known attacks.
geli refuses to create new volumes using these algorithms via 'geli
init'. It also warns when attaching to existing volumes or creating
temporary volumes via 'geli onetime' . The plan is to fully remove
support for these algorithms in FreeBSD 13.
Note that none of these algorithms have ever been the default
algorithm used by geli(8). Users would have had to explicitly select
these algorithms when creating volumes in the past.
Reviewed by: cem, delphij
MFC after: 3 days
Relnotes: yes
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D20344
Use the .PATH mechanism instead so keep installing them from lib/libc/gen
While here revert 347961 and 347893 which are no longer needed
Discussed with: manu
Tested by: manu
ok manu@
Clang is smart enough to evaluate strlen() of a constant at compile-time.
However, that won't work in the future if we compile libc with
-ffreestanding.
Reported by: kib
Dissenting: ngie, cem
Sponsored by: The FreeBSD Foundation
The .init and .fini epilogues from crtn should be placed immediately
after any instructions in .init and .fini sections from the linked
objects. Using 16-byte alignment for the epilogues on MIPS was a bug,
but it did not cause any issue with GNU ld as GNU ld (2.17.50) fills the
padding with NOPs.
Current versions of LLD fill any padding between different object files
with trap instructions. Inserting trap padding prior to the .init/.fini
epilogue is undesriable as the resulting binary will crash at runtime.
The .init and .fini sections in object files linked between crti and
crtn must already be a multiple of the instruction size and so no
alignment directive is required in crtn. Indeed, other architectures
(except sparc64) do not specify alignment in their crtn implementations.
Reported by: arichardson
Reviewed by: andrew
Event: Waterloo Hackathon 2019
Differential Revision: https://reviews.freebsd.org/D18291
fusefs file systems may have a fsname subtype (set by mount_fusefs's "-o
subtype" option) that gets appended to the fsname as returned by statfs(2).
The subtype is set on a per-mount basis so it isn't part of the struct
vfsconf. Special-case getvfsbyname to match either the full "fusefs.foobar"
or short "fusefs" fsname.
Sponsored by: The FreeBSD Foundation
Sync libarchive with vendor.
Relevant vendor changes:
Issue #795: XAR - do not try to add xattrs without an allocated name
PR #812: non-recursive option for extract and list
PR #958: support reading metadata from compressed files
PR #999: add --exclude-vcs option to bsdtar
Issue #1062: treat empty archives with a GNU volume header as valid
PR #1074: Handle ZIP files with trailing 0s in the extra fields
(Android APK archives)
PR #1109: Ignore padding in Zip extra field data (Android APK archives)
PR #1167: fix problems related to unreadable directories
Issue #1168: fix handling of strtol() and strtoul()
PR #1172: RAR5 - fix invalid window buffer read in E8E9 filter
PR #1174: ZIP reader - fix of MSZIP signature parsing
PR #1175: gzip filter - fix reading files larger than 4GB from memory
PR #1177: gzip filter - fix memory leak with repeated header reads
PR #1180: ZIP reader - add support for Info-ZIP Unicode Path Extra Field
PR #1181: RAR5 - fix merge_block() recursion
(OSS-Fuzz 12999, 13029, 13144, 13478, 13490)
PR #1183: fix memory leak when decompressing ZIP files with LZMA
PR #1184: fix RAR5 OSS-Fuzz issues 12466, 14490, 14491, 12817
OSS-Fuzz 12466: RAR5 - fix buffer overflow when parsing huffman tables
OSS-Fuzz 14490, 14491: RAR5 - fix bad shift-left operations
OSS-Fuzz 12817: RAR5 - handle a case with truncated huffman tables
PR #1186: RAR5 - fix invalid type used for dictionary size mask
(OSS-Fuzz 14537)
PR #1187: RAR5 - fix integer overflow (OSS-Fuzz 14555)
PR #1190: RAR5 - RAR5 don't try to unpack entries marked as directories
(OSS-Fuzz 14574)
PR #1196: RAR5 - fix a potential SIGSEGV on 32-bit builds
OSS-Fuzz 2582: RAR - fix use after free if there is an invalid entry
OSS-Fuzz 14331: RAR5 - fix maximum owner name length
OSS-Fuzz 13965: RAR5 - use unsigned int for volume number + range check
Additional RAR5 reader changes:
- support symlinks, hardlinks, file owner, file group, versioned files
- change ARCHIVE_FORMAT_RAR_V5 to 0x100000
- set correct mode for readonly directories
- support readonly, hidden and system Windows file attributes
MFC after: 2 weeks
During boot we only want to measure things which *must*
be verified - this should provide more deterministic ordering.
Reviewed by: stevek
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D20297
does not ship a -lomp symlink. Also update OptionalObsoleteFiles for
this, and add 32-bit variants while here.
Submitted by: jbeich
PR: 237975
MFC after: 3 days
In all practical situations, the resolver visibility is static.
Requested by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Approved by: so (emaste)
Differential revision: https://reviews.freebsd.org/D20281
These datasets will generally be canmount=noauto,mountpoint=none (e.g.
zroot/var) but have children that may need to be mounted. Instead of
skipping that segment for no good reason, descend.
Submitted by: Wes Maag
Reported by: Wes Maag
MFC after: 3 days
libc was picked as the destination location for these because of the syscalls
that use these files as the lowest level place they are referenced.
Approved by: will (mentor), rgrimes, manu
Differential Revision: https://reviews.freebsd.org/D16728
- Add some coverage for cap_sysctl(3).
- Add a test for the case where the caller wishes to find the sysctl
output length without specifying an output buffer.
Reviewed by: oshogbo
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17856
These complement cap_sysctlbyname(3) to provide a drop-in
replacement for the corresponding libc functions.
Also revise the libcap_sysctl limit interface to provide access
to sysctls by MIB, and to avoid direct manipulation of nvlists
by the caller.
Reviewed by: oshogbo
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17854
Historically we have not distinguished between kernel wirings and user
wirings for accounting purposes. User wirings (via mlock(2)) were
subject to a global limit on the number of wired pages, so if large
swaths of physical memory were wired by the kernel, as happens with
the ZFS ARC among other things, the limit could be exceeded, causing
user wirings to fail.
The change adds a new counter, v_user_wire_count, which counts the
number of virtual pages wired by user processes via mlock(2) and
mlockall(2). Only user-wired pages are subject to the system-wide
limit which helps provide some safety against deadlocks. In
particular, while sources of kernel wirings typically support some
backpressure mechanism, there is no way to reclaim user-wired pages
shorting of killing the wiring process. The limit is exported as
vm.max_user_wired, renamed from vm.max_wired, and changed from u_int
to u_long.
The choice to count virtual user-wired pages rather than physical
pages was done for simplicity. There are mechanisms that can cause
user-wired mappings to be destroyed while maintaining a wiring of
the backing physical page; these make it difficult to accurately
track user wirings at the physical page layer.
The change also closes some holes which allowed user wirings to succeed
even when they would cause the system limit to be exceeded. For
instance, mmap() may now fail with ENOMEM in a process that has called
mlockall(MCL_FUTURE) if the new mapping would cause the user wiring
limit to be exceeded.
Note that bhyve -S is subject to the user wiring limit, which defaults
to 1/3 of physical RAM. Users that wish to exceed the limit must tune
vm.max_user_wired.
Reviewed by: kib, ngie (mlock() test changes)
Tested by: pho (earlier version)
MFC after: 45 days
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D19908
The rewrite of strcmp in assembly uses an instruction added in PowerISA
2.05, making it SIGILL on CPUs older than the POWER6, such as the PPC970 in
the PowerMac G5. Revert this until we get clang+lld, or retire the in-tree
binutils in favor of newer binutils with IFUNC support, whichever comes
first.
Otherwise concurrently running threads may inadvertently use the same
token for different messages.
Preserve the behaviour of disallowing negative message tokens, but allow
a message token value of zero since this simplifies the code a bit and
tokens are documented to be non-negative.
PR: 234442
Reported and tested by: eugen
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
This is a prerequisite of unifying kernel zlib instances.
Submitted by: Yoshihiro Ota <ota at j.email.ne.jp>
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20191
(Introduced incorrectly in r347229 earlier today.)
As pointed out by kevans, 1.6 should be used for FreeBSD 13, like r340383.
Submitted by: kevans
Reported by: kib
Reviewed by: jilles
X-MFC-with: r347229
Differential Revision: https://reviews.freebsd.org/D20187
device_printf does multiple calls to printf allowing other console messages to
be inserted between the device name, and the rest of the message. This change
uses sbuf to compose to two into a single buffer, and prints it all at once.
It exposes an sbuf drain function (drain-to-printf) for common use.
Update documentation to match; some unit tests included.
Submitted by: jmg
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16690
multiples of 8. Then the misaligned pixels at the end were not copied.
Clean up variable misuse related to this bug. The width in bytes was
first calculated correctly and used to do complicated reblocking
correctly, but it was stored in an unrelated scratch variable and later
recalculated with an off-by-1-error, so the last byte (times 4 planes)
in the intermediate copy was not copied.
This doubly-misaligned case is especially slow. Misalignment complicates
the reblocking, and each misaligment requires a read before write, and this
read is still not done from the shadow buffer.
Instead of pretending to successfully mount them while not actually
mounting anything, we'll now actually mount them *and* claim we mounted them
successfully.
Reported by: ler
MFC after: 3 days
cursor from 16x16 (with 6 columns unused) to 10x16 and rename it to
the "small" cursor. Add a "large" 19x32 cursor and use it for screen
widths larger than 800 pixels. Use libvgl's too-small indentation for
the large data declarations.
MOUSE_IMG_SIZE = 16 is still part of the API. If an application supplies
invalid bitmaps for the cursor, then the results may be different from
before.
complications in the previous methods.
r346761 broke showing the mouse cursor after changing its state from
off to on (including initially), since showing the cursor uses the
state to decide whether to actually show and the state variable was
not changed until after null showing. Moving the mouse or copying
under the cursor fixed the problem. Fix this and similar problems for
the on to off transition by changing the state variable before drawing
the cursor.
r346641 failed to turn off the mouse cursor on exit from vgl. It hid
the cursor only temporarily for clearing. This doesn't change the state
variable, so unhiding the cursor after clearing restored the cursor if its
state was on. Fix this by changing its state to VGL_MOUSEHIDE using the
application API for changing the state.
Remove the VGLMouseVisible state variable and the extra states given by it.
This was an optimization that was just an obfuscation in at least the
previous version.
Staticize VGLMouseAction(). Remove VGLMousePointerShow/Hide() except as
internals in __VGLMouseMode(). __VGLMouseMouseMode() is the same as the
application API VGLMouseMouseMode() except it returns the previous mode
which callers need to know to restore it after hiding the cursor.
Use the refactoring to make minor improvements in a simpler way than was
possible:
- in VGLMouseAction(), only hide and and unhide the mouse cursor if the
mouse moved
- in VGLClear(), only hide and and unhide the mouse cursor if the clearing
method would otherwise clear the cursor.
cursor must be merged with the shadow buffer on the way to the screen,
and __VGLBitmapCopy() now has an option to do exactly that. This is
insignificantly less efficient.
display, not just in the unpanned top left corner. This currently
makes no difference since the kernel erroneously doesn't allow moving
the cursor completely outside of the unpanned corner.
hiding the mouse cursor. The showing and hiding is often done
asynchronously in a not very safe signal handler, but the state of
these registers and much more is protected from the signal handler
in a better way by deferring mouse signals while the state is in use.
support for 24-bit modes.
The non-segmented case has worked for a long time, but the segmented
case could never have worked since 24-bit accesses may cross a window
boundary but the window was not changed in the middle of the specialized
24-bit accesses for writing a single pixel.
VGLSetVScreenSize(), but is not restored by mode switches to at least
standard text mode, so must be restored explicitly. Standard text mode
displayed blanks when the line width was doubled.
nonzero height, the first line in the original order was not copied, and
for zero height, garbage lines before the first were copied until a crash
occurred.
SHLIBDIR should still be optionally set, just before src.opts.mk is included
so that libcompat can properly override it. This fixes lib32 failures
reported by both Jenkins and Michael Butler.
Reported by: Michael Butler <imb@protected-networks.net>
MFC after: 3 days
X-MFC-With: r346546
Rob's patch in D18564 cemented the SHLIBDIR because bsd.own.mk (included by
src.opts.mk) sets it to /usr/lib. r346546 did somehow not apply this part of
the patch, leaving it to get installed to the wrong place and subsequently
removed via ObsoleteFiles.
Reported by: jkim
MFC after: 3 days
X-MFC-With: r346546
in r346631. VGLEnd() clears some state variables as it restores state,
but not all of them, so it still needs to clear a single state variable
to indicate that it has completed. Put this clearing back where it was
(at the start instead of the end) to avoid moving bugs in the signal
handling.
VGLMouseFreeze() now only defers mouse signals and leaves it to higher
levels to hide and unhide the mouse cursor if necessary. (It is never
necessary, but is done to simplify the implementation. It is slow and
flashes the cursor. It is still done for copying bitmaps and clearing.)
VGLMouseUnFreeze() now only undoes 1 level of freezing. Its old
optimization to reduce mouse redrawing is too hard to do with unhiding
in higher levels, and its undoing of multiple levels was a historical
mistake.
VGLMouseOverlap() determines if a region overlaps the (full) mouse region.
VGLMouseFreezeXY() is the freezing and a precise overlap check combined
for the special case of writing a single pixel. This is the single-pixel
case of the old VGLMouseFreeze() with cleanups.
Fixes:
- check in more cases that the application didn't pass an invalid VIDBUF
- check for errors from copying a bitmap to the shadow buffer
- freeze the mouse before writing to the shadow buffer in all cases. This
was not done for the case of writing a single pixel (there was a race)
- don't spell the #defined values for VGLMouseShown as 0, 1 or boolean.
The mouse signal SIGUSR2 was not turned off for normal termination and
in some other cases. Thus mouse signals arriving after the frame
buffer was unmapped always caused fatal traps. The fatal traps occurred
about 1 time in 5 if the mouse was wiggled while vgl is ending.
The screen switch signal SIGUSR1 was turned off after clearing the
flag that it sets. Unlike the mouse signal, this signal is handled
synchronously, but VGLEnd() does screen clearing which does the
synchronous handling. This race is harder to lose. I think it can
get vgl into deadlocked state (waiting in the screen switch handler
with SIGUSR1 to leave that state already turned off).
Turn off the mouse cursor before clearing the screen in VGLEnd().
Otherwise, clearing is careful to not clear the mouse cursor. Undrawing
an active mouse cursor uses a lot of state, so is dangerous for abnormal
termination, but so is clearing. Clearing is slow and is usually not
needed, since the kernel also does it (not quite right).
sbin/veriexec will ignore entries that have no hash anyway,
but loader needs to be explicitly told that such files are
ok to ignore (not verify).
We will report as Unverified depending on verbose level,
but with no reason - because we are not rejecting the file.
Reviewed by: imp, mindal_semihalf
Sponsored by: Juniper Networks
MFC After: 1 week
Differential Revision: https://reviews.freebsd.org//D20018
Summary:
Optimize strcmp for powerpc64.
Data is loaded by double words and cmpb intruction is used to find '\0'.
Some performance gain rates between the current and the optimized solution:
String size (bytes) Gain rate
<=8 0.59%
<=16 1.92%
32 3.02%
64 5.60%
128 10.16%
256 18.05%
512 30.18%
1024 42.82%
Submitted by: alexandre.yamashita_eldorado.org.br,
leonardo.bianconi_eldorado.org.br
Differential Revision: https://reviews.freebsd.org/D15220
worked right for white interiors and black borders was used). Advertise
this by changing the default colors to a red interior and a white
border (the same as the kernel default). Add undocumented env variables
for changing these colors. Also change to the larger and better-shaped
16x10 cursor sometimes used in the kernel. The kernel choice is
fancier, but libvgl is closer to supporting the larger cursors needed
in newer modes.
The (n)and-or logic for the cursor doesn't work right for more than 2
colors. The (n)and part only masks out all color bits for the pixel
under the cursor when all bits are set in the And mask. With more
complicated logic, the non-masked bits could be used to implement
translucent cursors, but they actually just gave strange colors
(especially in packed and planar modes where the bits are indirect
through 1 or 2 palettes so it is hard to predict the final color).
They also gave a bug for writing pixels under the cursor. The
non-masked bits under the cursor were not combined in this case.
Drop support for combining with bits under the cursor by making any nonzero
value in the And mask mean all bits set.
Convert the Or mask (which is represented as a half-initialized 256-color
bitmap) to a fully initialized bitmap with the correct number of colors.
The 256-color representation must be as in 3:3:2 direct mode iff the final
bitmap has more than 256 colors. The conversion of colors is not very
efficient, so convert at initialization time.
There's no reason why a special case needs to be added specifically for amd64,
arm, and i386, as the code is written in machine architecture agnostic C/C++.
This will make it possible for all supporting clang architectures to produce
runtime coverage with `--coverage`.
MFC after: 2 weeks
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D20003
This change allows the user to once again override the C++ standard, restoring
high-level pre-r345708 behavior.
This also unbreaks building lib/ofed/libibnetdisc/Makefile with a non-C++11
capable compiler, e.g., g++ 4.2.1, as the library supported being built with
older C++ standards.
MFC after: 2 weeks
MFC with: r345708
Reviewed by: emaste
Reported by: jbeich
Differential Revision: https://reviews.freebsd.org/D19895 (as part of a larger change)
Previous spellings of my name (NGie, Ngie) weren't my legal spelling. Use Enji
instead for clarity.
While here, remove "All Rights Reserved" from copyrights I "own".
MFC after: 1 week
Relative performance to rand(3) is sort of irrelevant; they do different things
and a user with sensitivity to RNG performance won't use libc random(3) anyway.
The historical note about bad seeding is long obsolete, referring to a 1996 or
earlier version of FreeBSD.
Sponsored by: Dell EMC Isilon
libbe currently only provides an API to create a recursive boot environment,
without any formal support for intentionally limiting the depth. This
changeset adds an API, be_create_depth, that may be used to arbitrarily
restrict the depth of the new BE.
Submitted by: Rob Fairbanks <rob.fx907 gmail com>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18564
Initialize `oldlen` to the size of the value, instead of leaving the value
unitialized. Leaving it unitialized seems to work by accident on amd64 when
running 64-bit programs, but not on i386.
This matches patterns in use in other programs.
PR: 237458
Approved by: emaste (mentor; implicit)
MFC after: 1 week
Tested on: ^/head (amd64), ^/stable/11 (i386)
code for reading from the frame buffer.
Reading from the frame buffer is usually much slower than writing to
the frame buffer. Typically 10 to 100 times slower. It old modes,
it takes many more PIOs, and in newer modes with no PIOs writes are
often write-combined while reads remain uncached.
Reading from the frame buffer is not very common, so this change doesn't
give speedups of 10 to 100 times. My main test case is a floodfill()
function that reads about as many pixels as it writes. The speedups
are typically a factor of 2 to 4.
Duplicating writes to the shadow buffer is slower when no reads from the
frame buffer are done, but reads are often done for the pixels under the
mouse cursor, and doing these reads from the shadow buffer more than
compensates for the overhead of writing the shadow buffer in at least the
slower modes. Management of the mouse cursor also becomes simpler.
The shadow buffer doesn't take any extra memory, except twice as much
in old 4-plane modes. A buffer for holding a copy of the frame buffer
was allocated up front for use in the screen switching signal handler.
This wasn't changed when the handler was made async-signal safe. Use
the same buffer the shadow (but make it twice as large in the 4-plane
modes), and remove large special code for writing it as well as large
special code for reading ut. It used to have a rawer format in the
4-plane modes. Now it has a bitmap format which takes twice as much
memory but can be written almost as fast without special code.
VIDBUFs that are not the whole frame buffer were never supported, and the
change depends on this. Check for invalid VIDBUFs in some places and do
nothing. The removed code did something not so good.
not doing any unnecessary PIO instructions or refusing to start when the
i/o privilege needed for these instructions cannot be acquired.
This turns off useless palette management in direct modes. Palette
management had no useful effect since the hardware palette is not used
in these modes.
This transiently acquires i/o privilege if possible as needed to give
VGLSetBorder() and VGLBlankDisplay() a chance of working. Neither has
much chance of working. I was going to drop support for them in direct
modes, but found that VGLBlankDisplay() still works with an old graphics
card on a not so old LCD monitor.
This has some good side effects: reduce glitches for managing the palette
for screen switches, and speed up and reduce async-signal-unsafeness in
mouse cursor drawing.
screen bitmap and within a single MEMBUF were broken when first source
line is before the first destination line and the sub-bitmaps overlap.
The fix just copies horizontal lines in reverse order when the first
source line is before the first destination line. This switches
directions unnecessarily in some cases, but the switch is about as
fast as doing a precise detection of overlaps. When the first lines
are the same, there can be undetected overlap in the horizontal
direction. The old code already handles this mostly accidentally by
using bcopy() for MEMBUFs and by copying through a temporary buffer
for the screen bitmap although the latter is sub-optimal in direct
modes.
It is a useful arc4random wrapper in the kernel for much the same reasons as
in userspace. Move the source to libkern (because kernel build is
restricted to sys/, but userspace can include any file it likes) and build
kernel and libc versions from the same source file.
Copy the documentation from arc4random_uniform(3) to the section 9 page.
While here, add missing arc4random_buf(9) symlink.
Sponsored by: Dell EMC Isilon
compat mode or not. This is useful when implementing compatibility ioctl(2)
handlers in userspace.
MFC after: 1 week
Sponsored by: Mellanox Technologies
Add fileargs_lstat function to cap_fileargs casper service to be able to
lstat files while in capability mode. It can only lstat files given in
fileargs_init.
Submitted by: Bora Özarslan <borako.ozarslan@gmail.com>
Reviewed by: oshogbo, cem (partial)
MFC after: 3 weeks
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19548
with old kernels, by breaking the support for large frame buffers in the
same way as for current kernels.
Large frame buffers may be too large to map into kva, and the kernel
(syscons) only uses the first screen page anyway, so r203535, r205557
and 248799 limit the buffer size in VESA modes to the first screen
page, apparently without noticing that this breaks applications by
using the same limit for user mappings as for kernel mappings. In
vgl, this makes the virtual screen the same as the physical screen.
However, this is almost a feature since clearing and switching large
(usually mostly unused) frame buffers takes too long. E.g., on a 16
year old low-end AGP card it takes about 12 seconds to clear the 128MB
frame buffer in old kernels that map it all and also map it with slow
attributes (e.g., uncacheable). Older PCI cards are even slower, but
usually have less memory. Newer PCIe cards are faster, but may have
many GB of memory. Also, vgl malloc()s a shadow buffer with the same
size as the frame buffer, so large frame buffers are even more wasteful
in applications than in the kernel.
Use the same limit in vgl as in newer kernels.
Virtual screens and panning still work in non-VESA modes that have
more than 1 page. The reduced buffer size in the kernel also breaks
mmap() of the last physical page in modes where the reduced size is
not a multiple of the physical page size. The same reduction in vgl
only reduces the virtual screen size.
random.3 is only "better" in contrast to rand.3. Both are non-cryptographic
pseudo-random number generators. The opening blurbs of each's DESCRIPTION
section does emphasize this, and correctly directs unfamiliar developers to
arc4random(3). However, the summary (".Nd" or Name description) of random.3
conflicted in tone and message with that warning.
Resolve the conflict by clarifying in the Nd section that random(3) is
non-cryptographic and pseudo-random. Elide the "better" qualifier which
implied a comparison but did not provide a specific object to contrast.
Sponsored by: Dell EMC Isilon
Since inits for the main binary are run from rtld (for some time), the
rtld_exit atexit(3) handler, which is passed from rtld to the program
entry and installed by csu, is installed after any atexit(3) handlers
installed by main binary constructors. This means that rtld_exit() is
fired before main binary handlers.
Typical C++ static constructors are executed from init (either binary
or libs) but use atexit(3) to ensure that destructors are called in
the right order, independent of the linking order. Also, C++
libraries finalizers call __cxa_finalize(3) to flush library'
atexit(3) entries. Since atexit(3) entry is cleared after being run,
this would be mostly innocent, except that, atexit(rtld_exit) done
after main binary constructors, makes destructors from libraries
executed before destructors for main.
Fix by reordering atexit(rtld_exit) before inits for main binary, same
as it happened when inits were called by csu. Do it using new private
libc symbol with pre-defined ABI.
Reported. tested, and reviewed by: kan
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
depths > 8. Add some smaller optimizations for these depths. Use a
more generic method for all depths >= 8, although this gives tiny
pessimizations for these depths.
For clearing the whole frame buffer, avoid the same pessimizations
for depths > 8. Add some larger optimizations for these depths. Use
an even more generic method for all depths >= 8 to give the optimizations
for depths > 8 and a tiny pessimization for depth 8.
The main pessimization was that old versions of bcopy() copy 1 byte at a
time for all trailing bytes. (i386 still does this. amd64 now pessimizzes
large sizes instead of small ones if the CPU supports ERMS. dev/fb gets
this wrong by mostly not using the bcopy() family or the technically correct
bus space functions but by mostly copying 2 bytes at a time using an
unoptimized loop without even volatile declarations to prevent the compiler
rewriting it.)
The sizes here are 1, 2, 3 or 4 bytes, so depths 9-16 were up to twice as
slow as necessary and depths 17-24 were up to 3 times slower than necessary.
Fix this (except depths 17-24 are still up to 2 times slower than necessary)
by using (builtin) memcpy() instead of bcopy() and reorganizing so that the
complier can see the small constant sizes. Reduce special cases while
reorganizing although this is slightly slower than adding special cases.
The compiler inlining (and even -O2 vs -O0) makes little difference compared
with reducing the number of accesses except on modern hardware it gives a
small improvement.
Clearing was also pessimized mainly by the extra accesses. Fix it quite
differently by creating a MEMBUF containing 1 line (in fast memory using
a slow method) and copying this. This is only slightly slower than reducing
everything to efficient memset()s and bcopy()s, but simpler, especially
for the segmented case. This works for planar modes too, but don't use it
then since the old method was actually optimal for planar modes (it works
by moving the slow i/o instructions out of inner loops), while for direct
modes the slow instructions were all in the invisible inner loop in bcopy().
Use htole32() and le32toh() and some type puns instead of unoptimized
functions for converting colors. This optimization is mostly in the noise.
libvgl is only supported on x86, so it could hard-code the assumption that
the byte order is le32, but the old conversion functions didn't hard-code
this.
* Use `MIN` instead of similar hand rolled macro.
* Sort headers.
* Use `errno.h` instead of `sys/errno.h`.
* Wrap the argument to sizeof in parentheses for clarity.
* Remove `__BSD_VISIBLE` and `_XOPEN_SOURCE` #defines to mute warnings about
incompatible snprintf definitions.
This fixes a number of warnings I've been seeing lately in my builds.
Sort makefile variables per style.Makefile(9) (`CFLAGS`/`CWARNFLAG.gcc`) and
bump `WARNS` to 3.
MFC after: 2 weeks
Reviewed by: jtl
Approved by: jtl (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D19851
Our home-rolled solution didn't quite capture all of the details, and we
didn't actually validate snapshot names at all. zfs_name_valid captures the
important details, but it doesn't necessarily expose the errors that we're
wanting to see in the be_validate_* functions. Validating lengths
independently, then the names, should make this a non-issue.
the same code as the VIDBUF8 case, so it only worked for depths <= 8.
The 2 directions for copying between VIDBUFs and MEMBUFs worked by using
a Read/Write organization which makes the destination a VIDBUF so the
MEMBUF case was not reached, and the VIDBUF cases have already been fixed.
Fix this by removing "optimizations" for the VIDBUF8 case so that the
MEMBUF case can fall through to the general (non-segmented) case. The
optimizations were to duplicate code for the VIDBUF8 case so as to
avoid 2 multiplications by 1 at runtime. This optimization is not useful
since the multiplications are not in the inner loop.
Remove the same "optimization" for the VIDBUF8S case. It was even less
useful there since it duplicated more to do relatively less.
the file associated with the given file descriptor.
Reviewed by: kib, asomers
Reviewed by: cem, jilles, brooks (they reviewed previous version)
Discussed with: pjd, and many others
Differential Revision: https://reviews.freebsd.org/D14567
There are a few places that use hand crafted versions of the macros
from sys/netinet/in.h making it difficult to actually alter the
values in use by these macros. Correct that by replacing handcrafted
code with proper macro usage.
Reviewed by: karels, kristof
Approved by: bde (mentor)
MFC after: 3 weeks
Sponsored by: John Gilmore
Differential Revision: https://reviews.freebsd.org/D19317
provider grows, GELI will expand automatically and will move the metadata
to the new location of the last sector.
This functionality is turned on by default. It can be turned off with the
-R flag, but it is not recommended - if the underlying provider grows and
automatic expansion is turned off, it won't be possible to attach this
provider again, as the metadata is no longer located in the last sector.
If the automatic expansion is turned off and the underlying provider grows,
GELI will only log a message with the previous size of the provider, so
recovery can be easier.
Obtained from: Fudo Security
from 1.0.0:
Add "continuation" flag, to allow multiple "xo" invocations in a single line of output (#58)
Add --top-wrap to make top-level JSON wrappers
Add --{open,close}-{list,instace} options
Add xo_xml_leader(), to detect use of some bogus XML tags. It's still bad form, but it's a little safer now
Avoid call to xo_write before xo_flush, since the latter calls the former
Check return code from xo_flush_h properly (<0) (FreeBSD Bug 236935)
For JSON output, avoid newline before a container's close brace (#62)
Merge branch 'text_only' of https://github.com/zvr/libxo into zvr-text_only
Use XO_USE_INT_RETURN_CODES, not USE_INT_RETURN_CODES
add docs for --continuation
add docs for --not-first
call xo_state_set_flags before values and close containers; add XOIF_MADE_OUTPUT flag to track state; make proper empty JSON objects in xo_finish
color_map code has to be #ifdef'd out, since the struct definition
correct xo_flush_func_t (doesn't use xo_ssize_t)
make depth change for --top-wrap only for JSON
fix to handle --top-wrap in "xo" by being more consistent with handling trailing newlines
fix to handle text-only version #64 (from zvr)
fix xo_buf_has_room for round up to the next XO_BUFSIZ, not just add XO_BUFSIZ to the size (FreeBSD Bug 236937)
update docs for new "xo" options
update functions to use xo_ssize_t
update test cases
from 1.0.1:
Add EINTEGRITY to .pot files under test/gettext/ (fix from FreeBSD)
from 1.0.2:
handle failure from xo_vnsprintf; don't add -1 to "rc"
PR: 236937, 236935
Submitted by: phil
Reported by: Alfonso S. Siciliano <alfix86@gmail.com>
MFC after: 2 weeks
To use bectl in an example, when one creates a new boot environment with
either `bectl create <be>` or `bectl create -e <otherbe> <be>`, libbe will
take a snapshot of the original boot environment to clone. Previously, this
used %F-%T date format as the snapshot name, but this has some limitations-
attempting to create multiple boot environments in quick succession may
collide if done within the same second.
Tack a serial onto it to reduce the chances of a collision... we could still
collide if multiple processes/threads are creating boot environments at the
same time, but this is likely not a big concern as this has only been
reported as occurring in freebsd-ci setup.
MFC after: 3 days
The current approach of injecting manifest into mac_veriexec is to
verify the integrity of it in userspace (veriexec (8)) and pass its
entries into kernel using a char device (/dev/veriexec).
This requires verifying root partition integrity in loader,
for example by using memory disk and checking its hash.
Otherwise if rootfs is compromised an attacker could inject their own data.
This patch introduces an option to parse manifest in kernel based on envs.
The loader sets manifest path and digest.
EVENTHANDLER is used to launch the module right after the rootfs is mounted.
It has to be done this way, since one might want to verify integrity of the init file.
This means that manifest is required to be present on the root partition.
Note that the envs have to be set right before boot to make sure that no one can spoof them.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: sjg
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D19281
This patch adds a new table begemotSnmpdTransInetTable that uses the
InetAddressType textual convention and can be used to create listening
ports for IPv4, IPv6, zoned IPv6 and based on DNS names. It also supports
future extension beyond UDP by adding a protocol identifier to the table
index. In order to support this gensnmptree had to be modified.
Submitted by: harti
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D16654
Per the upstream pull-request [1]:
```
gtest prior to this change would completely ignore `GTEST_SKIP()` if
called in `Environment::SetUp()`, instead of bailing out early, unlike
`Test::SetUp()`, which would cause the tests themselves to be skipped.
The only way (prior to this change) to skip the tests would be to
trigger a fatal error via `GTEST_FAIL()`.
Desirable behavior, in this case, when dealing with
`Environment::SetUp()` is to check for prerequisites on a system
(example, kernel supports a particular featureset, e.g., capsicum), and
skip the tests. The alternatives prior to this change would be
undesirable:
- Failing sends the wrong message to the test user, as the result of the
tests is indeterminate, not failed.
- Having to add per-test class abstractions that override `SetUp()` to
test for the capsicum feature set, then skip all of the tests in their
respective SetUp fixtures, would be a lot of human and computational
work; checking for the feature would need to be done for all of the
tests, instead of once for all of the tests.
For those reasons, making `Environment::SetUp()` handle `GTEST_SKIP()`,
by not executing the testcases, is the most desirable solution.
In order to properly diagnose what happened when running the tests if
they are skipped, print out the diagnostics in an ad hoc manner.
Update the documentation to note this change and integrate a new test,
gtest_skip_in_environment_setup_test, into the test suite.
This change addresses #2189.
Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
```
The goal with my merging in this change is to avoid requiring extensive
refactoring/retesting of test suites when ensuring prerequisites are met,
e.g., checking for a CAPABILITIES-enabled kernel before running capsicum-test
(see D19758 for more details).
The proof-of-concept is being imported before accepted by the upstream
project due to the fact that the upstream project is undergoing a potential
development freeze and the maintainers aren't responding to my PR.
1. https://github.com/google/googletest/pull/2203
Reported by: asomers (https://github.com/google/googletest/issues/2189)
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 2 months
Differential Revision: https://reviews.freebsd.org/D19765
'be_destroy' can destroy a boot environment (by name) or a given snapshot.
If the target to be destroyed is a dataset, check if it's mounted. We don't
want to check if the origin dataset is mounted when destroying a snapshot.
PR: 236043
Submitted by: Rob Fairbanks <rob.fx907 gmail com>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D19650
The current logic for CSTD/CXXSTD requires homogenity as far as the
supported C/C++ standards, which is a sensible default. However, when
dealing with differing versions of C++, some code may compile with C++11, but
not C++17 (for instance). So in order to avoid having people convert over their
code to the new standard, give the users the ability to specify the standard on
a per-program basis.
This will allow a user to override the supporting standard for a set of
programs, mixing C++11 with C++14 (for instance).
Reviewed by: asomers
Apprved by: emaste (mentor)
MFC after: 1 month
MFC with: r345708
Differential Revision: https://reviews.freebsd.org/D19738
CXXSTD was added as the C++ analogue to CSTD.
CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`,
otherwise for older versions of g++.
This change standardizes the CXXSTD variable, originally added to
googletest.test.inc.mk as part of r345203.
As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.
Notes:
This value is not sanity checked in bsd.sys.mk, however, given the two
most used C++ compilers on FreeBSD (clang++ and g++) support both modes, it is
likely to work with both toolchains. This method will be refined in the future
to support more variants of C++, as not all versions of clang++ and g++ (for
instance) support C++14, C++17, etc.
Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD.
Example:
Before this commit:
```
CXXFLAGS+= -std=c++14
```
After this commit:
```
CXXSTD= c++14
```
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 1 month
MFC with: r345203, r345704, r345705
Relnotes: yes
Tested with: make tinderbox
Differential Revision: https://reviews.freebsd.org/D19732
When a review is closed via Phabricator it updates the patch attached to the
review. I downloaded the raw patch from Phabricator, applied it, and repeated
my mistake from r345704 by accident mixing content from D19732 and D19738.
For my own personal sanity, I will try not to mix reviews like this in the
future.
MFC after: 1 month
MFC with: r345706
Approved by: emaste (mentor, implicit)
CXXSTD was added as the C++ analogue to CSTD.
CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`,
otherwise for older versions of g++.
This change standardizes the CXXSTD variable, originally added to
googletest.test.inc.mk as part of r345203.
As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.
Notes:
This value is not sanity checked in bsd.sys.mk, however, given the two
most used C++ compilers on FreeBSD (clang++ and g++) support both modes, it is
likely to work with both toolchains. This method will be refined in the future
to support more variants of C++, as not all versions of clang++ and g++ (for
instance) support C++14, C++17, etc.
Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD.
Example:
Before this commit:
```
CXXFLAGS+= -std=c++14
```
After this commit:
```
CXXSTD= c++14
```
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 1 month
MFC with: r345203, r345704, r345705
Relnotes: yes
Tested with: make tinderbox
Differential Revision: https://reviews.freebsd.org/D19732
I accidentally committed code from two reviews. I will reintroduce the code to
bsd.progs.mk as part of a separate commit from r345704.
Approved by: emaste (mentor, implicit)
MFC after: 2 months
MFC with: r345704
CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`,
otherwise for older versions of g++.
This change standardizes the CXXSTD variable, originally added to
googletest.test.inc.mk as part of r345203.
As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.
Notes:
This value is not sanity checked in bsd.sys.mk, however, given the two
most used C++ compilers on FreeBSD (clang++ and g++) support both modes, it is
likely to work with both toolchains. This method will be refined in the future
to support more variants of C++, as not all versions of clang++ and g++ (for
instance) support C++14, C++17, etc.
Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD.
Example:
Before this commit:
```
CXXFLAGS+= -std=c++14
```
After this commit:
```
CXXSTD= c++14
```
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D19732
If dso uses initial exec TLS mode, rtld tries to allocate TLS in
static space. If there is no space left, the dlopen(3) fails. If space
if allocated, initial content from PT_TLS segment is distributed to
all threads' pcbs, which was missed and caused un-initialized TLS
segment for such dso after dlopen(3).
The mode is auto-detected either due to the relocation used, or if the
DF_STATIC_TLS dynamic flag is set. In the later case, the TLS segment
is tried to allocate earlier, which increases chance of the dlopen(3)
to succeed. LLD was recently fixed to properly emit the flag, ld.bdf
did it always.
Initial test by: dumbbell
Tested by: emaste (amd64), ian (arm)
Tested by: Gerald Aryeetey <aryeeteygerald_rogers.com> (arm64)
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D19072
Correct restoring was only attempted for mode 258 (800x600x4 P). (This
was the only useful graphics mode supported in the kernel until 10-15
years ago, and is still the only one explicitly documented in the man
page). The comment says that it is the geometry (subscreen size) that
is restored, but it seems to only be necessary to restore the font
size, with the geometry only needed since it is set by the same ioctl.
The font size was not restored for this mode, but was forced to 16.
For other graphics modes, the font size was clobbered to 0. This
confuses but doesn't crash the kernel (font size 0 gives null text).
This confuses and crashes vidcontrol. The only way to recover was to
use vidcontrol to set the mode to any text mode on the way back to the
original graphics mode.
vidcontrol gets this wrong in the opposite way when backing out of
changes after an error. It restores the font size correctly, but
forces the geometry to the full screen size.
r80270 has the usual wrong fix for unsafe signal handling -- just set
a flag and return to let an event loop check the flag and do safe
handling. This never works for signals like SIGBUS and SIGSEGV that
repeat and works poorly for others unless the application has an event
loop designed to support this.
For these signals, clean up unsafely as before, except for arranging that
nested signals are fatal and forcing a nested signal if the cleanup doesn't
cause one.
method as in /bin/sh.
We still do technically undefined things in the signal handler, but it
is safe in practice to access state that is protected by INTOFF/INTON.
In a recent commit, I sprinkled VGLMouseFrozen++/-- operations in
places that need INTOFF/INTON. This prevented clobbering of pixels
under the mouse, but left mouse signals deferred for too long. It is
necessary to call the signal handler when the count goes to 0. Old
versions did this in the unfreeze function, but didn't block actual
signals, so the signal handler raced itself. The sprinkled operations
reduced the races, but when then worked to block a race they left
signals deferred for too long.
Use INTOFF/INTON to fix complete loss of mouse signals while reading
the mouse status. Clobbering of the state was prevented by SIG_IGN'ing
mouse signals, but that has a high overhead and broke more than it
fixed by losing mouse signals completely. sigprocmask() works to block
signals without losing them completely, but its overhead is also too
high.
libvgl's mouse signal handling is often worse than none. Applications
can't block waiting for a mouse or keyboard or other event, but have
to busy-wait. The SIG_IGN's lost about half of all mouse events while
busy-waiting for mouse events.
It started truncating its color arg to 8 bits using plot() in r229415.
The version in r229415 is also more than 3 times slower in segmented
modes, by doing more syscalls to move the window.
segmented modes.
Also fix some style bugs in the 2 changed lines. libvgl uses a very non-KNF
style with 2-column indentation with no tabs except for regressions.
r345620 by kib@ fixed the rtld issue that caused a crash at startup
during resolution of libc's ifuncs with BIND_NOW.
PR: 233333
Sponsored by: The FreeBSD Foundation
r322369's use of basename(3) was incorrect and worked by accident so
long as the pidfile path was absolute or consisted of a single
component. Fix the basename() usage and add a regression test.
Reported by: 0mp
Reviewed by: cem
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D19728
Reading of single pixels didn't look under the cursor.
Copying of 1x1 bitmaps didn't look under the cursor for either reading
or writing.
Copying of larger bitmaps looked under the cursor for at most the
destination.
Copying of larger bitmaps looked under a garbage cursor (for the Display
bitmap) when the destination is a MEMBUF. The results are not used, so
this only wasted time and flickered the cursor.
Writing of single pixels looked under a garbage cursor for MEMBUF
destinations, as above except this clobbered the current cursor and
didn't update the MEMBUF. Writing of single pixels is not implemented
yet in depths > 8. Otherwise, writing of single pixels worked. It was
the only working case for accessing pixels under the cursor.
Clearing of MEMBUFs wasted time freezing the cursor in the Display bitmap.
The fixes abuse the top bits in the color arg to the cursor freezing
function to control the function. Also clear the top 8 bits so that
applications can't clobber the control bits or create 256 aliases for
every 24-bit pixel value in depth 32.
Races fixed:
Showing and hiding the cursor only tried to avoid races with the mouse
event signal handler for internal operations. There are still many
shorter races from not using volatile or sig_atomic_t for the variable
to control this. This variable also controls freezes, and has more
complicated states than before.
The internal operation of unfreezing the cursor opened a race window
by unsetting the signal/freeze variable before showing the cursor.
depths for the source and target are not supported. The bits for higher
numbered planes (mostly for red) were either not copied or were copied to
lower numbered planes for nearby pixels.
Quick fix for creation of mouse cursor bitmaps in all depths. This fix is
only complete for the default lightwhite cursor with a black frame.
Even the lightwhite and black colors are hard to find. The templates
use 0xff for lightwhite, but that means brightblue in the simplest mode
(Truecolor depth 24). Other modes are even more complicated -- they are
singly or doubly indirect throught palette(s) and changing of the palettes
by applications is supported.
Details:
Replicate the template value for Truecolor modes to fill out the target
depth (and more for depths not a multiple of 8). Do this for every
drawing of the cursor so that it sort of works for mouse cursor bitmaps
set by applications.
Use 0xf for lightwhite in most other modes. Only do this for the
default cursor so that it doesn't affect mouse cursor bitmaps set by
applications. 0xf mostly works because it was originally for CGA
lightwhite and is emulated using 1 or 2 indirections on EGA and VGA.
0x3f (EGA white) and 0xff (VGA black) direct palette indexes mostly
don't work since backwards compatibility inhibits or prevents them
representing lightwhite. But 0x3f (EGA white) must be used for mode
37 (VGA_MODEX) (320x240x8 V) since this mode is closer to EGA than VGA.
was not taken modulo the window size in VGLClear().
Segmented modes also need a kernel fix to almost work. The ioctl to set
the window origin is broken.
These bugs are rarely problems since non-VESA modes only need
segmentation to support multiple pages but libvgl doesn't support
multiple pages and treats these modes as non-segmented, and VESA modes
are usually mapped linearly except on old hardware so they really are
non-segmented.
to match the change in its declaration. Change the declaration back to
"byte color" since setting of the border color is not supported for more
than 256 colors.
VGLBitmapString() and VGLSetBorder() so as to not truncate to 8 bits.
Complete the corresponding fix for VGLGetXY() and VGLPutXY() (parts
of the man page were out of date).
Since the font format is undocumented, it is unclear how non-multiples
of 8 should be padded to bytes in the font file. Use the same
representation as bdf text format (big- endian, with padding in the
lower bits).
There seems to be no alternative to reading each plane independently using
3 slow i/o's per plane (this delivers 8 nearby pixels, but we don't buffer
the results so run 8 times slower than necessary.
All the code for this was there, but it was ifdefed out and replaced by
simpler code that cannot work in planar modes. The ifdefed out code
was correct except it was missing a volatile declaration, so compilers
optimized the multiple dummy reads in it to a single read.
Support for 16-bit and 32-bit Truecolor modes was supposed to be
complete in r70991 of main.c and in nearby revisions for other files, but
it was broken by the overruns in most cases (all cases were the mouse
is enabled, and most cases where bitmaps are used). r70991 also
uninintentionally added support for depths 9-15, 17-23 and 25-31.
Depth 24 was more obviously broken and its support is ifdefed out. In
the other ranges, only depth 15 is common. It was broken by buffer
overruns in all cases.
bitmap.c:
- the static buffer was used even when it was too small (but it was
large enough to often work accidentally in depth 16)
- the size of the dynamically allocated buffer was too small
- the sizing info bitmap->PixelBytes was not inititialzed in the bitmap
constructor. It often ended up as 0 for MEMBUFs, so using it in more
places gave more null pointer accesses. (It is per-bitmap, but since
conversion between bitmaps of different depths is not supported (except
from 4 bits by padding to 8), it would work better if it were global.)
main.c:
- depths were rounded down instead of up to a multiple of 8, so PixelBytes
was 1 too small for depths above 8 except 16, 24 and 32.
- PixelBytes was not initialized for 4-bit planar modes. It isn't really
used for frame buffer accesses in these modes, but needs to be 1 in
MEMBUF images.
mouse.c:
- the mouse cursor buffers were too small.
vgl.h:
- PixelBytes was not initialized in the static bitmap constructor. It
should be initialized to the value for the current mode, but that is
impossible in a static constructor. Initialize it to -1 so as to
fail if it is used without further initialization.
All modes that are supposed to be supported now don't crash in
nontrivial tests, and almost work. Missing uses of PixelBytes now
give in-bounds wrong pointers instead of overruns. Misconversions of
bitmaps give multiple miscolored mouse cursors instead of 1 white one,
and similarly for bitmaps copied through a MEMBUF.
args (neither MAP_PRIVATE nor MAP_SHARED). It was broken in r271635
and/or r271724 by stricter checking. The compatibility code in r271724
doesn't work for my old binaries (actually new binaries with old
libraries).
PR: needed to test the fix for PR 162373
r343532 noted the difference between "hw.realmem" and "hw.physmem", which I
was previously unaware of. I discovered that neither sysctl had a
description visible via `sysctl -d', so I found where they were defined and
added suitable descriptions. While in the file, I went ahead and added
descriptions for all the others which lacked them. I also updated sysctl.3
accordingly
Reviewed by: kib, bcr
MFC after: 1 weeks
Sponsored by: Panasas
Differential Revision: https://reviews.freebsd.org/D19007
This commit backports revisions 00938b2b228f3b70d3d9e51f29a1505bdad43f1e and
59f90a338bce2376b540ee239cf4e269bf6d68ad from googletest's master branch to
our included version of googletest, which is based on 1.8.1. It adds the
GTEST_SKIP feature, which is very useful for a project like FreeBSD where
some tests depend on particular system configurations.
Reviewed by: ngie
Obtained from: github.com/google/googletest
MFC after: 2 months
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/rS345331
This makes it more consistent with other filesystems, which all end in "fs",
and more consistent with its mount helper, which is already named
"mount_fusefs".
Reviewed by: cem, rgrimes
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19649
[ELF] Support --{,no-}allow-shlib-undefined
Summary:
In ld.bfd/gold, --no-allow-shlib-undefined is the default when
linking an executable. This patch implements a check to error on
undefined symbols in a shared object, if all of its DT_NEEDED entries
are seen.
Our approach resembles the one used in gold, achieves a good balance
to be useful but not too smart (ld.bfd traces all DSOs and emulates
the behavior of a dynamic linker to catch more cases).
The error is issued based on the symbol table, different from
undefined reference errors issued for relocations. It is most
effective when there are DSOs that were not linked with -z defs (e.g.
when static sanitizers runtime is used).
gold has a comment that some system libraries on GNU/Linux may have
spurious undefined references and thus system libraries should be
excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The
story may have changed now but we make --allow-shlib-undefined the
default for now. Its interaction with -shared can be discussed in the
future.
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: joerg, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D57385
Pull in r352943 from upstream lld trunk (by Fangrui Song):
[ELF] Default to --no-allow-shlib-undefined for executables
Summary:
This follows the ld.bfd/gold behavior.
The error check is useful as it captures a common type of ld.so
undefined symbol errors as link-time errors:
// a.cc => a.so (not linked with -z defs)
void f(); // f is undefined
void g() { f(); }
// b.cc => executable with a DT_NEEDED entry on a.so
void g();
int main() { g(); }
// ld.so errors when g() is executed (lazy binding) or when the program is started (-z now)
// symbol lookup error: ... undefined symbol: f
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: llvm-commits, emaste, arichardson
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57569
Together, these add support for --no-allow-shlib-undefined, and make it
the default for executables, so they will fail to link if any symbols
from needed shared libraries are undefined.
Reported by: jbeich
PR: 236062, 236141
MFC after: 1 month
X-MFC-With: r344779
enabling the functions that save and restore MXCSR, since access to this
register requires SSE support.
Note that you may run into other issues with OpenMP on i386, since this
*not* yet supported upstream, and certainly not extensively tested.
PR: 236062, 236582
MFC after: 1 month
X-MFC-With: r344779
on scalbn and a few other math functions, via libcompiler-rt. This
should allow OpenMP programs to link with BFD linkers too.
Reported by: jbeich
PR: 236062, 236581
MFC after: 1 month
X-MFC-With: r344779
functionality. This should make example OpenMP programs work out of the
box.
Reported by: jbeich
PR: 236062, 236581
MFC after: 1 month
X-MFC-With: r344779
* Set MK_OPENMP to yes by default only on amd64, for now.
* Bump __FreeBSD_version to signal this addition.
* Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes.
* Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h.
* Regenerate src.conf(5) with new WITH/WITHOUT fragments.
Relnotes: yes
PR: 236062
MFC after: 1 month
X-MFC-With: r344779
Not connected to the main build yet, as there is still the issue of the
GNU omp.h header conflicting with the LLVM one. (That is, if MK_GCC is
enabled.)
PR: 236062
MFC after: 1 month
X-MFC-With: r344779
This initial integration takes googlemock/googletest release 1.8.1, integrates
the library, tests, and sample unit tests into the build.
googlemock/googletest's inclusion is optionally available via `MK_GOOGLETEST`.
`MK_GOOGLETEST` is dependent on `MK_TESTS` and is enabled by default when
built with a C++11 capable toolchain.
Google tests can be specified via the `GTESTS` variable, which, in comparison
with the other test drivers, is more simplified/streamlined, as Googletest only
supports C++ tests; not raw C or shell tests (C tests can be written in C++
using the standard embedding methods).
No dependent libraries are assumed for the tests. One must specify `gmock`,
`gmock_main`, `gtest`, or `gtest_main`, via `LIBADD` for the program.
More information about googlemock and googletest can be found on the
Googletest [project page](https://github.com/google/googletest), and the
[GoogleMock](https://github.com/google/googletest/blob/v1.8.x/googlemock/docs/Documentation.md)
and
[GoogleTest](https://github.com/google/googletest/tree/v1.8.x/googletest/docs)
docs.
These tests are originally integrated into the build as plain driver tests, but
will be natively integrated into Kyua in a later version.
Known issues/Errata:
* [WhenDynamicCastToTest.AmbiguousCast fails on FreeBSD](https://github.com/google/googletest/issues/2172)
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 2 months
Differential Revision: https://reviews.freebsd.org/D19551
Move LLVM's libunwind to its own contrib/ directory similar to other
runtime libraries like libc++ and libcxxrt.
Reviewed by: dim, emaste
Differential Revision: https://reviews.freebsd.org/D19534
This is not required of a compliant implementation, but it's easy to
check for and helps improve compatibility with other common
implementations. Moreover, it's consistent with our
pthread_mutex_destroy().
PR: 234805
Reviewed by: jhb, kib, ngie
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19496
UEFI related headers were copied from edk2.
A new build option "MK_LOADER_EFI_SECUREBOOT" was added to allow
loading of trusted anchors from UEFI.
Certificate revocation support is also introduced.
The forbidden certificates are loaded from dbx variable.
Verification fails in two cases:
There is a direct match between cert in dbx and the one in the chain.
The CA used to sign the chain is found in dbx.
One can also insert a hash of TBS section of a certificate into dbx.
In this case verifications fails only if a direct match with a
certificate in chain is found.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: sjg
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D19093
clang and various other executables will fail to link with undefined
symbols.
Reported by: O. Hartmann <ohartmann@walstatt.org>
MFC after: 1 month
X-MFC-With: r344779
The armv6 build failed in CI due to missing symbols (from these two
source files) in the bootstrap Clang.
This affected only armv6 because other Clang-using archs are using LLD
as the bootstrap linker, and thus include SRCS_MIW via LLD_BOOTSTRAP.
Reported by: CI, via lwhsu
Sponsored by: The FreeBSD Foundation
Use SOURCE_DATE_EPOCH for BUILD_UTC if MK_REPRODUCIBLE_BUILD is yes.
Default SOURCE_DATE_EPOCH to 2019-01-01
Reviewed by: emaste
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D19464
These are taken directly from the density report from a TS1160
tape drive. (Using mt getdensity)
A TS1160 drive stores 20TB raw (60TB with compression) on a JE tape.
lib/libmt/mtlib.c:
Add 3592A6 encrypted/unencrypted density codes, and bpmm/bpi
values.
usr.bin/mt/mt.1:
Add 3592B5 encrypted/unencrypted density codes, bpmm/bpi
values and number of tracks. Bump the man page date.
MFC after: 3 days
Sponsored by: Spectra Logic
