On Sat, Jul 12, 2003, Pawel Jakub Dawidek wrote: > On Sat, Jul 12, 2003 at 03:57:18PM -0500, Alan L. Cox wrote: > +> > I've just send PR for this: > +> > > +> > http://www.freebsd.org/cgi/query-pr.cgi?pr=54418 > +> > > +> > I'll be greatful if somebody could review, commit and MFC it > +> > as soon as possible. I need to hold CerbNG next release until > +> > it will be fixed. > +> > > +> > +> As I've said in private e-mail, this is not a bug. You're really asking > +> for a change in "specification". Reductions in max_protection have had > +> permanent effect since the late 1980's. > > You've also asked my in private mail why I need this, I'll answer here. > > I need this to protect syscall arguments that I'm checking in CerbNG. > If I need to check an argument I've to be sure that kernel will check > exactly that same argument (here is ugly race). > So what I do is memory allocaton in process' vmspace, copy argument > there, mark newly allocated pages as read-only and call original > syscall with new pointer(s). Those pages are freed after that and > everything will be correct, but somebody has reported me about > 'bus error'. I've track this problem for two days. It occurs for > majordomo, when perl is trying to execute something, nevermind. > Pages are marked as read-only for child process, but parent > process is killed with SIGBUS signal. I don't mees with this parent > process at all, but it looks they're sharing some memory or some > pages/map is mirrored (copy-on-write mechanism?) with VM_PROT_READ > protection.
So let me see if I've got the sequence of events straight: 1) The process forks 2) The child makes a system call that results in the creation of a new read-only map entry. 3) The parent calls mmap() (for example) to create a read-write map entry with the same virtual address. 4) Somehow the parent's permissions end up being read-only, not read-write, and the parent dies. Is this correct? If so, this doesn't sound like a problem with vm_map_protect(), but rather with your handling of map entry sharing. My first inclination, as a non-expert, would be that you're not taking MAP_ENTRY_NEEDS_COPY into account. This is an optimization that allows two processes to share map entries until a COW fault is taken in one of them. This speeds up fork(2) greatly because VM objects are not allocated unnecessarily. _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
