Linux内核笔记007 - 内存管理的进一步封装

以你之姓@ 2022-12-02 13:47 207阅读 0赞

> 本文转自网络文章，内容均为非盈利，版权归原作者所有。  
> 转载此文章仅为个人收藏，分享知识，如有侵权，马上删除。  
> 原文作者：jmpcall  
> 专栏地址：[https://zhuanlan.kanxue.com/user-815036.htm][https_zhuanlan.kanxue.com_user-815036.htm]

内存管理学习到现在这个阶段，虽然内容又长又抽象，但其实仅仅才是整个高楼大厦中埋在地里的那部分，包括：

[Linux内核笔记001][Linux_001]、[Linux内核笔记002][Linux_002]，说明了Intel 80386 CPU为内存管理提供的硬件特性；[Linux内核笔记004][Linux_004]、[Linux内核笔记005][Linux_005]、[Linux内核笔记006][Linux_006]，说明了Linux内核按"页面"为单位，对各个进程的虚拟内存空间、对整个系统的物理内存空间和交换分区的基础管理。而实际应用场景，需要利用这些最基础的方式，封装更多的内存管理方式。

根据我个人的总结，实际应用一般包括两种场景：

*  批发型

基于以"页"为单位的已有管理接口，向系统"批发"内存，再以更灵活粒度的实现一层分配接口。

比如libc库中的malloc()函数，分配粒度完全自由。

malloc(100);    /* 如果独占1个页面，浪费3996字节空间 */
    malloc(5000);   /* 如果独占2个页面，浪费3192字节空间 */

另外，如果写过应用层网络流量处理程序，可能又基于malloc()函数，实现过用于存储网络会话的缓冲池。最简易的缓冲池，是在程序启动时，就预先分配大量内存，直到程序结束时才释放，比如程序启动时分配100万个session，那么启动后就能保证一直有100万个session可以使用，从而可以避免，系统中其它进程在某个时刻消耗过多内存，流量处理程序分配不到session的情况，另外，相比任意粒度的分配释放流程，固定结构的管理逻辑显然要简单的多，比如通过used成员就可以区分session使用/空闲状态，从而每次session的"分配"/"释放"操作，性能上也略优于直接使用malloc()/free()，但当程序处理的流量很大，每秒钟都需要分配/释放大量的session时，整体性能的提升就比较明显了。

![format_png][]

除了这两个例子，应用层根据不同的业务需要，还有很多其它的内存管理思路，内核层本身也封装了各种基于"页"管理之上的内存使用接口，比如： kmalloc()、vmalloc()、slab等。

*  映射型

映射指的是内存空间和IO空间之间的映射，通过内存访问的方式，读写磁盘和各种其它外设。

一方面为了突破硬件的限制：Intel x86系统CPU虽然提供了IN、OUT指令，用于访问I/O空间，但是通过查询Intel手册可以知道，用于传递IO地址的参数，是8位的立即数或16位的DX寄存器，即最多可以寻址64K的I/O空间，随着电脑同时能接的外设越来越多，以及各种新型外设的功能越来越丰富，即对外的寄存器越来越多，64K的I/O寻址能力已经远远不够用了，针对这种情况，内核实现了ioremap()函数，可以将I/O空间映射到内存空间，对外设进行操作。

![format_png 1][]

另一方面就是为了丰富功能：比如文件映射，应用层使用mmap()系统调用，内核层相应实现了sys\_mmap2()函数。

## 1. 内核缓冲区的管理 ##

*  slab特点

① 需要某种对象时，并不直接分配这种对象，而是先分配slab对象，然后将slab对象的对象区，用于最终对象，并且整个所需的对象，可以由多个slab承载，slab之间用链表相连。这样便于扩充和回收，比如流量处理程序，在上网高峰期，启动时默认分配的100万个session就不够用了，就需要扩充session缓冲池的大小，上网低峰期，可能20万个session就足够了，剩余空闲的，就可以释放给系统；

② mem\_zone的道理相同，为了可以方便的合并连续页面，每个slab占用2^n个连续页面块，最多也不超过32个页面；

③ 每个slab有一个空闲对象链数组，它和对象区数组的大小一致，free成员为第一个空闲对象的下标，同时空闲对象链数组的该下标处，为对象区中下一个空闲对象的下标，直接为BUFCTL\_END，slab分配/释放对象时，空闲对象链数组也会相应更新；

④ 为了加快空闲对象的查找速度，slab的实现始终保持：同一个kmem\_cache\_s结构上挂的slab，根据使用情况划为三截，第一截中的slab，包含的对象为全部使用，第二截中的slab，包含的对象为部分使用，第三截中的slab，包含的对象为全部空闲。  
这些特点，相比malloc()，在性能和缓解内存碎片方面是有优势的，不过malloc()侧重的是灵活的分配粒度，所以在这两点上有些牺牲，完全是情有可原的。

![format_png 2][]

*  着色区

书上简单提了一下，着色区可以提高缓冲行命中，但没有过多解释为什么可以提高命中，所以仍然是写点我个人的理解：

我记不清就是这本书，还是内核代码的某个注释提到过，通过slab管理的数据结构，访问频率越高的成员，建议放在结构体的越前面。同时我又查了一下[高级缓存的命中原理][Link 1]，它包括全相联映射、直接相联映射、组相联映射三种方式，总之就是很多不同的内存页，会映射到相同的高级缓存块，比如下图所示，两个slab都是以页边界开始，第一个着色区为0，第二个着色区为一个缓冲行大小，这样，两个slab中的所有对象，前面部分的高频访问成员，映射的缓冲行就是错开的，从而访问对象1、对象2的前n个成员时，都不会覆盖对方前n个成员对应的缓冲行，从而降低了不同对象中高频访问成员在高级缓存中的冲突率。

![format_png 3][]

*  slab整体组织

单个slab，由slab\_t结构管理，描述包含的实际对象的情况，包含同种对象的多个slab，由kmem\_cache\_t结构（即struct kmem\_cache\_s）管理，而每个kmem\_cache\_t对象本身，又是从挂在一个总根kmem\_cache\_t对象（变量名为cache\_cache）上的slab分配的。

![format_png 4][]![format_png 4][]

比如，现在需要预先分配100万个session对象，那么最终得到的就是一个kmem\_cache\_t对象，这个kmem\_cache\_t对象可能挂了10个新创建的slab，每个slab包含10万个session，而这个kmem\_cache\_t对象本身，又是从挂在cache\_cache上的某个slab中分配的。

梳理一下，就是这样：

kmem_cache_t *kmem_cache_create()
      |- 从cache_cache分配一个kmem_cache_t对象
      |- 创建10个新slab_t对象，每个slab包含10万个session，并且全部链入kmem_cache_t对象

这里有一点点容易犯糊涂：cache\_cache也是一个kmem\_cache\_t对象，它是如何被创建的呢？

很显然，cache\_cache不能通过调用kmem\_cache\_create()函数创建，要不然就成"先有鸡先有蛋"的问题了，通过代码可以看到，它是一个全局变量，占用的内存在进程的数据段中，在内核加载时就分配了，并且将slab\_t对象链表初始化为空，由后续触发扩展逻辑时添加slab：

/* internal cache of cache description objs */
    static kmem_cache_t cache_cache = {
        slabs:      LIST_HEAD_INIT(cache_cache.slabs),
        firstnotfull:   &cache_cache.slabs,
        objsize:    sizeof(kmem_cache_t),
        flags:      SLAB_NO_REAP,
        spinlock:   SPIN_LOCK_UNLOCKED,
        colour_off: L1_CACHE_BYTES,
        name:       "kmem_cache",
    };

*  接口

经过上述描述，slab的代码就很容易看懂了：

① slab创建/销毁：kmem\_cache\_create() / kmem\_cache\_destroy()；

② 从slab分配/释放实际对象：kmem\_cache\_alloc() / kmem\_cache\_free()，slab中的实际对象已全部使用时，kmem\_cache\_alloc()会调用kmem\_cache\_grow()进行扩展；

③ 回收空闲slab：kmem\_cache\_shrink()，[Linux内核笔记006][Linux_006]分析kswapd()函数时，就已经见到过内存紧张时，这个函数被调用的过程。

## 2. 外部设备存储空间的地址映射 ##

PCI外设中，都会有用于配置pci地址的寄存器， 具体可以等到学习书中8.4节"PCI总线"时，再详细了解，目前只需要知道，电脑启动阶段，BIOS会为每个PCI外设安排好总线地址，总线地址即物理地址（lspci命令不带参数，查看到的是总线号，lspci -v可以看到总线地址，不要搞混淆），这样内核就可以通过映射的物理内存，读写外设对外的寄存器了。但是由于保护模式下，程序不可以直接访问物理内存，所以就需要分配一块虚拟内存区间，映射到外设所在的物理内存，再由程序使用，这就是ioremap()函数的功能。

相比内存分配的过程，ioremap()不需要分配物理页面，直接获取BIOS为外设安排的物理地址即可，这些物理页面也不会被swapd()函数换出，因为为了保证对外设的访问必须经过内核，所以是从内核空间分配一块虚拟区间进行映射的。

我有时候觉得，内核之所以难理解，可能是因为我们先接触到的是上层，学习的过程也相应是"自上而下"的，然而"自下而上"往往更接近自然的发展过程，所以有些情况，我们也可以从底层往上层想，比如对于人的感观，系统中的进程都是在"同时"执行，但实际上 ，如果先从上层撇开进程的概念，从最底层把整个系统看作一个"超大程序"，则：  
① "超大程序"执行初期，一直顺着内核的代码执行，直到执行到idle进程创建的逻辑，以及根据系统启动配置创建init进程，和更多的用户进程，使得"超大程序"又动态增多了一部分指令， 所以进程的本质，就是"动态增加指令，并分配相应资源，然后跳转到增加的指令执行"；

② 对于单核的情况，每个时刻，CPU只可能执行"超大程序"的其中一条指令，所以进程不会"同时"执行；

③ 内核代码，有一部分在没有进程之前执行，有一部分，由进程根据用户代码通过中断/异常的方式"调用"，或者由时钟中断"调用"，"中断、异常和系统调用"是书中第三章内容，下一篇笔记就开始学习，目前只需要知道，内核的代码，有一部分是"依附"于进程执行的，"超大程序"在创建进程时，才会相应创建一个进程管理对象，里面包含这个进程使用的各种资源等，而不是"依附"进程执行到内核时，就一定或者可能还没有进程管理对象，所以即使每个进程管理结构，都有对内核空间的管理信息，仍然需要一个内核独立使用的管理对象，remap\_area\_pages()函数中，init\_mm就是由内核独立使用。

![format_png 5][]![format_png 5][]

对于内核空间，我之前产生过这样的疑问：某个进程修改内核空间的映射，其它进程如何"知道"？

[Linux内核笔记004][Linux_004]，介绍过swapper\_pg\_dir变量，当时的情景，对应的是实模式到保护模式的过渡阶段，只介绍了根据初始值中的2个目录项，临时映射了8MB大小的内存，后续执行到pagetable\_init()函数，会为目录表的后1/4部分，即用于内核空间映射的目录项（0xc0000000~0xffffffff虚拟地址的最高10，对应的目录项索引为0x300~0x3ff，即768~1023），直接分配页表并建立映射。

每个进程都是独立使用一个目录表，索引值小于768的目录项，指向的页表也都是独立的，所以用户空间才可以被隔离，相比而言，索引值达到768的目录项，指向的页表是内核初始化阶段就统一分配的，内核空间的映射，只在页表层修改，即使某个页表中的页表项全部为0，也不释放该页表，这样，只要各个进程的目录表后1/4是从swapper\_pg\_dir复制的，就能保证内核空间可以正确的被共享，内核的实际实现也正是这样：idle进程是系统中的第一个进程，进程管理对象直接通过全局变量定义，通过初始化值就可以看出，目录表指向的就是swapper\_pg\_dir，其它进程的目录表又都是从父进程复制。

## 3. 系统调用brk() ##

内核代码的逻辑，决定了对各个进程虚拟空间的布局，Linux系统中，各个进程虚拟空间的低地址区，依次为代码段、初始化数据段、未初始化数据段，再往上是堆和栈，其中，栈靠近内核空间，向下增长，堆靠近数据段，向上增长。

堆的底端，在进程创建完成时就确定了，大小只能从顶端的边界开始调整，增长时要延着边界向上，分配虚拟区间和物理页面，并建立映射，减小时要延着边界向下，撤消虚拟区间与物理页面的映射。brk()函数是一个系统调用，就是用于动态调整进程堆区的大小。系统调用需要通过"门"进行调用，跟调用应用程序中的函数相比，除了会让CPU跳转到特定的指令块执行，还会让CPU从用户态切换到内核态，等到学习第三章"中断、异常和系统调用"，就能详细的了解，先明白brk()函数用于增加/减小进程的堆即可。libc库，在堆之上，又实现了一层管理，从而可以利用malloc()/free()函数，执行更灵活粒度的分配/释放。

![format_png 6][]

通过brk()函数进入内核态后，执行的是sys\_brk()内核函数：

sys_brk()
     |- if (期望边界 < 当前边界)
     |   |- do_munmap()
     |   |   |  // 从当前进程已使用虚拟区间中，查找第一个结束地址高于期望边界的区间
     |   |   |- find_vma_prev()
     |   |   |- do_munmap()还会在其它情景中被调用，所以要考虑释放某个区间当中的区域，将原区间一分为二的情况
     |   |   |- 也要考虑释放区间，跨越已存在的多个区间的情况
     |   |   |- /* 以下部分，涉及到文件系统，可以先不深究 */
     |   |   |  /*
     |   |   |   * fs/namei.c,202，i_writecount含义注释:
     |   |   |   *  0:  no writers, no VM_DENYWRITE mappings
     |   |   |   * <0: (-i_writecount) vm_area_structs with VM_DENYWRITE set exist
     |   |   |   * >0: (i_writecount) users are writing to the file.
     |   |   |  */
     |   |   |- "<0"与">0"互斥，所以执行到此处的前提是"i_writecount<=0"
     |   |   |- 如果要撤消的虚拟区间，是通过mmap()遇到到文件的，执行740~750行的代码时，要避免其它进程对文件进行写操作
     |   |   |- /* 以下是目前需要深刻理解的 */
     |   |   |- // 解除虚拟页面和物理页面的映射
     |   |   |- zap_page_range()
     |   |       |- zap_pmd_range()  // 循环执行，直到最后一个映射对应的目录项
     |   |           |- zap_pte_range()  // 循环执行，直到最后一个映射对应的中级目录项
     |   |               |- ptep_get_and_clear()  // 清除相应范围的页表项
     |   |               |- free_pte()
     |   |                   |- if (pte_present(pte))
     |   |                   |   |- free_page_and_swap_cache()
     |   |                   |       |- delete_from_swap_cache_nolock()
     |   |                   |       |  |- lru_cache_del()  // 从LRU队列移除，如果来自非交换文件，先将内容写进文件
     |   |                   |       |  |- __delete_from_swap_cache()  // 从换入换出队列移除(在address_space结构中)
     |   |                   |       |  |- page_cache_release()  // 释放LRU占用的引用计数
     |   |                   |       |- page_cache_release()     // 释放分配时就分配的引用计数1
     |   |                   |- else
     |   |                       |- swap_free()   // 递减盘上页面使用计数
     |   |- unmap_fixup()    // 处理虚拟区间一分为二等情况
     |   |- free_pgtables()  // 撤消掉一些映射后，可能有些页表的页表项全部为0了，相应的的页表也要释放
     |- else  // 扩展堆的大小
         |- 检查资源限制(ulimit命令可以查看/设置各个进程堆大小、栈大小，以及其它资源的限制)
         |- find_vma_intersection()  // 检查是否与已有区间冲突，高端区间可能是与栈冲突，低端区间可能是与进程本身的数据段冲突
         |- vm_enough_memory()       // 检查是否有足够的内存用于扩展
         |- do_brk()                 // 扩展
             |- make_pages_present()
                 |- handle_mm_fault()  // 主动利用缺页异常处理函数，建立映射

## 4. 系统调用mmap() ##

*  mmap()应用

mmap()函数用于将文件的指定区间，映射到内存，从而可以直接通过内存，读写文件内容。

原型：void \*mmap(void \*addr, size\_t length, int prot, int flags, int fd, off\_t offset);

flags参数包含很多标志位，个人觉得以下2个对mmap()函数的理解，影响较大：

MAP\_ANONYMOUS：匿名映射，映射到的是dev/zero文件，可以用于父子进程间共享内存；

MAP\_FIXED：flags不包含该标志时，addr参数只是一个参考值，包含该标志时，则要求mmap()一定使用addr地址处的虚拟区间进行映射，并且要求addr处的虚拟区间原本就已经映射，一般用于加载.so文件，.text段、.data段、.bss段属于不同，不可以位于同一个虚拟区间，但各自mmap()，又不能保证位置上连续，所以先映射出一块总的，然后分别MAP\_FIXED覆盖。

*  mmap()函数分析

// Linux-2.4.0往前一些的版本
    old_mmap()
     |- copy_from_user()  // 将参数拷贝到内核空间
     |- do_mmap2()
     
    // Linux-2.4.0版本
    sys_mmap2()
     |- do_mmap2()
     
    // old_mmap()和sys_mmap2()仅仅是传递参数的方式不一样，关键逻辑都调用do_mmap2()完成
    do_mmap2()
     |- do_mmap_pgoff()
         |- 检查文件属性，是否满足flags参数指定的映射方式
         |- kmem_cache_alloc()  // 分配一个vm_area_struct对象，用于管理新增的虚拟区间
         |- if (flags参数指定MAP_FIXED)
         |   |- 用于覆盖已有虚拟区间，不需要重新分配
         |- else
         |   |  // 从TASK_UNMAPPED_BASE即1G开始往上找一块可以容纳映射长度的空闲虚拟区间
         |   |- get_unmapped_area()
         |- kmem_cache_alloc()  // 分配一个虚拟区间管理结构，并初始化成员
         |  // 记录映射在文件中的起点，这样虚拟区间的每个页面对应的"盘上页面"就已经确定了，不需要像swap文件那样依赖PTE
         |- vma->vm_pgoff = pgoff
         |  // 先分配，再检查条件
         |  // 否则如果由于分配函数内部暂时分配不到物理页面，"礼让"其它进程先执行再回到这里，先前的检查就都失效了
         |- if (do_munmap()撤消重叠区间失败
         |      || 进程虚拟区间个数已经达到上限
         |      || 本次为建立进程专用可写区间，但物理内存不够)
         |   |- 释放新分配的虚拟区间管理结构
         |  // flags参数包含MAP_ANONYMOUS标志位，为匿名映射，file=NULL
         |- if (file)
         |   |- if (flags参数指定MAP_DENYWRITE)
         |   |   |- deny_write_access()  // 不允许通过常规操作访问文件
         |   |- get_file()  // 递增file引用计数
         |   |- file->f_op->mmap()  // 如果file是Ext2文件，mmap函数指针指向generic_file_mmap()函数
         |   |  generic_file_mmap()
         |   |   |  // file_private_mmap/file_shared_mmap又进一步提供了nopage函数指针：filemap_nopage()
         |   |   |- vma->vm_ops = &file_private_mmap/&file_shared_mmap  // 根据flags参数是否指定VM_SHARED
         |- else if (flags参数指定MAP_SHARED)
             |- shmem_zero_setup()
                 |  // 书中6.7节"共享内存"详细介绍
                 |- shmem_file_setup()   // 映射到dev/zero文件
                 |- vma->vm_ops = &shmem_shared_vm_ops

通过mmap()的实现可以看到，它主要就是新增了一个虚拟区间，然后设置了映射的目标文件和范围，以及一些函数指针。换句话说，它只是描述了要如何映射，并没有实际映射任何一个虚拟页面到文件，实际的映射是在某个虚拟页面受到访问时，在do\_page\_fault()函数中完成的：

mmap()函数中执行的file->f\_op->mmap()，和do\_page\_fault()函数中执行的vma->vm\_ops->nopage()，都叫做VFS（虚拟文件系统）接口，对于Ext2文件，它们最终执行的分别是Ext2文件驱动中的do\_mmap2()、filemap\_nopage()。有一句话叫做"Linux一切皆文件"，比如，socket()函数返回的就是文件描述符，读写该文件描述符，就可以收发网络报文，除此之外，键盘对应的是字符设备文件，硬盘对应的是块设备文件。。而不同文件的功能不同，是因为对应的硬件和驱动的实现逻辑不同，在各种不同的驱动之上，内核抽象了一套文件操作的统一接口，即VFS（相当于文件操作框架），内核本身只使用VFS接口操作文件，不关心不同文件系统的区别，VFS接口的功能由驱动层具体实现。所以书中建议，等到学完第五章"文件系统"，可以回头再看一遍mmap()函数的实现。

*  对比

① mmap()文件映射 —— read()、write()

read()、write()函数会为文件在内核空间分配缓存，所以mmap()的性能优势在首次读写文件的时候，比如read()函数从硬盘读取文件内容，要先从内核空间分配一块缓存（不能直接读到用户态buffer映射的物理内存，因为读取文件也是以页为单位的，另外还有预读等情况，会覆盖buffer之外的内存，所以要另外找一块物理内存作为缓存），然后复制到用户空间，而mmap()用户态的buffer，天生就会映射到文件内容所在的物理页面，所以少了一次内核态与用户态之间的复制，write()函数同理。

② mmap()匿名映射 —— brk()

mmap()匿名映射和brk()一样，用于malloc()内部实现。使用brk()只能通过边界调整堆的大小，如果边界上的页面还在使用，即使free()掉再多的内存，仍然由libc层维持着，并没有真正释放给系统，但可以缓解虚拟空间的碎片；使用mmap()可以从1G虚拟地址之上，到栈顶之间，寻找空闲的虚拟区间，每个区间可以使用brk()单独释放。

## 5. malloc() ##

应用层，又基于内核的接口，对内存管理做了更高一层的封装，最亲切的就是malloc()/free()。搞清楚malloc()/free()内部的机制，是利用堆溢出漏洞的基本要求，墙裂推荐一个链接：[https://sploitfun.wordpress.com/archives/][https_sploitfun.wordpress.com_archives]

*  [Understanding glibc malloc][]，介绍了malloc()/free()的内部机制
 *  [Linux (x86) Exploit Development Tutorial Series][Linux _x86_ Exploit Development Tutorial Series]，介绍了各种二进制漏洞，其中包括堆溢出的利用原理

[https_zhuanlan.kanxue.com_user-815036.htm]: https://zhuanlan.kanxue.com/user-815036.htm
[Linux_001]: https://blog.csdn.net/u013469753/article/details/108316191
[Linux_002]: https://blog.csdn.net/u013469753/article/details/108316428
[Linux_004]: https://blog.csdn.net/u013469753/article/details/108317017
[Linux_005]: https://blog.csdn.net/u013469753/article/details/108317335
[Linux_006]: https://blog.csdn.net/u013469753/article/details/108317507
[format_png]: /images/20221123/9171641a3c0848658ad9c6e4507a385c.png
[format_png 1]: /images/20221123/16315e5ecd4c4e63bbd5c4f7f4edd959.png
[format_png 2]: /images/20221123/0ec31685fdb745de95b7115601327678.png
[Link 1]: http://www.doc88.com/p-212945104357.html
[format_png 3]: /images/20221123/ff4692ca37cd4bb09b11cd307ac4e565.png
[format_png 4]: /images/20221123/a5f2185b22104c7984c72de94ab2bd4a.png
[format_png 5]: /images/20221123/ae92bf44dbac4285bfa7cddc312bd8f2.png
[format_png 6]: /images/20221123/021c7610c9044d6a899df41b30e94c07.png
[https_sploitfun.wordpress.com_archives]: https://sploitfun.wordpress.com/archives/
[Understanding glibc malloc]: https://sploitfun.wordpress.com/2015/02/10/understanding-glibc-malloc/
[Linux _x86_ Exploit Development Tutorial Series]: https://sploitfun.wordpress.com/2015/06/26/linux-x86-exploit-development-tutorial-series/