详解缺页中断-----缺页中断处理(内核、用户)

一、什么是缺页中断?

进程线性地址空间里的页面不必常驻内存,在执行一条指令时,如果发现他要访问的页没有在内存中(即存在位为0),那么停止该指令的执行,并产生一个页不存在的异常,对应的故障处理程序可通过从外存加载该页的方法来排除故障,之后,原先引起的异常的指令就可以继续执行,而不再产生异常。

二、页面调度算法

将新页面调入内存时,如果内存中所有的物理页都已经分配出去,就按照某种策略来废弃整个页面,将其所占据的物理页释放出来;

三、查看进程发生缺页中断的次数

ps -o majflt,minflt -C program查看

majflt和minflt表示一个进程自启动以来所发生的缺页中断的次数;

四、产生缺页中断的几种情况

1、当内存管理单元(MMU)中确实没有创建虚拟物理页映射关系,并且在该虚拟地址之后再没有当前进程的线性区(vma)的时候,可以肯定这是一个编码错误,这将杀掉该进程;

2、当MMU中确实没有创建虚拟页物理页映射关系,并且在该虚拟地址之后存在当前进程的线性区vma的时候,这很可能是缺页中断,并且可能是栈溢出导致的缺页中断;

3、当使用malloc/mmap等希望访问物理空间的库函数/系统调用后,由于linux并未真正给新创建的vma映射物理页,此时若先进行写操作,将和2产生缺页中断的情况一样;若先进行读操作虽然也会产生缺页异常,将被映射给默认的零页,等再进行写操作时,仍会产生缺页中断,这次必须分配1物理页了,进入写时复制的流程;

4、当使用fork等系统调用创建子进程时,子进程不论有无自己的vma,它的vma都有对于物理页的映射,但它们共同映射的这些物理页属性为只读,即linux并未给子进程真正分配物理页,当父子进程任何一方要写相应物理页时,导致缺页中断的写时复制;

五、缺页中断的处理

缺页中断处理函数为arch/arm/mm/fault.c文件中的do_page_fault函数

1、当前执行流程在内核态时

(1)通过mm是否存在判断是否是内核线程,对于内核线程,进程描述符的mm总为NULL,一旦成立,说明是在内核态中发生的异常,跳到no_context

                     if (in_atomic() || !mm)

                               goto no_context;

如果当前执行流程在内核态,不论是在临界区还是内核进程本身(内核的mm为NULL),说明在内核态出了问题,跳到标号no_context进入内核态异常处理,由函数_do_kernel_fault完成;

(2)

 

这个函数首先尽可能的设法解决这个异常,通过查找异常表中和目前的异常对应的解决办法并调用执行;如果无法通过异常表解决,那么内核就要在打印其页表等内容后退出;

 

(2)用户进程的缺页中断

对于用户空间的缺页中断,则会调用函数_do_page_fault.

首先从CPU的控制寄存器CR2中读出出错的地址address,然后调用find_vma(),在进程的虚拟地址空间中找出结束地址大于address的第一个区间,如果找不到的话,则说明中断是由地址越界引起的,转到bad_area执行相关错误处理;

确定并非地址越界后,控制转向标号good_area。在这里,代码首先对页面进行例行权限检查,比如当前的操作是否违反该页面的Read,Write,Exec权限等。如果通过检查,则进入虚拟管理例程handle_mm_fault().否则,将与地址越界一样,转到bad_area继续处理。

handle_mm_fault()用于实现页面分配与交换,它分为两个步骤:首先,如果页表不存在或被交换出,则要首先分配页面给页表;然后才真正实施页面的分配,并在页表上做记录。具体如何分配这个页框是通过调用handle_pte_fault()完成的。

handle_pte_fault()函数根据页表项pte所描述的物理页框是否在物理内存中,分为两大类:

(1)请求调页:被访问的页框不在主存中,那么此时必须分配一个页框,分为线性映射、非线性映射、swap情况下映射

(2)写实复制:被访问的页存在,但是该页是只读的,内核需要对该页进行写操作,此时内核将这个已存在的只读页中的数据复制到一个新的页框中

handle_pte_fault()调用pte_non()检查表项是否为空,即全为0;如果为空就说明映射尚未建立,此时调用do_no_page()来建立内存页面与交换文件的映射;反之,如果表项非空,说明页面已经映射,只要调用do_swap_page()将其换入内存即可;

参考博客:https://blog.csdn.net/u010246947/article/details/10431149

                    http://www.360doc.com/content/11/0721/17/6580811_135034260.shtml

  • 36
    点赞
  • 146
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
http upgrade-insecure-requests是一个HTTP头部字段,用于指定浏览器是否在不安全的HTTP请求中自动升级到安全的HTTPS协议。当该字段设置为1时,浏览器将尝试将HTTP请求升级为HTTPS请求,以提高安全性。 在默认情况下,当浏览器加载一个包含HTTP连接的网页时,网页中的资源请求(例如图片、脚本等)也会默认使用HTTP连接,即使网页本身使用HTTPS连接。这样会存在安全风险,因为HTTP连接的传输是不加密的,可能被黑客窃听、篡改等。 通过使用http upgrade-insecure-requests头部字段,网页可以向浏览器发出指令,在加载时自动将HTTP资源请求升级为HTTPS。这样可以确保网页的所有资源在传输过程中都使用了加密的HTTPS连接,提高用户的安全性。 当浏览器收到网页响应时,会检查其中的资源链接。如果检测到某些资源是使用HTTP连接的,而网页中存在http upgrade-insecure-requests字段并被设置为1,浏览器就会自动将这些资源请求转为HTTPS。整个过程对于用户来说是透明的,用户不需要做任何操作。 需要注意的是,使用http upgrade-insecure-requests头部字段仅仅是告诉浏览器去升级HTTP资源为HTTPS请求,但并不能完全确保资源请求都成功升级为HTTPS。如果某些资源服务器不支持HTTPS,或者HTTPS连接存在错误,那么这些资源仍然会以不安全的HTTP方式加载。 总之,http upgrade-insecure-requests头部字段可以提高网页和资源的安全性,但仍需要保证资源服务器的支持和HTTPS连接的正确配置。同时,网站开发人员和管理员也应该注意安全性措施,确保使用HTTPS连接和加密传输用户的敏感数据。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值