Searched +hist:0 +hist:e88a887 (Results 1 - 16 of 16) sorted by relevance
/haiku/src/system/kernel/ | ||
H A D | real_time_clock.cpp | diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. |
H A D | int.cpp | diff 3c259739 Wed Dec 01 15:16:57 MST 2021 Augustin Cavalier <waddlesplash@gmail.com> kernel/int: Allow arch_int_assign_to_cpu to make its own decisions. For now this is used on RISCV64 to indicate that interrupts will always be on CPU 0. However, in the future, some architectures may want or require interrupts to be "steered" in various ways, and this also paves the way for that. Change-Id: Iec79870cf5c4898d102d0e624de19602271ae772 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4721 Reviewed-by: waddlesplash <waddlesplash@gmail.com> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e35d5d2 Mon Dec 12 12:40:37 MST 2011 John Scipione <jscipione@gmail.com> Change instances of wether in comments to whether. No functional change intended. diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e35d5d2e5ef3d288e056d60ef1b16dc399eaa0c Mon Dec 12 12:40:37 MST 2011 John Scipione <jscipione@gmail.com> Change instances of wether in comments to whether. No functional change intended. |
H A D | low_resource_manager.cpp | diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0af5c554 Fri Jun 18 15:01:27 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * Changed the address space note, warning, critical limits to fixed values. The value for note remains the same, the others are significantly higher, now. * compute_state(): Log low resource state changes. * "low_resource" command: Also print the current resource values. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37168 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0af5c55487983ff4abc56df56c259b5e9e459be6 Fri Jun 18 15:01:27 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * Changed the address space note, warning, critical limits to fixed values. The value for note remains the same, the others are significantly higher, now. * compute_state(): Log low resource state changes. * "low_resource" command: Also print the current resource values. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37168 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
H A D | image.cpp | diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. |
H A D | system_info.cpp | diff 79895eed Wed Apr 23 14:26:03 MDT 2014 Murai Takashi <tmurai01@gmail.com> Fix gcc 4.9.0 build Signed-off-by: Jérôme Duval <jerome.duval@gmail.com> diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 79895eed07bbe1918686c6bf26869116369c3596 Wed Apr 23 14:26:03 MDT 2014 Murai Takashi <tmurai01@gmail.com> Fix gcc 4.9.0 build Signed-off-by: Jérôme Duval <jerome.duval@gmail.com> diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. |
H A D | condition_variable.cpp | diff 02077ffc Tue Nov 23 15:20:18 MST 2021 Augustin Cavalier <waddlesplash@gmail.com> kernel/condition_variable: Atomicize ConditionVariableEntry and drop the lock. Before 2019, the entire ConditionVariable system was "giant"-locked: that is, there was a single global lock that all ConditionVariable and ConditionVariableEntry operations had to pass through. This of course was not very performant on multicore systems and when ConditionVariables see significant use, so I reworked it then to have more granular locking. Those patches took a number of attempts to get right, as having two objects in separate threads that can each access the other not turn into a deadlock or use-after-free is not easy to say the least, and the ultimate solution I came up with erased most of the performance gains I initially saw on the first (partially broken) patchsets. So I have wanted to revisit this and see if there was a better way even since then. Recently there have been a few reports of ConditionVariable-related panics (apparently double unlocks), notably #16894, and so that was reason enough to actually revisit this code and see if a better solution could be found. Well, I think I have come up with one: after this commit, Entries no longer have their own lock, and instead accesses to Entry members are almost always atomic; and there is now a case where we spin inside Variable::_NotifyLocked as well as one in Entry::_RemoveFromVariable. This leads to somewhat simpler code (no more lock/unlock dance in Notify), though it is significantly more difficult to understand the nuances of it, so I have left a sizable number of comments explaining the intricacies of the new logic. Note: I initially tried 1000 for "tries", but on a few instances I did see the panic hit, strangely. I don't think the code that is waited on can be reasonably reduced any further, so I have just increased the limit to 10000 (which is still well below what spinlocks use.) Hopefully this suffices. Quick benchmark, x86, compiling HaikuDepot and the mime_db in VMware, 2 cores: before: real 0m23.627s user 0m25.152s sys 0m7.319s after: real 0m23.962s user 0m25.229s sys 0m7.330s Though I occasionally I saw sys times as low as 7.171s, so this seems to be at least not a regression if not a definitive improvement. Change-Id: Id042947976885cd5c1433cc4290bdf41b01ed10e Reviewed-on: https://review.haiku-os.org/c/haiku/+/4727 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> diff 02077ffc Tue Nov 23 15:20:18 MST 2021 Augustin Cavalier <waddlesplash@gmail.com> kernel/condition_variable: Atomicize ConditionVariableEntry and drop the lock. Before 2019, the entire ConditionVariable system was "giant"-locked: that is, there was a single global lock that all ConditionVariable and ConditionVariableEntry operations had to pass through. This of course was not very performant on multicore systems and when ConditionVariables see significant use, so I reworked it then to have more granular locking. Those patches took a number of attempts to get right, as having two objects in separate threads that can each access the other not turn into a deadlock or use-after-free is not easy to say the least, and the ultimate solution I came up with erased most of the performance gains I initially saw on the first (partially broken) patchsets. So I have wanted to revisit this and see if there was a better way even since then. Recently there have been a few reports of ConditionVariable-related panics (apparently double unlocks), notably #16894, and so that was reason enough to actually revisit this code and see if a better solution could be found. Well, I think I have come up with one: after this commit, Entries no longer have their own lock, and instead accesses to Entry members are almost always atomic; and there is now a case where we spin inside Variable::_NotifyLocked as well as one in Entry::_RemoveFromVariable. This leads to somewhat simpler code (no more lock/unlock dance in Notify), though it is significantly more difficult to understand the nuances of it, so I have left a sizable number of comments explaining the intricacies of the new logic. Note: I initially tried 1000 for "tries", but on a few instances I did see the panic hit, strangely. I don't think the code that is waited on can be reasonably reduced any further, so I have just increased the limit to 10000 (which is still well below what spinlocks use.) Hopefully this suffices. Quick benchmark, x86, compiling HaikuDepot and the mime_db in VMware, 2 cores: before: real 0m23.627s user 0m25.152s sys 0m7.319s after: real 0m23.962s user 0m25.229s sys 0m7.330s Though I occasionally I saw sys times as low as 7.171s, so this seems to be at least not a regression if not a definitive improvement. Change-Id: Id042947976885cd5c1433cc4290bdf41b01ed10e Reviewed-on: https://review.haiku-os.org/c/haiku/+/4727 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> diff 02077ffc Tue Nov 23 15:20:18 MST 2021 Augustin Cavalier <waddlesplash@gmail.com> kernel/condition_variable: Atomicize ConditionVariableEntry and drop the lock. Before 2019, the entire ConditionVariable system was "giant"-locked: that is, there was a single global lock that all ConditionVariable and ConditionVariableEntry operations had to pass through. This of course was not very performant on multicore systems and when ConditionVariables see significant use, so I reworked it then to have more granular locking. Those patches took a number of attempts to get right, as having two objects in separate threads that can each access the other not turn into a deadlock or use-after-free is not easy to say the least, and the ultimate solution I came up with erased most of the performance gains I initially saw on the first (partially broken) patchsets. So I have wanted to revisit this and see if there was a better way even since then. Recently there have been a few reports of ConditionVariable-related panics (apparently double unlocks), notably #16894, and so that was reason enough to actually revisit this code and see if a better solution could be found. Well, I think I have come up with one: after this commit, Entries no longer have their own lock, and instead accesses to Entry members are almost always atomic; and there is now a case where we spin inside Variable::_NotifyLocked as well as one in Entry::_RemoveFromVariable. This leads to somewhat simpler code (no more lock/unlock dance in Notify), though it is significantly more difficult to understand the nuances of it, so I have left a sizable number of comments explaining the intricacies of the new logic. Note: I initially tried 1000 for "tries", but on a few instances I did see the panic hit, strangely. I don't think the code that is waited on can be reasonably reduced any further, so I have just increased the limit to 10000 (which is still well below what spinlocks use.) Hopefully this suffices. Quick benchmark, x86, compiling HaikuDepot and the mime_db in VMware, 2 cores: before: real 0m23.627s user 0m25.152s sys 0m7.319s after: real 0m23.962s user 0m25.229s sys 0m7.330s Though I occasionally I saw sys times as low as 7.171s, so this seems to be at least not a regression if not a definitive improvement. Change-Id: Id042947976885cd5c1433cc4290bdf41b01ed10e Reviewed-on: https://review.haiku-os.org/c/haiku/+/4727 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> diff 02077ffc Tue Nov 23 15:20:18 MST 2021 Augustin Cavalier <waddlesplash@gmail.com> kernel/condition_variable: Atomicize ConditionVariableEntry and drop the lock. Before 2019, the entire ConditionVariable system was "giant"-locked: that is, there was a single global lock that all ConditionVariable and ConditionVariableEntry operations had to pass through. This of course was not very performant on multicore systems and when ConditionVariables see significant use, so I reworked it then to have more granular locking. Those patches took a number of attempts to get right, as having two objects in separate threads that can each access the other not turn into a deadlock or use-after-free is not easy to say the least, and the ultimate solution I came up with erased most of the performance gains I initially saw on the first (partially broken) patchsets. So I have wanted to revisit this and see if there was a better way even since then. Recently there have been a few reports of ConditionVariable-related panics (apparently double unlocks), notably #16894, and so that was reason enough to actually revisit this code and see if a better solution could be found. Well, I think I have come up with one: after this commit, Entries no longer have their own lock, and instead accesses to Entry members are almost always atomic; and there is now a case where we spin inside Variable::_NotifyLocked as well as one in Entry::_RemoveFromVariable. This leads to somewhat simpler code (no more lock/unlock dance in Notify), though it is significantly more difficult to understand the nuances of it, so I have left a sizable number of comments explaining the intricacies of the new logic. Note: I initially tried 1000 for "tries", but on a few instances I did see the panic hit, strangely. I don't think the code that is waited on can be reasonably reduced any further, so I have just increased the limit to 10000 (which is still well below what spinlocks use.) Hopefully this suffices. Quick benchmark, x86, compiling HaikuDepot and the mime_db in VMware, 2 cores: before: real 0m23.627s user 0m25.152s sys 0m7.319s after: real 0m23.962s user 0m25.229s sys 0m7.330s Though I occasionally I saw sys times as low as 7.171s, so this seems to be at least not a regression if not a definitive improvement. Change-Id: Id042947976885cd5c1433cc4290bdf41b01ed10e Reviewed-on: https://review.haiku-os.org/c/haiku/+/4727 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> diff 02077ffc Tue Nov 23 15:20:18 MST 2021 Augustin Cavalier <waddlesplash@gmail.com> kernel/condition_variable: Atomicize ConditionVariableEntry and drop the lock. Before 2019, the entire ConditionVariable system was "giant"-locked: that is, there was a single global lock that all ConditionVariable and ConditionVariableEntry operations had to pass through. This of course was not very performant on multicore systems and when ConditionVariables see significant use, so I reworked it then to have more granular locking. Those patches took a number of attempts to get right, as having two objects in separate threads that can each access the other not turn into a deadlock or use-after-free is not easy to say the least, and the ultimate solution I came up with erased most of the performance gains I initially saw on the first (partially broken) patchsets. So I have wanted to revisit this and see if there was a better way even since then. Recently there have been a few reports of ConditionVariable-related panics (apparently double unlocks), notably #16894, and so that was reason enough to actually revisit this code and see if a better solution could be found. Well, I think I have come up with one: after this commit, Entries no longer have their own lock, and instead accesses to Entry members are almost always atomic; and there is now a case where we spin inside Variable::_NotifyLocked as well as one in Entry::_RemoveFromVariable. This leads to somewhat simpler code (no more lock/unlock dance in Notify), though it is significantly more difficult to understand the nuances of it, so I have left a sizable number of comments explaining the intricacies of the new logic. Note: I initially tried 1000 for "tries", but on a few instances I did see the panic hit, strangely. I don't think the code that is waited on can be reasonably reduced any further, so I have just increased the limit to 10000 (which is still well below what spinlocks use.) Hopefully this suffices. Quick benchmark, x86, compiling HaikuDepot and the mime_db in VMware, 2 cores: before: real 0m23.627s user 0m25.152s sys 0m7.319s after: real 0m23.962s user 0m25.229s sys 0m7.330s Though I occasionally I saw sys times as low as 7.171s, so this seems to be at least not a regression if not a definitive improvement. Change-Id: Id042947976885cd5c1433cc4290bdf41b01ed10e Reviewed-on: https://review.haiku-os.org/c/haiku/+/4727 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> diff 02077ffc Tue Nov 23 15:20:18 MST 2021 Augustin Cavalier <waddlesplash@gmail.com> kernel/condition_variable: Atomicize ConditionVariableEntry and drop the lock. Before 2019, the entire ConditionVariable system was "giant"-locked: that is, there was a single global lock that all ConditionVariable and ConditionVariableEntry operations had to pass through. This of course was not very performant on multicore systems and when ConditionVariables see significant use, so I reworked it then to have more granular locking. Those patches took a number of attempts to get right, as having two objects in separate threads that can each access the other not turn into a deadlock or use-after-free is not easy to say the least, and the ultimate solution I came up with erased most of the performance gains I initially saw on the first (partially broken) patchsets. So I have wanted to revisit this and see if there was a better way even since then. Recently there have been a few reports of ConditionVariable-related panics (apparently double unlocks), notably #16894, and so that was reason enough to actually revisit this code and see if a better solution could be found. Well, I think I have come up with one: after this commit, Entries no longer have their own lock, and instead accesses to Entry members are almost always atomic; and there is now a case where we spin inside Variable::_NotifyLocked as well as one in Entry::_RemoveFromVariable. This leads to somewhat simpler code (no more lock/unlock dance in Notify), though it is significantly more difficult to understand the nuances of it, so I have left a sizable number of comments explaining the intricacies of the new logic. Note: I initially tried 1000 for "tries", but on a few instances I did see the panic hit, strangely. I don't think the code that is waited on can be reasonably reduced any further, so I have just increased the limit to 10000 (which is still well below what spinlocks use.) Hopefully this suffices. Quick benchmark, x86, compiling HaikuDepot and the mime_db in VMware, 2 cores: before: real 0m23.627s user 0m25.152s sys 0m7.319s after: real 0m23.962s user 0m25.229s sys 0m7.330s Though I occasionally I saw sys times as low as 7.171s, so this seems to be at least not a regression if not a definitive improvement. Change-Id: Id042947976885cd5c1433cc4290bdf41b01ed10e Reviewed-on: https://review.haiku-os.org/c/haiku/+/4727 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> diff 37eda488 Sat Aug 03 09:22:49 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> kernel/condition_variable: Granularize locking. Before this commit, *all* ConditionVariable operations (yes, all; even Wait, Notify, etc.) went through a single spinlock, that also protected the sConditionVariableHash. This obviously does not scale so well with core count, to say the least! With this commit, we add spinlocks to each Variable and Entry. This makes locking somewhat more complicated (and nuanced; see inline comment), but the trade-off seems completely worth it: (compile HaikuDepot in VMware, 2 cores) before real 1m20.219s user 1m5.619s sys 0m40.724s after real 1m12.667s user 0m57.684s sys 0m37.251s The more cores there are, the more of an optimization this will likely prove to be. But 10%-across-the-board is not bad to say the least. Change-Id: I1e40a997fff58a79e987d7cdcafa8f7358e1115a diff 37eda488 Sat Aug 03 09:22:49 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> kernel/condition_variable: Granularize locking. Before this commit, *all* ConditionVariable operations (yes, all; even Wait, Notify, etc.) went through a single spinlock, that also protected the sConditionVariableHash. This obviously does not scale so well with core count, to say the least! With this commit, we add spinlocks to each Variable and Entry. This makes locking somewhat more complicated (and nuanced; see inline comment), but the trade-off seems completely worth it: (compile HaikuDepot in VMware, 2 cores) before real 1m20.219s user 1m5.619s sys 0m40.724s after real 1m12.667s user 0m57.684s sys 0m37.251s The more cores there are, the more of an optimization this will likely prove to be. But 10%-across-the-board is not bad to say the least. Change-Id: I1e40a997fff58a79e987d7cdcafa8f7358e1115a diff 37eda488 Sat Aug 03 09:22:49 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> kernel/condition_variable: Granularize locking. Before this commit, *all* ConditionVariable operations (yes, all; even Wait, Notify, etc.) went through a single spinlock, that also protected the sConditionVariableHash. This obviously does not scale so well with core count, to say the least! With this commit, we add spinlocks to each Variable and Entry. This makes locking somewhat more complicated (and nuanced; see inline comment), but the trade-off seems completely worth it: (compile HaikuDepot in VMware, 2 cores) before real 1m20.219s user 1m5.619s sys 0m40.724s after real 1m12.667s user 0m57.684s sys 0m37.251s The more cores there are, the more of an optimization this will likely prove to be. But 10%-across-the-board is not bad to say the least. Change-Id: I1e40a997fff58a79e987d7cdcafa8f7358e1115a diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. |
H A D | smp.cpp | diff 41418981 Sat Nov 01 17:01:36 MDT 2014 Michael Lotz <mmlr@mlotz.ch> kernel: Sync panic messages across acquire_spinlock versions. * Always include last caller and lock value on both UP and MP path. * Change lock value printing to hex format, as 0xdeadbeef is more obvious than its decimal counterpart. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 41418981f43f24600cead1a6b4cbc7cfb90bde9a Sat Nov 01 17:01:36 MDT 2014 Michael Lotz <mmlr@mlotz.ch> kernel: Sync panic messages across acquire_spinlock versions. * Always include last caller and lock value on both UP and MP path. * Change lock value printing to hex format, as 0xdeadbeef is more obvious than its decimal counterpart. diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. |
H A D | port.cpp | diff 072b9ed0 Sat Nov 23 13:13:24 MST 2019 Augustin Cavalier <waddlesplash@gmail.com> kernel/port: Properly release the first reference to the Port object. Creating a BReferenceable sets its reference count to 1. create_port() was then acquiring 2 references for the two lists it inserts the port object into, and subsequently delete_port() releases those. But that "reference 0" never was released anywhere, and so despite being removed from hashes, etc. port objects were just leaked, along with whatever messages remained in their queue, never to be freed. This of course can add up pretty quickly in systems that created and deleted ports frequently, for instance, in long-running media playback, opening/closing applications, etc. As far as I can tell, this bug was introduced in the fix to #8007 (7f64b301b1e78fb5a50c44a0cb2bb94a91e31d00), which introduced the ref-counting system to the port heap, so it has been with us since 2013 (!). Fixes #15489, and probably some of the other "media playback memory leak" tickets. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. |
H A D | sem.cpp | diff daf1dd9c Tue Nov 28 23:33:19 MST 2023 Augustin Cavalier <waddlesplash@gmail.com> kernel/sem: Use "count" as thread_unblock status in B_RELEASE_ALL. Previously, "count" did nothing for B_RELEASE_ALL. Now, if it is < 0, it will be the error code returned by acquire_sem() of any waiting threads. As B_RELEASE_ALL is a Haiku extension, this change should not cause any compatibility problems that we cannot fix. This will be useful in implementing some features of TUN/TAP with network FIFOs. Change-Id: I2dbccedefac2024fe740b87543ff3b80f5257e20 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7163 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff 87bdc2b0 Mon Aug 05 10:59:48 MDT 2019 Adrien Destugues <pulkomandy@pulkomandy.tk> fix dumping semaphores by name There was no check for strtoul success or failure (it returns 0 on failure but that is also a valid conversion result). Detect if endptr has been advanced instead (meaning there were some parsed characters in strtoul so the argument at least starts with a number) Change-Id: Ieefbd57a250ddcdb9362094389151c2a432e4c73 Reviewed-on: https://review.haiku-os.org/c/1683 Reviewed-by: Rene Gollent <rene@gollent.com> diff 0a564c2c Sat Jul 20 09:07:48 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> kernel/sem: Drop GRAB macros in favor of SpinLockers. No functional change intended. Change-Id: I24f6f8c55b18f8d031d0b5a87672cc969e141577 Reviewed-on: https://review.haiku-os.org/c/1636 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff b7b5d763 Mon Dec 17 11:14:47 MST 2012 Sergei Reznikov <diver@gelios.net> 64-bit fixes for kernel with KDEBUG_LEVEL = 0 Signed-off-by: Alex Smith <alex@alex-smith.me.uk> diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 209c0f49 Thu Oct 23 02:49:25 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> 0 is a valid semaphore ID. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28292 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff b95f6d47 Tue Apr 22 10:22:42 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Introduced a set of functions (thread_prepare_to_block(), thread_block(), thread_unblock(),...) that allow a thread to wait for something without needing a semaphore or condition variable. It can simply block and another thread can unblock it. Supports timeouts and interrupting. Both semaphores and condition variables use this common mechanism, now. * Semaphores: - Some simplifications due to the thread blocking mechanism. - Changed locking order to sem -> thread. It was the other way around before and when introducing the wait_for_objects() support I had also introduced a situation where the locking was reverse, which could potentially cause a dead lock on SMP systems. - Instead of queueing thread structures, a semaphore queues queued_thread entries now, which are created on the stack. The thread::sem structure could thus be removed. - Added sem_entry::net_count, which is sem_entry::count plus the acquisition count of all waiting threads. This number is needed in remove_thread_from_sem() and instead of computing it there we maintain it. - Fixed remove_thread_from_sem(). It would not unblock threads, if the sem count was <= 0. - Made sem::last_acquirer unconditional. It is actually needed for sem_info::latest_holder. Fixed fill_sem_info() accordingly. - Added some optional tracing output, though only via ktrace_printf(). * Condition variables: - Could be simplified significantly through the use of the thread blocking mechanism. Removed a good deal of unnecessary code. - Moved the ConditionVariableEntry "flags" parameter from Wait() to Add(), and adjusted all places where condition variables are used accordingly. * snooze() uses thread_block_with_timeout() instead of a semaphore. * Simplified thread interrupting in the signal and user debugger code. Instead of separate functions for threads waiting on a semaphore or condititon variable, we only have a single thread_interrupt(), now. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25099 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff b7b5d7636b96de53bb4327684cc1843e56f62320 Mon Dec 17 11:14:47 MST 2012 Sergei Reznikov <diver@gelios.net> 64-bit fixes for kernel with KDEBUG_LEVEL = 0 Signed-off-by: Alex Smith <alex@alex-smith.me.uk> diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. |
H A D | heap.cpp | diff 4e16be4f Mon Apr 25 16:14:44 MDT 2022 Augustin Cavalier <waddlesplash@gmail.com> kernel: Do not invoke memalign with 0 as the alignment argument. The memalign() function has special semantics for its arguments even when -fno-builtin is enabled, it seems (that may be a problem on Clang's part, however.) The alloc_align attribute, which we apply to the memalign_etc function, does not seem to have the same problems; at least its documentation at GCC gives no indication that 0 is not a legal value to pass. Change-Id: Ie5ba090b924ac3577775165d20f11f9696be97f3 diff 4e16be4f Mon Apr 25 16:14:44 MDT 2022 Augustin Cavalier <waddlesplash@gmail.com> kernel: Do not invoke memalign with 0 as the alignment argument. The memalign() function has special semantics for its arguments even when -fno-builtin is enabled, it seems (that may be a problem on Clang's part, however.) The alloc_align attribute, which we apply to the memalign_etc function, does not seem to have the same problems; at least its documentation at GCC gives no indication that 0 is not a legal value to pass. Change-Id: Ie5ba090b924ac3577775165d20f11f9696be97f3 diff 0af21102 Sat Sep 21 12:59:52 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> kernel: Fix compiling the debug heap on x86_64. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff ffb6929a Mon Oct 31 16:00:16 MDT 2011 Michael Lotz <mmlr@mlotz.ch> bonefish+mmlr: Move blocking the 0xcccccccc and 0xdeadbeef address ranges from heap to VM init so that it also works when used in the slab allocator. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43047 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff ffb6929a Mon Oct 31 16:00:16 MDT 2011 Michael Lotz <mmlr@mlotz.ch> bonefish+mmlr: Move blocking the 0xcccccccc and 0xdeadbeef address ranges from heap to VM init so that it also works when used in the slab allocator. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43047 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff b4e5e498 Mon Jan 25 06:46:58 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> MemoryManager: * Added support to do larger raw allocations (up to one large chunk (128 pages)) in the slab areas. For an even larger allocation an area is created (haven't seen that happen yet, though). * Added kernel tracing (SLAB_MEMORY_MANAGER_TRACING). * _FreeArea(): Copy and paste bug: The meta chunks of the to be freed area would be added to the free lists instead of being removed from them. This would corrupt the lists and also lead to all kinds of misuse of meta chunks. object caches: * Implemented CACHE_ALIGN_ON_SIZE. It is no longer set for all small object caches, but the block allocator sets it on all power of two size caches. * object_cache_reserve_internal(): Detect recursion and don't wait in such a case. The function could deadlock itself, since HashedObjectCache::CreateSlab() does allocate memory, thus potentially reentering. * object_cache_low_memory(): - I missed some returns when reworking that one in r35254, so the function might stop early and also leave the cache in maintenance mode, which would cause it to be ignored by object cache resizer and low memory handler from that point on. - Since ReturnSlab() potentially unlocks, the conditions weren't quite correct and too many slabs could be freed. - Simplified things a bit. * object_cache_alloc(): Since object_cache_reserve_internal() does potentially unlock the cache, the situation might have changed and their might not be an empty slab available, but a partial one. The function would crash. * Renamed the object cache tracing variable to SLAB_OBJECT_CACHE_TRACING. * Renamed debugger command "cache_info" to "slab_cache" to avoid confusion with the VMCache commands. * ObjectCache::usage was not maintained anymore since I introduced the MemoryManager. object_cache_get_usage() would thus always return 0 and the block cache would not be considered cached memory. This was only of informational relevance, though. slab allocator misc.: * Disable the object depots of block allocator caches for object sizes > 2 KB. Allocations of those sizes aren't so common that the object depots yield any benefit. * The slab allocator is now fully self-sufficient. It allocates its bootstrap memory from the MemoryManager, and the hash tables for HashedObjectCaches use the block allocator instead of the heap, now. * Added option to use the slab allocator for malloc() and friends (USE_SLAB_ALLOCATOR_FOR_MALLOC). Currently disabled. Works in principle and has virtually no lock contention. Handling for low memory situations is yet missing, though. * Improved the output of some debugger commands. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35283 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 65b5e4d7 Wed Sep 09 20:09:16 MDT 2009 Michael Lotz <mmlr@mlotz.ch> Make use of the address range blocking to guarantee that accessing 0xdeadbeef and 0xcccccccc (and 64 pages thereafter) in any way will always lead to a crash. Before it could happen that these ranges were allocated for an area and then accessing these would not be as evident anymore. Only enabled when the corresponding paranoid setting is enabled (which it currently is). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33033 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 65b5e4d7 Wed Sep 09 20:09:16 MDT 2009 Michael Lotz <mmlr@mlotz.ch> Make use of the address range blocking to guarantee that accessing 0xdeadbeef and 0xcccccccc (and 64 pages thereafter) in any way will always lead to a crash. Before it could happen that these ranges were allocated for an area and then accessing these would not be as evident anymore. Only enabled when the corresponding paranoid setting is enabled (which it currently is). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33033 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
H A D | module.cpp | diff 0f839b9e Mon Apr 20 21:47:46 MDT 2020 Augustin Cavalier <waddlesplash@gmail.com> kernel/module: Panic if search_module is called during gKernelStartup. The VFS has not been initialized at this point, so we can't use it. Should catch #15865. diff 0cbce9aa Wed Jul 18 17:45:17 MDT 2012 Alex Smith <alex@alex-smith.me.uk> A few 64-bit fixes for ELF/module code. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e35d5d2 Mon Dec 12 12:40:37 MST 2011 John Scipione <jscipione@gmail.com> Change instances of wether in comments to whether. No functional change intended. diff 0cbce9aa4732e96acd9d593cb86ca0847a61d051 Wed Jul 18 17:45:17 MDT 2012 Alex Smith <alex@alex-smith.me.uk> A few 64-bit fixes for ELF/module code. diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e35d5d2e5ef3d288e056d60ef1b16dc399eaa0c Mon Dec 12 12:40:37 MST 2011 John Scipione <jscipione@gmail.com> Change instances of wether in comments to whether. No functional change intended. |
H A D | main.cpp | diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 813d4cbe Sun Apr 11 10:07:39 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * Moved created subdirectory src/system/kernel/lock.cpp to new subdirectory locks. * Added syscalls for a new kind of mutex. A mutex consists only of an int32 and doesn't require any kernel resources. So it's initialization cannot fail (it consists only of setting the mutex value to 0). An uncontended lock or unlock operation can basically consist of an atomic_*() in userland. The syscalls (when the mutex is contended) are a bit more expensive than semaphore operations, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36158 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 813d4cbe94b99e33ac2b921ae76df4d1b2b39b40 Sun Apr 11 10:07:39 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * Moved created subdirectory src/system/kernel/lock.cpp to new subdirectory locks. * Added syscalls for a new kind of mutex. A mutex consists only of an int32 and doesn't require any kernel resources. So it's initialization cannot fail (it consists only of setting the mutex value to 0). An uncontended lock or unlock operation can basically consist of an atomic_*() in userland. The syscalls (when the mutex is contended) are a bit more expensive than semaphore operations, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36158 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
H A D | elf.cpp | diff 0cbce9aa Wed Jul 18 17:45:17 MDT 2012 Alex Smith <alex@alex-smith.me.uk> A few 64-bit fixes for ELF/module code. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 4d7859f0 Tue Jul 06 09:41:33 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> elf_resolve_symbol(): If a weak undefined symbol could not be resolved, return 0 as its address. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37412 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff d3b44ccb Wed Jul 29 15:30:35 MDT 2009 Ingo Weinhold <ingo_weinhold@gmx.de> Added explicit physical address parameter to vm_create_anonymous_area() and create_area_etc(). 0 for the default behavior. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31941 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff e6e76e14 Tue Nov 11 14:24:09 MST 2008 Axel Dörfler <axeld@pinc-software.de> * elf_find_symbol() now checks if the hashtable section is greater than 0. * Whatever is the cause of #2733, this should at least not make it crash. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28615 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 3cf7ecd1 Sun Apr 13 16:52:11 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Added <sys/mman.h> header. It declares only mmap() and munmap() yet and defines the macros needed by them. * Renamed syscall sys_vm_map_file() to _kern_map_file() and changed the path to an FD parameter. Changed vm_map_file() accordingly and adjusted the kernel ELF loader and the runtime loader. * Added syscall _kern_unmap_memory(). * Added bool unmapAddressRange parameter to vm_create_anonymous_area() and map_backing_store(). If true and the address specification is B_EXACT_ADDRESS, all areas in the specified address range will be deleted (unless an area is covered only partially). * Introduced B_SHARED_AREA flag, which is set on areas that have been created by {vm,_user}_map_file() with REGION_NO_PRIVATE_MAP. When fork()ing those areas won't be copied CoW, but rather be cloned. This is needed for mmap() MAP_SHARED. * {vm,_user}_map_file() also accept an FD argument < 0, in which case an anonymous area is created. * Implemented mmap() and munmap(). Currently there's the restriction that we can't partially unmap areas. Otherwise the functions should be rather compliant. We also support the non-POSIX extension MAP_ANONYMOUS. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24964 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 0ad660a1 Thu Nov 02 13:38:30 MST 2006 Axel Dörfler <axeld@pinc-software.de> Remap all preloaded executables read-only and executable. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19180 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 0cbce9aa4732e96acd9d593cb86ca0847a61d051 Wed Jul 18 17:45:17 MDT 2012 Alex Smith <alex@alex-smith.me.uk> A few 64-bit fixes for ELF/module code. diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. |
/haiku/src/system/kernel/cache/ | ||
H A D | file_map.cpp | diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 01762bd5 Sat Dec 03 15:30:16 MST 2011 Michael Lotz <mmlr@mlotz.ch> Fix possibly harmful use of stale pointer in edge case. The call to _MakeSpace() may move the extent data from the indirect array (kept in a heap allocation) to the direct one kept inside the class. In that case the lastExtent pointer would become stale and further use of it would've lead to suboptimal extents in the best case to reading/writing at the wrong point in files and possibly corruption of another allocation in the worst (both unlikely though). To mitigate that we now re-initialize the pointer to the correct location if we hit the cache limit. Also made the use of the start variable more understandable. Instaed of decrementing it (possibly wrapping) when an extent wasn't going to be used and later adding the vector index again, just increment whenever we actually move to the next extent. For bad things to happen a few conditions needed to come together though: 1. There needed to be multiple vectors that could be combined with the existing last extent. 2. There first needed to be more extents than the cache limit and that number then had to decrease below the cache limit again. 3. The memory needed to stay intact after being freed up until after the evaluation (or similar enough data had to be written to it). At least the last one was guaranteed to not be true anymore since we re-introduced overwritting freed memory with 0xdeadbeef in the slab, therefore nastily hiding this. I'm not sure that the first condition is ever met either (probably the vectors are combined beforehand so that there never are multiple adjacent ones) at least for the normal use case (the page writer writing back pages). I was at least unable to reproduce an actual file corruption in my testing. Just the out of bounds access to the stale pointer happened rather easily though and is now at least fixed. diff 4accd841 Sun Jan 06 07:04:15 MST 2008 Axel Dörfler <axeld@pinc-software.de> * Fixed a big bug in common_file_io_vec_pages(): vecOffset was not correctly set when the first chunk of the file could be read in directly, causing it to read data to a wrong place in the buffer. * Reading in the first chunk directly would have also only worked if vecIndex and vecOffset was 0 when calling the function. * Applied the fs_shell changes in file_map to the kernel version as well (the constructor already worked correctly, though). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23265 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 01762bd57ff51c04b93cee907275d8e885d38519 Sat Dec 03 15:30:16 MST 2011 Michael Lotz <mmlr@mlotz.ch> Fix possibly harmful use of stale pointer in edge case. The call to _MakeSpace() may move the extent data from the indirect array (kept in a heap allocation) to the direct one kept inside the class. In that case the lastExtent pointer would become stale and further use of it would've lead to suboptimal extents in the best case to reading/writing at the wrong point in files and possibly corruption of another allocation in the worst (both unlikely though). To mitigate that we now re-initialize the pointer to the correct location if we hit the cache limit. Also made the use of the start variable more understandable. Instaed of decrementing it (possibly wrapping) when an extent wasn't going to be used and later adding the vector index again, just increment whenever we actually move to the next extent. For bad things to happen a few conditions needed to come together though: 1. There needed to be multiple vectors that could be combined with the existing last extent. 2. There first needed to be more extents than the cache limit and that number then had to decrease below the cache limit again. 3. The memory needed to stay intact after being freed up until after the evaluation (or similar enough data had to be written to it). At least the last one was guaranteed to not be true anymore since we re-introduced overwritting freed memory with 0xdeadbeef in the slab, therefore nastily hiding this. I'm not sure that the first condition is ever met either (probably the vectors are combined beforehand so that there never are multiple adjacent ones) at least for the normal use case (the page writer writing back pages). I was at least unable to reproduce an actual file corruption in my testing. Just the out of bounds access to the stale pointer happened rather easily though and is now at least fixed. diff 4accd841c7331a6674a4c5db4d9b2686d7eb8bac Sun Jan 06 07:04:15 MST 2008 Axel Dörfler <axeld@pinc-software.de> * Fixed a big bug in common_file_io_vec_pages(): vecOffset was not correctly set when the first chunk of the file could be read in directly, causing it to read data to a wrong place in the buffer. * Reading in the first chunk directly would have also only worked if vecIndex and vecOffset was 0 when calling the function. * Applied the fs_shell changes in file_map to the kernel version as well (the constructor already worked correctly, though). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23265 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
H A D | file_cache.cpp | diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0c615a01 Thu May 01 16:07:36 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Removed old mutex implementation and renamed cutex to mutex. * Trivial adjustments of code using mutexes. Mostly removing the mutex_init() return value check. * Added mutex_lock_threads_locked(), which is called with the threads spinlock being held. The spinlock is released while waiting, of course. This function is useful in cases where the existence of the mutex object is ensured by holding the threads spinlock. * Changed the two instances in the VFS code where an IO context of another team needs to be locked to use mutex_lock_threads_locked(). Before it required a semaphore-based mutex implementation. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25283 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff cfe386c2 Thu Nov 08 06:45:04 MST 2007 Axel Dörfler <axeld@pinc-software.de> * read_into_cache() and write_to_cache() both did not compute the number of needed pages correctly, and would also not read/write enough in case the offset didn't start at 0 resulting in undetected short reads/writes. It's amazing how many bugs can be hidden in a few lines of code. * Fixed a bug that might have been the cause for bug #1601: when the last part of the write did not end on a page boundary, the last page had to be read first, but that was done from the wrong offset. Also, if only parts of that page could be read (because the file size didn't span over the whole page) the remaining parts needed to be cleared. * The cache_funcs were always called with the same value for numBytes and bufferSize so I've eliminated the former. * Large reads now also bypass the cache in case of low memory, large writes now also only bypass the cache in that case, following Ingo's suggestion. * Fixed compilation with debugging turned on. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22858 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 0d871d3c Mon Oct 08 20:04:36 MDT 2007 Axel Dörfler <axeld@pinc-software.de> * satisfy_cache_io() was using the wrong value to compute the number of pages to reserve, which could result in to few being reserved in certain situations. * Use MutexLocker where appropriate. * Reordered includes following the new rules. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22494 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 2b028fca Wed Nov 23 11:36:38 MST 2005 Axel Dörfler <axeld@pinc-software.de> Removed one TODO from the list: in case pages_io() fails, read_chunk_into_cache() 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 diff eab435cd Fri Aug 05 05:52:22 MDT 2005 Axel Dörfler <axeld@pinc-software.de> vfs_get_vnode_cache() now only allocates a new cache if requested: this prevents the system to allocate caches for files that don't use or have a file cache (ie. only those can be mmap()ed!). Therefore, cache_prefetch() no longer crashes when trying to prefetch files without a file cache. read_into_cache() no longer does anything if the requested size is 0. Fixed a bug in cache_prefetch_vnode(): if the cache couldn't be retrieved, it put the vnode, but didn't own it (the caller does). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13904 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0c615a01ae49634aaf59fbe35b3d55b3bb8890df Thu May 01 16:07:36 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Removed old mutex implementation and renamed cutex to mutex. * Trivial adjustments of code using mutexes. Mostly removing the mutex_init() return value check. * Added mutex_lock_threads_locked(), which is called with the threads spinlock being held. The spinlock is released while waiting, of course. This function is useful in cases where the existence of the mutex object is ensured by holding the threads spinlock. * Changed the two instances in the VFS code where an IO context of another team needs to be locked to use mutex_lock_threads_locked(). Before it required a semaphore-based mutex implementation. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25283 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff cfe386c2d5c4d83b121714dde8c05f40ed241dfb Thu Nov 08 06:45:04 MST 2007 Axel Dörfler <axeld@pinc-software.de> * read_into_cache() and write_to_cache() both did not compute the number of needed pages correctly, and would also not read/write enough in case the offset didn't start at 0 resulting in undetected short reads/writes. It's amazing how many bugs can be hidden in a few lines of code. * Fixed a bug that might have been the cause for bug #1601: when the last part of the write did not end on a page boundary, the last page had to be read first, but that was done from the wrong offset. Also, if only parts of that page could be read (because the file size didn't span over the whole page) the remaining parts needed to be cleared. * The cache_funcs were always called with the same value for numBytes and bufferSize so I've eliminated the former. * Large reads now also bypass the cache in case of low memory, large writes now also only bypass the cache in that case, following Ingo's suggestion. * Fixed compilation with debugging turned on. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22858 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
H A D | block_cache.cpp | diff 0e6ece91 Wed Jul 10 17:21:14 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> block_cache: Use an object_cache for the cache_notifications. cache_listeners are (following packagefs changes) the second-most allocated object during the boot process, with 20799 on a *minimum* image. Since they are used so extensively in BFS I/O, making them object_cached for both performance and memory reasons seems to make a lot of sense. Change-Id: I6ef6c3e811c0c4189fea45ee7920131796c9e7c8 Reviewed-on: https://review.haiku-os.org/c/1577 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> Reviewed-by: Stephan Aßmus <superstippi@gmx.de> diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e35d5d2 Mon Dec 12 12:40:37 MST 2011 John Scipione <jscipione@gmail.com> Change instances of wether in comments to whether. No functional change intended. diff 0a5bfde2 Tue Jul 28 15:50:42 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Added stack traced to the Abort tracing output. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31870 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 0d066dea Sat Jul 19 18:37:56 MDT 2008 Axel Dörfler <axeld@pinc-software.de> * Added block level tracing to the block cache. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26521 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 0aee496b Wed Apr 02 04:44:08 MDT 2008 Axel Dörfler <axeld@pinc-software.de> * block_cache_private.h is no longer needed, moved its contents into block_cache.cpp. * Fixed warning. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24739 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel. * Most of this is incorrect printf format strings. Changed all strings causing errors to use the B_PRI* format string definitions, which means the strings should be correct across all platforms. * Some other fixes for errors, casts required, etc. diff 0e35d5d2e5ef3d288e056d60ef1b16dc399eaa0c Mon Dec 12 12:40:37 MST 2011 John Scipione <jscipione@gmail.com> Change instances of wether in comments to whether. No functional change intended. diff 0a5bfde2254f95f840ddacfed5179edd6b8baa41 Tue Jul 28 15:50:42 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Added stack traced to the Abort tracing output. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31870 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
Completed in 730 milliseconds