[haiku-bugs] Re: [Haiku] #8233: Patch for pthread_attr_getguardsize
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Fri, 06 Apr 2012 13:18:32 -0000
#8233: Patch for pthread_attr_getguardsize
--------------------------+------------------------------------------------
Reporter: unitedroad | Owner: bonefish
Type: | Status: assigned
enhancement | Milestone: R1
Priority: normal | Version: R1/Development
Component: | Keywords: pthread, pthread_attr_getguardsize
System/POSIX | Blocking:
Resolution: | Platform: All
Blocked By: |
Has a Patch: 1 |
--------------------------+------------------------------------------------
Comment (by bonefish):
Replying to [comment:13 hamish]:
> Replying to [comment:12 bonefish]:
> > otherwise after `fork()`ing one could write in the guard range
> Hmm. As it stands now, after a `fork()` the guard pages of the parent
thread's stack become writeable. I'm guessing this is because
`vm_copy_on_write_area()` doesn't take into account the guard size
(http://cgit.haiku-os.org/haiku/tree/src/system/kernel/vm/vm.cpp#n2304) of
the existing cache.
Yes, neither `vm_copy_on_write_area()` nor `vm_copy_area()` take that into
account yet.
> However even when `vm_copy_on_write_area()` does take the guard size
into account, the guard region logic in `VMAnonymousCache::Fault()` is
only considered if overcommiting is on (which it isn't for the copy
cache). Is there any good reason why this is so?
No, I think the only reason for this is that both overcommitting and guard
page support were introduced for the stacks and thus the features got
lumped together (also in `VMAnonymousNoSwapCache` BTW).
I'm afraid the guard size is also not handled correctly when resizing and
cutting areas/caches. Though that's getting farther and farther away from
the pthread guard size feature. Feel free to add TODO's for the time
being.
--
Ticket URL: <http://dev.haiku-os.org/ticket/8233#comment:14>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
