Date: Tue, 21 Jun 2005 16:57:53 +0300 From: Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua> To: Aziz Kezzou <french.linuxian@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Memory Management questions ? Message-ID: <20050621135753.GA367@pm514-9.comsys.ntu-kpi.kiev.ua> In-Reply-To: <3727392705062012385d75d5c0@mail.gmail.com> References: <37273927050614012154fdb80b@mail.gmail.com> <20050614120706.GA539@pm514-9.comsys.ntu-kpi.kiev.ua> <3727392705061919494ea7e0ad@mail.gmail.com> <200506201037.43599.jhb@FreeBSD.org> <3727392705062012385d75d5c0@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 20, 2005 at 03:38:43PM -0400, Aziz Kezzou wrote: > On 6/20/05, John Baldwin <jhb@freebsd.org> wrote: [skipped] > > > > Are you modifying kernel memory from userland or are you trying to access user > > memory from kernel code? > > > > I want to be able to modify BOTH user and kernel memory in kernel mode. > > Typically, a user process invoques a system call. While executing the > system call I need to have r/w access to the calling process's memory > (which is normally OK) and also r/w access to kernel's memory. Note : Having entered to the kernel a process begins to run with higher privilege and of course it should have access to the kernel address space. Can it access own user space address space directly, I think, depends on MD code, which is responsible for memory manipulation (pmap). According to my understanding, on i386 process's PDE has entries for the kernel memory (1G), which is represented with 4M pages, process uses 4K pages for its memory (3G). When a process runs in userland it uses segments selectors and corresponding segments have limits which do not allow from userspace access kernel memory. When a process runs in the kernel in case of syscall invocation, it uses another segment selectors and another corresponding segments with another limits. All this allows not to reload %cr3. Really you don't have true r/w access to the calling process's memory, since you need to honor COW mappings (such as shadow objects or private mappings of vnode's object), COW pages (used for I/O). To honor all these you need to use copyin(9) and friends, which will call vm_fault() (BTW check that copyin checks VM_MAXUSER_ADDRESS, so user process cannot specify va outside its address space). Please (somebody) correct me, if I understood something wrong. > the user pages that are access from kernel mode are wired to avoid a > page-fault inside the kernel, is that necessary ? > It depends from which parts of the kernel you will access these pages. Also sometimes needed pages in the kernel are wired, sometimes pages are hold, currently I don't completely understand difference; even more, sometimes pages are hold, but comments in functions says that these pages are wired! > Also is there a way of sharing part of the user memory space with the > kernel. In a way that both have access to it and both see each others > work (i.e, no copy-on-write ) ? Please check functions names I gave in my first letter. Also you can create anon vm_object and share it between a process and the kernel or other process (like sysv_mem). Hope this can help.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050621135753.GA367>