for KEYGEN_RANDOMKEY.
Print a warning if such a refusal is made---this will help the user understand
why there is an error.
Patch provided by: Taylor R Campbell <campbell+netbsd@mumble.net>.
skip entries, print (null), run off the end of the array, or occasionally
receive SIGSEGV, and now will, hopefully at least, do none of that.
Based in part on the patch in PR 44183 from Sergio Acereda; I also
did some tidyup and fixed it to print top-to-bottom first like ls(1).
lock any uvm objects, check if lockholders are currently on CPU
and yield to try very soon again instead of assuming deadlock.
This makes limited-memory kernels perform the same as memory-unlimited
kernels (provided there is a reasonable amount of memory available).
For example, for large file copy off of ffs where the image is
backed on host memory (i.e. no disk i/o, i.e. ideal conditions)
the figures are, per rump kernel memory limit:
3000kB: same
1000kB: 10% slower
500kB: 50% slower
(per pagedaemon code might still be able to use some tweak, though)
- sync usage comment with current reality
- sort includes
- wrap lines
- use EXIT_FAILURE consistently
- make error messages consistent: Cannot->Can't
- Remove "Old FFSv1 macros" in favor of system macros in ufs/ffs/fs.h .
Leave dblksize() because it uses the on-disk dinode structure.
More cleanup is needed.
No functional changes intended.
is done in rumpuser for simplicity, since on the kernel side things
we assume we have only one pointer of space). As a side-effect,
we can no longer know if the current thread is holding on to a
mutex locked without curlwp context (basically all mutexes inited
outside of mutex_init()). The only thing that called rumpuser_mutex_held()
for a non-kmutex was the giant lock. So, instead implement recursive
locking for the giant lock in the rump kernel and get rid of the
now-unused recursive pthread mutex in the hypercall interface.
satisfied. This allows the caller to unlock the object and the
pagedaemon to avoid deadlock even if ~all memory is consumed by
one vm object. This in turn makes is possible to copy a large file
into a rump kernel with a 10MB memory limit (where large >> 10MB).
A little more tuning will be required to avoid the pagedaemon
hitting the sleep-and-retry path, though.
+ fix some outdated unrelated comments
instead of a _disable and _enable routine, we have a single _enable which
takes a flag, and has a slightly different function signature.
Macppc kernels should build again.
alignment faults. the code is:
0x00007f7ffd40ccd7 <_pixman_implementation_create_sse2+0>: push %rbp
0x00007f7ffd40ccd8 <_pixman_implementation_create_sse2+1>: mov %rsp,%rbp
0x00007f7ffd40ccdb <_pixman_implementation_create_sse2+4>: sub $0x10,%rsp
...
0x00007f7ffd40cdab <_pixman_implementation_create_sse2+212>: mov $0xffffffffffffffff,%rdx
0x00007f7ffd40cdb2 <_pixman_implementation_create_sse2+219>: mov %rdx,0xfffffffffffffff0(%rbp)
0x00007f7ffd40cdb6 <_pixman_implementation_create_sse2+223>: mov %rdx,0xfffffffffffffff8(%rbp)
0x00007f7ffd40cdba <_pixman_implementation_create_sse2+227>: movdqa 0xfffffffffffffff0(%rbp),%xmm0
upon entry we have stack aligned to 16 bytes. the first instruction
subtracts 8, we copy this not-16-byte aligned value into %rbp, and
then decrement the stack by 16 bytes.
then we store a big -1 into 16 bytes on the stack, and then load it
into %xmm0.. except we load it from an unaligned pointer and GP.
more than create an empty file system, grow it, and makes sure fsck
finds the result clean. The 'shrink' test does likewise for shrinking,
but is an expected failure at the moment due to PR bin/44177.
plunky