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
* 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
parameter during construction).
* Doing so will now result in a kernel panic whenever your file system tries to
write to a block.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18719 a95241bf-73f2-0310-859d-f6bbb57e9c96
will now grab a reference to the vnode as well if successful. This way, vfs_get_vnode_cache()
now actually works how it should: it will now always grab a reference to the cache and
its underlying vnode. This removes an extra reference to the vnode (and vm_cache) that
got ignored before and prevented volumes to be unmounted (or file caches to be removed).
Thanks to Korli for pointing this out.
* file_cache_create() is now aware of that extra vnode reference and releases it; unmounting
volumes is now working again as it should.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18716 a95241bf-73f2-0310-859d-f6bbb57e9c96
into more than MAX_FILE_IO_VECS pieces. This could have very weird consequences
like overwriting data outside the file (but on that same partition only).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17536 a95241bf-73f2-0310-859d-f6bbb57e9c96
reading the file map of certain files (hope I got that more or less
right)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17525 a95241bf-73f2-0310-859d-f6bbb57e9c96
systems a chance to know if they have locked already.
This fixes a locking problem in BFS where one thread tried to acquire two read
locks (where someone else trying to acquire a write lock would have caused a
dead lock).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17108 a95241bf-73f2-0310-859d-f6bbb57e9c96
since it unlocked the cache while waiting on a busy page. Now, we're filling
the pending request before unlocking the cache.
* Fixed the deadlock I mentioned in the last commit: if a page fault happens
at the same time we're trying to read/write from/to a page, we no longer
fight for the BFS inode lock, but eventually doing the job twice if needed.
Will need to go over the "write modified" functions to make sure they are
behaving as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17091 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Adapt other sources where needed (the boot loader's RootFileSystem still
used the old implementation).
* Implemented RootFileSystem::Rewind().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16889 a95241bf-73f2-0310-859d-f6bbb57e9c96
blocks - this is not enough, though as it would also need to ask other
volumes to free ranges.
* Increased the number of blocks to free in case of low memory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16663 a95241bf-73f2-0310-859d-f6bbb57e9c96
modified to panic when an invalid block is requested (to find fs errors)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16537 a95241bf-73f2-0310-859d-f6bbb57e9c96
* cached_block::parent_data can be NULL in a sub transaction in case the
block wasn't part of the parent transaction (but not in low memory
situations). cache_abort_sub_transaction() and cache_detach_sub_transaction()
didn't account for this, though, ie. the block data could end up
corrupted.
* Renamed cached_block::original in original_data.
* Renamed cached_block::data in current_data.
* Added some comments.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16108 a95241bf-73f2-0310-859d-f6bbb57e9c96
cache_abort_sub_transaction now doesn't crash if parent_cache is NULL (happens in low memory situations)
Axel, please review and fix if needed
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16105 a95241bf-73f2-0310-859d-f6bbb57e9c96
{HAIKU,HOST,TARGET}_KERNEL_PIC_{CC,LINK}FLAGS which define the
compiler/linker flags specifying the kind of position independence
the kernel shall have. For x86 we had and still have -fno-pic, but the
PPC kernel has -fPIE (position independent executable) now, as we
need to relocate it.
* The boot loader relocates the kernel now. Mostly copied the relocation
code from the kernel ELF loader. Almost completely rewrote the PPC
specific relocation code, though. It's more correct and more complete now
(some things are still missing though).
* Added boot platform awareness to the kernel. Moved the generic
Open Firmware code (openfirmware.c/h) from the boot loader to the kernel.
* The kernel PPC serial debug output is sent to the console for the time
being.
* The PPC boot loader counts the CPUs now and allocates the kernel stacks
(made OF device iteration a bit more flexible on the way -- the search
can be restricted to subtree). Furthermore we really enter the kernel...
(Yay! :-) ... and crash in the first dprintf() (in the atomic_set()
called by acquire_spinlock()). kprintf() works, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15756 a95241bf-73f2-0310-859d-f6bbb57e9c96
as cached_block::data - which led to a crash as block_cache::FreeBlock() tried to
free both later.
Since neither cached_block::parent_data nor cached_block::original are supposed
to be != NULL in block_cache::FreeBlock(), they are no longer freed, but the system
panics if one of them is not NULL.
This should fix bug #77.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15749 a95241bf-73f2-0310-859d-f6bbb57e9c96
and thus, it could be used again which led to a crash.
Changed the free ranges list from a singly linked list to a doubly linked
list so that not all free ranges have to be searched for the one to be
freed anymore.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15696 a95241bf-73f2-0310-859d-f6bbb57e9c96
vm_cache_ref starts with a reference count of 1. When acquiring a vm_cache,
you no longer need to worry if that should go through the vm_store, or not;
as it now always does.
* map_backing_store() no longer needs to play with the vm_cache_ref
references.
* that simplified some code.
* vfs_get_vnode_cache() now grabs a reference to the cache, if successful.
* better balanced vnode ownership on vnode_store creation (vnode_store
released the vnode before if its creation failed).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15641 a95241bf-73f2-0310-859d-f6bbb57e9c96
this saves 4 bytes per page. To compensate the loss of bytes, the offset is now
stored in page size units, that's enough to address 2^44 or 16 TB (which is now
the maximal supported file size!).
* Renamed vm_page::ppn to physical_page_number.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15637 a95241bf-73f2-0310-859d-f6bbb57e9c96
them apart (this even saves a pointer from vm_virtual_map to its address space)
* aspace -> address_space
* vm_create_address_space() did not check if creating the semaphore succeeded
* Removed team::kaspace - was not really needed (introduced a new vm_kernel_address_space()
function that doesn't grab a reference to the address space)
* Removed vm_address_space::name - it was just a copy of the team name, anyway,
and there is always only one address space per team
* Removed aspace_id - the address space is now using the team_id
* Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15609 a95241bf-73f2-0310-859d-f6bbb57e9c96
* the link were not initialized in cached_block, as its constructor were never called
(was using malloc/free instead of new/delete).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15564 a95241bf-73f2-0310-859d-f6bbb57e9c96
When memory gets low, the blocks on that list are also freed - but right now,
that only happens when a block is put back (not directly on demand, ie. via
a low memory handler).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15552 a95241bf-73f2-0310-859d-f6bbb57e9c96
will no longer panic, but free its allocated pages.
I ran into this because BFS managed to create a file without data stream but
with a length larger than 0...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15093 a95241bf-73f2-0310-859d-f6bbb57e9c96
about our block_io module not honouring the total length in read_pages().
Removed drops into the debugger when there is a block without an "original"
data buffer - that's completely normal and happens when someone asks for
a cleared block that is not yet in the cache.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14437 a95241bf-73f2-0310-859d-f6bbb57e9c96
Added and implemented new functions cache_blocks_in_[sub_]transaction().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14431 a95241bf-73f2-0310-859d-f6bbb57e9c96
to it - if that page was read from disk unmodified before (or written back in
the mean time), the updated contents coult not be detected, and therefore, were
never written back.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14048 a95241bf-73f2-0310-859d-f6bbb57e9c96
was incorrectly calculated, and could therefore cause all sorts of troubles with
writes over 4 kB.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14011 a95241bf-73f2-0310-859d-f6bbb57e9c96
