summaryrefslogtreecommitdiffstats
path: root/kernel/mm/mmu_context.c
blob: b1b6f238e42d2c418c8b0b9924922fc8a9b0c64b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
/* Copyright (C) 2009 Red Hat, Inc.
 *
 * See ../COPYING for licensing terms.
 */

#include <linux/mm.h>
#include <linux/mmu_context.h>
#include <linux/export.h>
#include <linux/sched.h>

#include <asm/mmu_context.h>

/*
 * use_mm
 *	Makes the calling kernel thread take on the specified
 *	mm context.
 *	(Note: this routine is intended to be called only
 *	from a kernel thread context)
 */
void use_mm(struct mm_struct *mm)
{
	struct mm_struct *active_mm;
	struct task_struct *tsk = current;

	task_lock(tsk);
	preempt_disable_rt();
	active_mm = tsk->active_mm;
	if (active_mm != mm) {
		atomic_inc(&mm->mm_count);
		tsk->active_mm = mm;
	}
	tsk->mm = mm;
	switch_mm(active_mm, mm, tsk);
	preempt_enable_rt();
	task_unlock(tsk);
#ifdef finish_arch_post_lock_switch
	finish_arch_post_lock_switch();
#endif

	if (active_mm != mm)
		mmdrop(active_mm);
}
EXPORT_SYMBOL_GPL(use_mm);

/*
 * unuse_mm
 *	Reverses the effect of use_mm, i.e. releases the
 *	specified mm context which was earlier taken on
 *	by the calling kernel thread
 *	(Note: this routine is intended to be called only
 *	from a kernel thread context)
 */
void unuse_mm(struct mm_struct *mm)
{
	struct task_struct *tsk = current;

	task_lock(tsk);
	sync_mm_rss(mm);
	tsk->mm = NULL;
	/* active_mm is still 'mm' */
	enter_lazy_tlb(mm, tsk);
	task_unlock(tsk);
}
EXPORT_SYMBOL_GPL(unuse_mm);
he host, all of them are killed by this | | | attacker. | | | In this case. This parameter should always set to "swift- | | | proxy". | | | 3) host: which is the name of a control node being attacked. | | | | | | e.g. | | | -fault_type: "kill-process" | | | -process_name: "haproxy" | | | -host: node1 | | | | +--------------+--------------------------------------------------------------+ |monitors | In this test case, two kinds of monitor are needed: | | | 1. the "openstack-cmd" monitor constantly request a specific | | | Openstack command, which needs two parameters: | | | 1) monitor_type: which is used for finding the monitor class | | | and related scritps. It should be always set to | | | "openstack-cmd" for this monitor. | | | 2) command_name: which is the command name used for request. | | | | | | 2. the "process" monitor check whether a process is running | | | on a specific node, which needs three parameters: | | | 1) monitor_type: which used for finding the monitor class | | | and related scripts. It should be always set to "process" | | | for this monitor. | | | 2) process_name: which is the process name for monitor | | | 3) host: which is the name of the node runing the process | | | In this case, the command_name of monitor1 should be | | | services that is supported by load balancer and the process- | | | name of monitor2 should be "haproxy", for example: | | | | | | e.g. | | | monitor1: | | | -monitor_type: "openstack-cmd" | | | -command_name: "nova image-list" | | | monitor2: | | | -monitor_type: "process" | | | -process_name: "haproxy" | | | -host: node1 | | | | +--------------+--------------------------------------------------------------+ |metrics | In this test case, there are two metrics: | | | 1)service_outage_time: which indicates the maximum outage | | | time (seconds) of the specified Openstack command request. | | | 2)process_recover_time: which indicates the maximun time | | | (seconds) from the process being killed to recovered | | | | +--------------+--------------------------------------------------------------+ |test tool | Developed by the project. Please see folder: | | | "yardstick/benchmark/scenarios/availability/ha_tools" | | | | +--------------+--------------------------------------------------------------+ |references | ETSI NFV REL001 | | | | +--------------+--------------------------------------------------------------+ |configuration | This test case needs two configuration files: | | | 1) test case file: opnfv_yardstick_tc053.yaml | | | -Attackers: see above "attackers" discription | | | -waiting_time: which is the time (seconds) from the process | | | being killed to stoping monitors the monitors | | | -Monitors: see above "monitors" discription | | | -SLA: see above "metrics" discription | | | | | | 2)POD file: pod.yaml | | | The POD configuration should record on pod.yaml first. | | | the "host" item in this test case will use the node name in | | | the pod.yaml. | | | | +--------------+--------------------------------------------------------------+ |test sequence | description and expected result | | | | +--------------+--------------------------------------------------------------+ |step 1 | start monitors: | | | each monitor will run with independently process | | | | | | Result: The monitor info will be collected. | | | | +--------------+--------------------------------------------------------------+ |step 2 | do attacker: connect the host through SSH, and then execute | | | the kill process script with param value specified by | | | "process_name" | | | | | | Result: Process will be killed. | | | | +--------------+--------------------------------------------------------------+ |step 3 | stop monitors after a period of time specified by | | | "waiting_time" | | | | | | Result: The monitor info will be aggregated. | | | | +--------------+--------------------------------------------------------------+ |step 4 | verify the SLA | | | | | | Result: The test case is passed or not. | | | | +--------------+--------------------------------------------------------------+ |post-action | It is the action when the test cases exist. It will check | | | the status of the specified process on the host, and restart | | | the process if it is not running for next test cases. | | | | | | Notice: This post-action uses 'lsb_release' command to check | | | the host linux distribution and determine the OpenStack | | | service name to restart the process. Lack of 'lsb_release' | | | on the host may cause failure to restart the process. | | | | +--------------+--------------------------------------------------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | | | execution problem. | | | | +--------------+--------------------------------------------------------------+