We the meta data area couldn't be allocated in any of the supported
(reattachable) places, just use a static allocation. The tracing feature
wouldn't be available at all in such a case.
In debug_cleanup(), if the debug syslog buffer is disabled (the default when
KDEBUG_LEVEL is 0), then a new buffer is allocated with kernel_args_malloc().
This is done after kernel_args addresses have been converted to 64-bit, so
the address the kernel gets will be 32-bit, resulting in the page fault seen
in #9842. Fixed by moving the call to debug_cleanup() to before
convert_kernel_args().
... in case of team creation error. Once assigned to Team::io_context
the Team object takes responsibility of the I/O context object and
releases the reference on destruction. load_image_internal() and
fork_team() were thus releasing one reference too many.
Fixes#9851.
* In case the locale backend could not be loaded, these functions (and
their reentrant counterparts) just returned an error. So we reactivate
parts of the BSD-/Olson-implementation in localtime_fading_out.c in
order to use them as fallback.
* Cleanup localtime_fading_out.c (remove a lot of unused cruft).
* all those functions need to return the given wc unchanged in case of
error, not 0
* towctrans() didn't actually look at the requested transition, but
always acted as if _ISlower was given
* when an executable with a different ABI is being loaded and some
needed image isn't found, don't retry using the standard ABI folders
of the system - those are now considered incompatible
* ReaderImplBase:
- Add virtual CreateCachedHeapReader() which can create a cached
reader based on the given heap reader.
- Rename HeapReader() to RawHeapReader() and add HeapReader() for the
cached heap reader.
- Add DetachHeapReader() to allow a clients to remove the heap
reader(s) after deleting the ReaderImplBase object.
* packagefs:
- Add CachedDataReader class, which wraps a given
BAbstractBufferedDataReader and provides caching for it using a
VMCache. The implementation is based on the IOCache implementation.
- Use CachedDataReader to wrap the heap reader. For file data that
means they are cached twice -- in the heap reader cache and in the
file cache -- but due to the heap reader using a VMCache as well,
the pages will be recycled automatically anyway. For attribute data
the cache should be very helpful, since they weren't cached at all
before.
* Add flags parameter to Init() of BPackageReader and friends.
* Introduce flag B_HPKG_READER_DONT_PRINT_VERSION_MISMATCH_MESSAGE and
don't print a version mismatch error when given.
* package extract/list: Use the new flag.
* Add new package haiku_loader.hpkg and move haiku_loader there. The
package is built without compression, so that the stage 1 boot loader
has a chance of loading it.
* Adjust the stage 1 boot loader to load the haiku_loader package and
relocate the boot loader code accordingly.
Instead of handling compression for individual file/attribute data we
do now compress the whole heap where they are stored. This
significantly improves compression ratios. We still divide the
uncompressed data into 64 KiB chunks and use a chunk offset array for
the compressed chunks to allow for quick random access without too much
overhead. The tradeoff is a limited possible compression ratio -- i.e.
we won't be as good as tar.gz (though surprisingly with my test
archives we did better than zip).
The other package file sections (package attributes and TOC) are no
longer compressed individually. Their uncompressed data are simply
pushed onto the heap where the usual compression strategy applies. To
simplify things the repository format has been changed in the same
manner although it doesn't otherwise use the heap, since it only stores
meta data.
Due to the data compression having been exposed in public and private
API, this change touches a lot of package kit using code, including
packagefs and the boot loader packagefs support. The latter two haven't
been tested yet. Moreover packagefs needs a new kind of cache so we
avoid re-reading the same heap chunk for two different data items it
contains.
* When looking for a place for new area the size of the area to be
inserted instead of the next area size was used to check whether
we are already past the upper bound.
* There was an attempt to insert area even if we were past the
upper bound.
* If at least one image is either B_HAIKU_ABI_GCC_2_ANCIENT or
B_HAIKU_ABI_GCC_2_BEOS almost all areas are marked as executable.
* B_EXECUTE_AREA and B_STACK_AREA are made public. The former is enforced since
the introduction of DEP and apps need it to correctly set area protection.
The latter is currently needed only to recognize stack areas and fix their
protection in compatibility mode, but may also be useful if an app wants
to use sigaltstack from POSIX API.
* Add optional packages Zlib and Zlib-devel.
* Simplify the build feature section for zlib and also extract the
source package.
* Replace all remaining references to the zlib instance in the tree and
remove it.
Casting the difference of the two off_t values to size_t may truncate
the result. Doing so before the comparison will therefore break it.
Instead cast the size to off_t to get around the signed versus unsigned
integer expression comparison and then cast the result of the comparison
to size_t again. Should fix#9714.
This reverts commit f7176b0ee5. Citing Ingo:
"off_t is the correct type to use for addressing pages in a cache/file,
which page_num_t should only be used for physical pages." I'll see how to
fix the GCC 4.7 warnings differently :)
* error message: error: cannot bind packed field
'args->kernel_args::platform_args.platform_kernel_args::apm' to 'apm_info&'
* the reason would be that the reference doesn't have alignment information anymore.
* changed the reference to const for read access, and use the long form for setting a field.
- Instead of implicitly registering and unregistering a service
instance on construction/destruction, DefaultNotificationService
now exports explicit Register()/Unregister() calls, which subclasses
are expected to call when they're ready.
- Adjust all implementing subclasses. Resolves an issue with deadlocks
when booting a DEBUG=1 build.
* Add "bool kernel" parameter to vfs_entry_ref_to_path(), so it can be
specified for which I/O context the entry ref shall be translated.
* _user_entry_ref_to_path(): Use the calling team's I/O context instead
of the kernel's. Fixes the bug that in a chroot the syscall would
return a path for outside the chroot.
* make runtime_loader a dynammically linked object
* add kernel support for loading user images that need to be relocated
* load runtime_loader at random address
Currently there are two generators. The fast one is the same one the scheduler
is using. The standard one is the same algorithm libroot's rand() uses. Should
there be a need for more cryptographically PRNG MD4 or MD5 might be a good
candidates.
This address specification is actually not needed since PIC images can be
located anywhere. Only their size is restriced but that is the compiler and
linker concern. Thanks to Alex Smith for pointing that out.
B_ALREADY_WIRED, which was erroneously passed for the area protection
parameter to map_backing_store(), has the value 7 which implies user
readable and writable. Hence the address ranges around 0xdeadbeef and
0xcccccccc could actually be read and written from anywhere.
On some 64 bit architectures program and library images have to be mapped in
the lower 2 GB of the address space (due to instruction pointer relative
addressing). Address specification B_RANDOMIZED_IMAGE_ADDRESS ensures that
created area satisfies that requirement.
Placing commpage and team user data somewhere at the top of the user accessible
virtual address space prevents these areas from conflicting with elf images
that require to be mapped at exact address (in most cases: runtime_loader).
This patch introduces randomization of commpage position. From now on commpage
table contains offsets from begining to of the commpage to the particular
commpage entry. Similary addresses of symbols in ELF memory image "commpage"
are just offsets from the begining of the commpage.
This patch also updates KDL so that commpage entries are recognized and shown
correctly in stack trace. An update of Debugger is yet to be done.
Set execute disable bit for any page that belongs to area with neither
B_EXECUTE_AREA nor B_KERNEL_EXECUTE_AREA set.
In order to take advanage of NX bit in 32 bit protected mode PAE must be
enabled. Thus, from now on it is also enabled when the CPU supports NX bit.
vm_page_fault() takes additional argument which indicates whether page fault
was caused by an illegal instruction fetch.
x86_userspace_thread_exit() is a stub originally placed at the bottom of
each thread user stack that ensures any thread invokes exit_thread() upon
returning from its main higher level function.
Putting anything that is expected to be executed on a stack causes problems
when implementing data execution prevention. Code of x86_userspace_thread_exit()
is now moved to commpage which seems to be much more appropriate place for it.
When mmap() is invoked without specifying address hint B_RANDOMIZED_ANY_ADDRESS
is used.
Otherwise, unless MAP_FIXED flag is set (which requires mmap() to return an area
positioned exactly at given address), B_RANDOMIZED_BASE_ADDRESS is used.
When forking a process team user data area is not cloned but a new one is
created instead. However, the new one has to be at exactly the same address
parent's team user data area is. When process is exec then team user data
area may be recreated at random position.
This patch also make sure that instances of struct user_thread in team user
data are each in separate cache line in order to prevent false sharing since
these data are very likely to be accessed simultaneously from threads executing
on different CPUs. This change however reduces the number of threads process
can create. It is fixed by reserving 512kB of address space in case team user
data area needs to grow.
Randomized equivalent of B_ANY_ADDRESS. When a free space is found (as in
B_ANY_ADDRESS) the base adress is then randomized using _RandomizeAddress
pretty much like it is done in B_RANDOMIZED_BASE_ADDRESS.
B_RAND_BASE_ADDRESS is basically B_BASE_ADDRESS with non-deterministic created
area's base address.
Initial start address is randomized and then the algorithm looks for a large
enough free space in the interval [randomized start, end]. If it fails then
the search is repeated in the interval [original start, randomized start]. In
case it also fails the algorithm falls back to B_ANY_ADDRESS
(B_RANDOMIZED_ANY_ADDRESS when it is implemented) just like B_BASE_ADDRESS does.
Randomization range is limited by kMaxRandomize and kMaxInitialRandomize.
Inside the page randomization of initial user stack pointer is not only a part
of ASLR implementation but also a performance improvement that helps
eliminating aligned 64 kB data access.
Minimal user stack size is increased to 8 kB in order to ensure that regardless
of initial stack pointer value there is still enough space on stack.
The physical memory map area was not included in the kernel virtual
address space range (it was below KERNEL_BASE). This caused problems
if an I/O operation took place on physical memory mapped there (the
bad address error seen in #9547 was occurring in lock_memory_etc()).
Changed KERNEL_BASE and KERNEL_SIZE to cover the area and add a null
area that covers all of it. Also changed X86VMTranslationMap64Bit to
handle large pages in Query(), as the physical map area uses large
pages.
As pointed out by Hamish the alignment used && in second case
instead of &, which meant it was never used.
Another error when a32 was 0xFF000000 and b32 was 0xFF00FFFF
would return a non zero value. A simple fix for the issues
with going over to the byte by byte comparison failed, so
rather than leave broken code I remove this for the time being.
Not the best code I've written obviously.
The standard states that F_GETLK should check whether given lock would be
blocked by another one and return description of the conflicting one (or
set l_type to F_UNLCK if there is no collision).
Current implementation of F_GETLK performs completely different actions, it
"Retrieves the first lock that has been set by the current team". Moreover,
if there are no locks (advisory_locking == NULL) an error is returned
instead of l_type set to F_UNLCK.
Unlike Classic PPC, Book-E CPUs do not have hardware page-table walk,
rather only a limited set of software-managed TLBs. Also, translation
is never disabled even when page-faulting.
The Linux Book-E port pins part of the RAM in one or more TLBs, and
allocates kernel memory from it for the kernel itself and exception
vectors, as well as page tables.
cf. http://kernel.org/doc/ols/2003/ols2003-pages-340-350.pdf
We take a similar approach, but instead of using a tree-like page
directory we reserve a large part of this mapped range for an
hashed page table similar to the Classic one, to later allow
factoring code out. The kernel and boot modules will also be
allocated there, and the rest should be used as SLAB areas.
Note doing so will not allow implementing proper permissions for
the areas allocated there since they are all handled by a single TLB.
Also note Book-E does not standardize the MMU implementation itself.
For now only AMCC440 type MMU is supported. This will need to be
cleaned up later on.
The size variable at this point is actually a page count.
The test should never be true anyway though. Maybe we should use a
pages variable for clarity?
* Read the PVR register to determine the CPU type.
* Also check the FDT /cpu/cpu@0 node for model string
(we use the FDT calls directly since the OF wrapper isn't initialized yet).
* Use this to enable the FPU APU hack for 440 (instead of #ifdef).
* Moved some functionality into their own files so that they can easily
be reused by other code.
* Added crc32() function from FreeBSD. Implemented CRC handling and
validation.
* Implemented missing write functionality.
This replaces the use of a few BSD-specific functions, as well
as the direct references to _open/_close et-al.
BFS doesn't support the FTS_NOSTAT directory link count optimization,
and no statfs() function is available, so we simply turn that off.
* Added the aforementioned functions.
* create_area_etc() now takes a guard size parameter.
* The thread_info::stack_base/end range now refers to the usable range
only.
The value computed isn't actually used anywhere. It just ensured that
a panic would be triggered if we "skipped" to virtual addresses further
along. This shouldn't be problematic however.
This makes it less likely that uninitialized entries cause troubles.
Also panic if we encounter an unknown entry type instead of defaulting
to 4K pages.
And actually use the virtual address for it later on. This wasn't
problematic as the virtual and physical addresses are identity mapped,
but it seems more correct to do it in this order.
As there are only 8 bits for the index in the coarse page table entries
the maximum index is 256. This makes us correctly move to the next page
directory once we've run through all entries. Fixes missing unmap of
pages that crossed that boundary and consequent panic "page still has
mappings" when the page was removed from a cache.
Since we have the same setup with a loaded and mapped boot archive, we
can reuse the MemoryDevice implemented in uboot. This gets the loader
to the stage where it loads and attempts to boot the kernel.
An archive (ramfs) to be loaded can be specified in the raspberry pi
config.txt with a certain base address. We can use this to put our
floppy boot archive into memory on startup.
During the start procedure we now map that archive so we can later
load the kernel from it.
Add more fields to arch framebuffer to hold the physical address and
size of the framebuffer. Then fill these in when mapping the
framebuffer to virtual memory.
These can be used for on-screen debug output with relatively little
effort, as they just need a plain framebuffer definition to work.
Some stubs are added to not clutter up the kernel sources with too
many ifdefs.
Making the fields protected allows them to be set by arch framebuffer
implementations. The getters can be used to retrieve the configuration
from outside the implementation.
The stack pointer is set up so that it uses the space below our .text
section at 0x8000. The stack pointer actually points at one entry less
than the specified address, so it starts at 0x8000 - sizeof(uint32) and
grows downwards from there.
* Raspberry Pi is broken now after
the other recent arm work... needs
more investigation.
* Comment out stage2 header as it
links to headers with c++ code.
Need to verify entry.s can call
c++ code (I think it's mangled to
the assembly or something)
* Fix naming of code entry to match
other arm code.
This will get libroot.so to build, which should give us much more compilation
coverage for ARM now too. Will have to go through all the libroot code with
a tooth comb anyway once userland comes up...
(Will consider replacing the glibc mess with bsd for all non gcc2 platforms)
Will sort this out properly when userland is coming up. Need to get
a basic libroot version working first, so I can build a proper HaikuImage
to boot from ;)
These are pretty generic 32bit target files, so just copy them over.
Once we get userland properly starting, we can review these to see
if they need any changes.
This adds a few generic implementations of basic arithmetic functions. These
would normally be implemented in assembly, but add them for easy bringup of
new architectures.
This enables new platforms to start with a minimal set of changes to libroot.
There is no ARM port for the glibc version we're using mostly, so I'm picking
up files from more recent glibc and will probably need to hack around in them,
as glibc seem to have cleaned up their arch support a lot these days.
When iterator->current is NULL, hash_next() assumes we've reached the
end of a bucket (linked list) and moves to the next one. Wehn the first
element of a linked list was removed in hash_remove_current()
iterator->current was set to NULL, causing the next call to hash_next()
to skip over the rest of the list of that bucket.
To fix this we now decrement iterator->bucket by one, so the next call
to hash_next() correctly arrives at the new first element of the same
bucket. Doing it this way avoids having to search backwards through the
table to find the actual previous item.
This caused modules to be skipped in module_init_post_boot_device()
when normalizing module image paths so some of the module images ended
up non-normalized. This could then cause images to be loaded a second
time for modules that were part of an actually already loaded image.
This setup is present for the PCI module with the pci/x86 submodule
and would lead to a second copy of the PCI module image to be loaded
but without being initialized, eventually leading to #8684.
The affected module images were pretty much random, as it depended on
the order in which they were loaded from the file system, in this case
the boot floppy archive of the El-Torito boot part of ISO and anyboot
images. The r1alpha4 release images unfortunately had the module files
ordered in the archive just so that the PCI module image would be
skipped, allowing #8684 to happen on many systems with MSI support.
Since the block cache uses hash_remove_current() as well in some cases,
it is possible that transactions in its list could've been skipped.
Cursory testing didn't reveal this to be a usual case, and it is
possible that in the pattern it is used there, the bug wouldn't be
triggered at all. It's still possible that it caused rare misbehaviour
though.
Since we're using multi-part uImage format, we can add the FDT as
a seperate "blob" in the uImage, if the used U-Boot version is not
"FDT enabled".
This is used for example for our Verdex target. Currently I've got
a local hack in the platform/u-boot/Jamfile, looking into pulling
in the FDT files and a proper Jam setup to do that properly...
This detects everything up to ARMv6 right now. Need to check more
recent ARM ARMs for ARMv7 detection.
The detected details get passed on to the kernel, which can use
the pre-detected info for selecting right pagetable format and such.
Copyright removal of Axel done after agreement with Axel @ BeGeistert
that for files that were copy/pasted from x86 arch and then fully
replaced the implementation, removal of original copyright holder is
allowed, since their actual code is gone ;)
Remove the dummies from the C code and implement them in assembly,
due to the label referencing issues with the fault handler.
This code is ripe for optimisation, my ARM assembly is pretty
basic ;)
Does work though, and gets us one step closer to a full arch.
As noted during BeGeistert and today again by kallisti5, there's a
Pentium reference in the ARM bootloader code.
Correct the message to something more appropriate....
Thanks to Rene for the suggestion ;)
This is to make sure all ARM platforms will benefit from planned work on this
MMU/CPU code. The less code duplicated, the better.
Compile-tested for all supported ARM platforms
This also implements the fault handler correctly now, and cleans up the
exception handling. Seems a lot more stable now, no unexpected panics or
faults happening anymore.
This will generate asm_offsets.h which makes our assembly code
easier to maintain by preventing hardcoded offsets for fields within structures.
(copied from X86 and removed the X86 specifics)
* don't enforce a zero boundary or a zero alignment
* when going to the next range, takes alignment into account.
It could previously just be enforced again through alignment and loop infinite.
* it should help with some FreeBSD based drivers
This contains both the common ARM(v5) vector handling as well as
the PXA(verdex) specific interrupt controller code, to be seperated
when ARM support for FDT is implemented.
Functional enough to handle interrupts, needs work on KDL support.
