close all of its file descriptors), code outside of the core kernel would be executed
in the descriptor's close/free hooks.
Since the semaphore timeout code, and send_data()/receive_data() rely on the
thread being available in the thread hash, they wouldn't work anymore.
This fixes bug #1168. Thanks to Marcus for providing such a nice test case :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20808 a95241bf-73f2-0310-859d-f6bbb57e9c96
quite a bit in the past already); it somehow doesn't work right with how semaphores
are used in BeOS/Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20759 a95241bf-73f2-0310-859d-f6bbb57e9c96
threads with higher priorities a much better scheduling experience, it
also creates a problem as soon as more than one higher priority thread
waits on a resource held by a lower priority thread; the higher priority
threads play ping-pong, and the lower priority thread doesn't get it's
chance.
* Increased the probability of skipping a thread priority.
* I won't do any other changes on the scheduler, that's meianote's job now :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20758 a95241bf-73f2-0310-859d-f6bbb57e9c96
The solution is less than optimal, but should work for now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20722 a95241bf-73f2-0310-859d-f6bbb57e9c96
so we can't easily check if the remaining mappings are valid - therefore I disabled
the check completely.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20654 a95241bf-73f2-0310-859d-f6bbb57e9c96
if the page is currently copied, the source page still has mappings.
* vm_copy_on_write_area() did not set the cache type for the upper cache.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20530 a95241bf-73f2-0310-859d-f6bbb57e9c96
* read_dir() is supposed to return B_OK and and a count of 0 when
reaching the end of the directory. In case the node in question could
not be found, we were looping infinitely.
* free_dir_cookie() was not invoked.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20519 a95241bf-73f2-0310-859d-f6bbb57e9c96
small to hold the information for the requested I/O size.
* get_file_map() returned B_BUFFER_OVERFLOW already in case the array
was exactly as large as needed.
* read_chunk_into_cache() and write_chunk_to_cache() will no longer
override their local "size" variable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20509 a95241bf-73f2-0310-859d-f6bbb57e9c96
sets a fault handler, so that an invalid memory access while executing
the command (address typos always do the trick :-) won't result in
another KDL session on top of the current one, which wouldn't even be
"cont"able.
All pieces of code setting a fault handler do now save and reset the
previous one, so that e.g. a user_memcpy() in a debugger command doesn't
disturb the mechanism.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20500 a95241bf-73f2-0310-859d-f6bbb57e9c96
unload_kernel_add_on(). The former one could lead to deadlocks with
load_kernel_add_on() (e.g. occasionally the boot process would hang).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20485 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added a few comments.
* Simplified the nested while loops by dropping the special handling for the
first iovec and restructuring the innermost loop. This also rules out
the possibility of a zero-length temporary vec. IMHO the readability
has improved quite a bit (YMMV :-). Hopefully without introducing new
bugs; please review!
* Corrected computation of totalSize in case less than size has been
read/written.
* Also set *_numBytes in case all fileVecs have been processed. Only
relevant in case the request extends beyond the end of file.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20483 a95241bf-73f2-0310-859d-f6bbb57e9c96
filling them which could have written over the stack, and their iovec length
was set for the wrong iovec, potentially clobbering any memory.
* The first tempVec was usually empty, anyway, as the wrong iovec was chosen
to start from (usually one too early).
* The tempVec loop is now repeated until the whole fileVec is completed.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20476 a95241bf-73f2-0310-859d-f6bbb57e9c96
in.
* New debugger command "find_page", which searches all page queues to
find out, which one a page is actually in.
* Solved nasty race condition between the page scrubber and
vm_page_allocate_page_run(): The page scrubber didn't mark the pages
it was processing busy, so that vm_page_allocate_page_run() could claim
them in the meantime. They would end up in the clear pages queue,
although being assigned to a cache at the same time. This should
finally solve bug #1056.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20474 a95241bf-73f2-0310-859d-f6bbb57e9c96
being merged in vm_cache_remove_consumer(), fault_find_page() tried again
with the current vm_cache_ref, but didn't realize it might have had inserted
a busy page in this cache already.
This fixes a deadlock, as this page would never get unbusy again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20470 a95241bf-73f2-0310-859d-f6bbb57e9c96
that returns 0. Patch by Hugo Santos.
* Removed superfluous memset() of select_sync structures.
* Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20467 a95241bf-73f2-0310-859d-f6bbb57e9c96
would start with the first block in the unused blocks list, but then
continue with the blocks that share the same hash table slot, thus
freeing potentially used blocks. Could theoretically have caused
BFS to see and write incorrect meta/administrative data on certain
occasions.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20459 a95241bf-73f2-0310-859d-f6bbb57e9c96
yet sure what is causing this, but until I find the time to look into it (or someone else
as part of GSoC), raising the limit helps.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20427 a95241bf-73f2-0310-859d-f6bbb57e9c96
owner of that thread - this fixes the kernel part of bug #1122.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20419 a95241bf-73f2-0310-859d-f6bbb57e9c96
short, if the FD table size wasn't a multiple of 8.
* vfs_resize_fd_table() didn't seem to know at all about the
close-on-exit bitmap. The pointer in the io_context would point to
free()d memory afterwards. This explains the sporadically closed
stdin/out/err descriptors in programs started from Tracker and
Deskbar.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20413 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added a comment to vm_remove_all_page_mappings() that shows that we need to
change the mapping spinlock into a mutex.
* Pointed out some potential problems in the code.
* Added vm_page_at_index(), vm_clear_map_activation(), and vm_test_map_activation()
in preparation of the page scanner rewrite.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20407 a95241bf-73f2-0310-859d-f6bbb57e9c96
mapped fully read-only (for both kernel and userland). Previously a
kernel read access to a yet unmapped r/w accessible userland address
would cause the page from the lower cache to be mapped with write
permission for userland (on x86 also for the kernel) thus e.g.
allowing a fork()ed child process to write to the parent process'
memory.
Fixes bugs #113 and #928.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20402 a95241bf-73f2-0310-859d-f6bbb57e9c96
{set,clear}_debugger_{break,watch}point(), allowing to set/clear break
and watchpoints for the calling team. When a break/watchpoint is hit,
the team enters the debugger. Handy in situations when the program in
question can't really be started in a debugger (or it would be
complicated to do so). The functions work only as long as no debugger is
installed for the team.
We clear the arch specific team and thread debug infos now, when a new
debugger is installed, thus clearing break- and watchpoints.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20396 a95241bf-73f2-0310-859d-f6bbb57e9c96
* NewBlock()/FreeBlock() are now symmetrical in that the former no longer inserts
the block into the hash table.
* delete_transaction() also no longer removes the transaction from the hash table.
* cache_transaction_sync() now uses the new hash_remove_current() function.
* minor other cleanup (like line breaks).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20374 a95241bf-73f2-0310-859d-f6bbb57e9c96
hashtable in case of a read error (NewBlock() also adds the block,
but FreeBlock() only frees it).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20365 a95241bf-73f2-0310-859d-f6bbb57e9c96
suggested by Ingo; before it would just fill the physical pages with NULL pointers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20364 a95241bf-73f2-0310-859d-f6bbb57e9c96
start address wasn't aligned and numBytes was a multiple of the page
size, the last page was ignored. A subsequent get_memory_map() would
return NULL as physical address for that page, if it hadn't been mapped
before (that function looks generally suspicious, IMHO). E.g. reads from a
device into an unaligned buffer that hadn't been touched before would
hit that problem. Fixes bug #1075. Might also fix other reported
problems (like #1056), since this bug could have cause all kinds of weird
behavior and crashes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20362 a95241bf-73f2-0310-859d-f6bbb57e9c96
that points to both, the page and the area the page is in. This will allow a page
scanner to steal unused pages when necessary.
* The locking is currently done with a spinlock which we might want to have another
look at one day.
* dump_page() and dump_area_struct() now dump the page mappings as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20356 a95241bf-73f2-0310-859d-f6bbb57e9c96
add-ons accordingly and removed the syscall.
* Removed send_notification().
* Reimplemented notify_listener(). It used the unimplemented
send_notification(). Now it has a chance to work. Note that
notify_listener() is obsolete. I would already have removed it, if
there weren't lots of FS implementations still using it (Hint!).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20329 a95241bf-73f2-0310-859d-f6bbb57e9c96
vnode::covered_by fields. Together with sMountOpLock it allows write
access, either lock alone suffices for read access. Before
sMountOpLock had to be acquired for read (and write) access, which
meant that while mounting/unmounting a FS path resolution would have
to wait. In case of the UserlandFS this would even cause a deadlock
while mounting if the client tried to resolve the path of the device
to be mounted (e.g. by opening it).
* Added a clarifying comment about read access to the
fs_mount::covers_vnode/root_vnode field and removed locking in
resolve_volume_root_to_mount_point() which was not necessary for
explained reasons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20308 a95241bf-73f2-0310-859d-f6bbb57e9c96
name (saves copying the name, if that has to be done anyway) and added a
wrapper version with the old interface.
* dir_vnode_to_path() was broken for file systems that didn't support
the get_vnode_name() hook. It resolved the mount point too early, so
that it was searching the mount point and not the FS root dir for the
node. It uses the get_vnode_name() function now (before resolving the
mount point).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20305 a95241bf-73f2-0310-859d-f6bbb57e9c96
