[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

Ticket URL: <http://dev.haiku-os.org/ticket/8233#comment:14>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: