9 Process address space

• The functions in the kernel directly obtain dynamic memory,
  • This is achieved by calling one of the following functions:
  • __get_free_pages or alloc_pages get page frames from partitioned page frame allocator
• kmem_cache_alloc () or kmalloc () uses the slab allocator to allocate blocks for private or general objects, and vmalloc () or vmalloc_32 () to obtain a non-contiguous memory area.
• If the requested memory area is satisfied,
  • Return a page descriptor address or linear address (that is, the starting address of the allocated dynamic memory area)

 

• Kernel priority
• If a kernel function requests dynamic memory, it makes no sense to try to retreat
• The kernel trusts itself.
  • All kernel functions are assumed to be correct, so kernel functions do not have to insert any protection against programming errors.

 

• When allocating memory to user mode processes, the situation is different:
• Process requests for dynamic memory are considered to be unhurried.
• When the executable file of a process is loaded, the process does not necessarily have immediate access to all code pages.
• When a process calls ma1loc () to obtain the requested dynamic memory, it does not mean that the process will access all the acquired memory soon.
• The kernel always tries to postpone the allocation of dynamic memory to user-mode processes.
• User processes cannot be trusted, so the kernel must be ready to catch all addressing errors caused by user-mode processes.

 

• The kernel uses a new resource to implement deferred allocation of process dynamic memory.
• When the user mode process requests dynamic memory, the requested page frame is not obtained.
  • And only get the right to use a new linear address interval,
  • This linear address range becomes part of the process address space.
• This interval is called the "linear area".

 

• How do processes view dynamic memory
• "Linear area" describes the basic composition of the process address space
• The role of the page fault exception handler in postponing the process of allocating page frames.
• How the kernel creates and deletes the entire address space of a process.
• APIs and system calls related to process address space management

Process address space

• The address space of a process consists of all linear addresses allowed for the process.
• The set of linear addresses seen by each process is different, and there is no relationship between the addresses used by one process and the addresses used by another process.
• The kernel can dynamically modify the address space of a process by adding or deleting certain linear address ranges.

 

• The kernel expresses the linear address range through the resources of the so-called linear area. The linear area is described by the starting linear address, length and access rights.
• The start address and the length of the linear area must be a multiple of 4096, so that the data identified by each linear area completely fills the page frame assigned to it.
• Here are some typical situations where the process acquires a new linear region

 

• When the console enters the command, the shell process creates a new process to execute the command
  • A brand new address space (a set of linear areas) is allocated to the new process (see "Creating and Deleting Process Address Spaces" and Chapter 20 later in this chapter).
• The running process decided to load a completely different program.
  • Process identifier unchanged
  • The linear area used before loading this program is released,
  • And there is a new linear area assigned to this process (see "exec" in Chapter 20)
• A running process may perform "memory mapping" on a file (or part of it).
  • The kernel allocates a new linear area for this process to map this file (see Chapter 16, "Memory Map")
• The process may continue to add data to its user-space stack until the linear area mapping this stack is used up, and the kernel will decide to extend the size of this linear area (see "Page Missing Exception Handler" later in this chapter
• A process may create an IPC shared linear area to share data with other processes.
  • The kernel allocates a new linear area to this process to implement this solution (see "IPC Shared Memory" in Chapter 19)
• Transfer malloc () to expand your own dynamic area (heap)
  • The kernel may decide to extend the linear area allocated to this heap (see "Heap Management" later in this chapter).

 

 

• "Page fault exception handler" sees,
  • Determine the linear area of ​​a process (that is, the address space of the process) is the kernel task
  • This allows the page fault exception handler to effectively distinguish between two different types of invalid linear addresses that caused this exception handler
  • Invalid linear address caused by programming error
  • Invalid linear address caused by page fault
    • Even if this linear address belongs to the address space of the process,
    • But the frame of this address is still to be allocated.

 

• From the process point of view, the latter address is not invalid,
  • The kernel needs to use this page fault to achieve the request adjustment:
    • The kernel handles this page fault by providing a page frame and allows the process to continue execution.

Memory descriptor

• All information related to the process address space is in the data structure of the memory descriptor.
• As shown in Table 9-2

struct mm_struct {
	struct vm_area_struct * mmap;		/* list of VMAs */
	struct rb_root mm_rb;
	struct vm_area_struct * mmap_cache;	/* last find_vma result */
	unsigned long (*get_unmapped_area) (struct file *filp,
				unsigned long addr, unsigned long len,
				unsigned long pgoff, unsigned long flags);
	void (*unmap_area) (struct vm_area_struct *area);
	unsigned long mmap_base;		/* base of mmap area */
	unsigned long free_area_cache;		/* first hole */
	pgd_t * pgd;
	atomic_t mm_users;			/* How many users with user space? */
	atomic_t mm_count;			/* How many references to "struct mm_struct" (users count as 1) */
	int map_count;				/* number of VMAs */
	struct rw_semaphore mmap_sem;
	spinlock_t page_table_lock;		/* Protects page tables, mm->rss, mm->anon_rss */

	struct list_head mmlist;		/* List of maybe swapped mm's.  These are globally strung
						 * together off init_mm.mmlist, and are protected
						 * by mmlist_lock
						 */

	unsigned long start_code, end_code, start_data, end_data;
	unsigned long start_brk, brk, start_stack;
	unsigned long arg_start, arg_end, env_start, env_end;
	unsigned long rss, anon_rss, total_vm, locked_vm, shared_vm;
	unsigned long exec_vm, stack_vm, reserved_vm, def_flags, nr_ptes;

	unsigned long saved_auxv[42]; /* for /proc/PID/auxv */

	unsigned dumpable:1;
	cpumask_t cpu_vm_mask;

	/* Architecture-specific MM context */
	mm_context_t context;

	/* Token based thrashing protection. */
	unsigned long swap_token_time;
	char recent_pagein;

	/* coredumping support */
	int core_waiters;
	struct completion *core_startup_done, core_done;

	/* aio bits */
	rwlock_t		ioctx_list_lock;
	struct kioctx		*ioctx_list;

	struct kioctx		default_kioctx;

	unsigned long hiwater_rss;	/* High-water RSS usage */
	unsigned long hiwater_vm;	/* High-water virtual memory usage */
};