Lines Matching +full:two +full:- +full:user
19 if it can be proven that a user address space has never executed
25 virtual-->physical address translations obtained from the software
43 This interface flushes an entire user address space from
56 Here we are flushing a specific range of (user) virtual
59 modifications for the address space 'vma->vm_mm' in the range
60 'start' to 'end-1' will be visible to the cpu. That is, after
62 virtual addresses in the range 'start' to 'end-1'.
78 address space is available via vma->vm_mm. Also, one may
79 test (vma->vm_flags & VM_EXEC) to see if this region is
81 split-tlb type setups).
84 page table modification for address space 'vma->vm_mm' for
85 user virtual address 'addr' will be visible to the cpu. That
87 'vma->vm_mm' for virtual address 'addr'.
97 "vma->vm_mm", in the software page tables.
100 For example, it could use this event to pre-load TLB
105 is changing an existing virtual-->physical mapping to a new value,
122 a virtual-->physical translation to exist for a virtual address
129 indexed caches which must be flushed when virtual-->physical
139 This interface flushes an entire user address space from
148 This interface flushes an entire user address space from
161 Here we are flushing a specific range of (user) virtual
163 entries in the cache for 'vma->vm_mm' for virtual addresses in
164 the range 'start' to 'end-1'.
180 address space is available via vma->vm_mm. Also, one may
181 test (vma->vm_flags & VM_EXEC) to see if this region is
191 'vma->vm_mm' for virtual address 'addr' which translates
211 Here in these two interfaces we are flushing a specific range
214 space for virtual addresses in the range 'start' to 'end-1'.
216 The first of these two routines is invoked after map_kernel_range()
225 Is your port susceptible to virtual aliasing in its D-cache?
226 Well, if your D-cache is virtually indexed, is larger in size than
230 If your D-cache has this problem, first define asm/shmparam.h SHMLBA
232 addressed D-cache (or if the size is variable, the largest possible
233 size). This setting will force the SYSv IPC layer to only allow user
242 Next, you have to solve the D-cache aliasing issue for all
244 mapped into some user address space, there is always at least one more
246 PAGE_OFFSET. So immediately, once the first user maps a given
247 physical page into its address space, by implication the D-cache
254 These two routines store data in user anonymous or COW
255 pages. It allows a port to efficiently avoid D-cache alias
260 for these two pages is chosen in such a way that the kernel
262 of the same "color" as the user mapping of the page. Sparc64
266 user will ultimately have this page mapped, and the 'page'
269 If D-cache aliasing is not an issue, these two routines may
276 user space shared/writable mappings of this page potentially
283 space of a user process. So for example, VFS layer code
289 that dirty data in that page at the page->virtual mapping
291 D-cache aliasing, to make sure these kernel stores are
292 visible to user space mappings of that page.
297 stores done by the user.
299 If D-cache aliasing is not an issue, this routine may
302 There is a bit set aside in page->flags (PG_arch_1) as
309 the actual flush if there are currently no user processes
315 page->mapping->i_mmap is an empty tree, just mark the architecture
334 of arbitrary user pages (f.e. for ptrace()) it will use
335 these two routines.
356 When the kernel needs to modify a user page is has obtained
359 page up to date. It is assumed here that the user has no
384 subsystem assumes that the user mapping and kernel offset mapping are