[转帖]Linux进程栈空间大小

linux,进程,空间,大小 · 浏览次数 : 0

小编点评

## 生成内容时带简单的排版 **1. 概述** * Linux系统中创建线程的方式:clone系统调用 * clone系统调用传入的参数:flags、clone_flags、stack_start、stack_size、child_tidptr、pid、trace * flags值:CLONE_VM、CLONE_SIGHAND、CLONE_THREAD、CLONE_SETTLS、CLONE_PARENT_SETTID、CLONE_CHILD_CLEARTID **2. flags值解释** * CLONE_VM:将task_struct中的mm指针设置为新的mm * CLONE_SIGHAND:将task_struct中的mm信号设置为新的mm * CLONE_THREAD:将task_struct中的mm信号设置为新的mm * CLONE_SETTLS:将task_struct中的mm信号设置为新的mm * CLONE_PARENT_SETTID:将task_struct中的mm信号设置为新的mm * CLONE_CHILD_CLEARTID:将task_struct中的mm信号设置为新的mm **3. 代码解析** * copy_process函数中检查了clone_flags,如果设置了CLONE_VM,那么将当前task_struct->mm指针赋值给新的task_struct->mm * 在copy_mm中检查了clone_flags,如果设置了CLONE_VM,那么将当前task_struct->mm指针赋值给新的task_struct->mm * 变量oldmm是指 oldmm指针,如果设置了CLONE_VM,则将mm指针赋值给oldmm * 在copy_mm中检查了clone_flags,如果设置了CLONE_VM,则将当前task_struct->mm指针赋值给新的task_struct->mm **4. 总结** * 生成内容时需要带简单的排版,例如flags值解释、代码解析等

正文

https://zhuanlan.zhihu.com/p/530357476

 

内核栈

Linux上进程的相关属性在内核中表示为task_struct,该结构体中stack成员指向进程内核栈的栈底:

struct task_struct {
    ...
    void *stack;
    ...
}

我们知道Linux的子进程创建都是通过复制父进程的task_struct来进行的,所以可以从系统的0号进程着手分析进程内核栈的大小;0号进程为init_task

struct task_struct init_task = INIT_TASK(init_task);

来看看init_taskstack字段的值:

#define INIT_TASK(tsk)  \
{                                   \
    ...
    .stack      = &init_thread_info,                \
    ...
}
...
#define init_thread_info    (init_thread_union.thread_info)
...
union thread_union init_thread_union;

init_taskstack字段实际上指向thread_union联合体中的thread_info,再来看一下thread_union的结构:

union thread_union {
    struct thread_info thread_info;
    unsigned long stack[THREAD_SIZE/sizeof(long)];
};

所以init_task进程的内核栈就是init_thread_union.stack,而thread_info位于内核栈的栈底;内核栈声明为unsigned long类型的数组,其实际大小与平台相关,即为THREAD_SIZE的定义;对于arm32平台,它的定义为:

/* arch/arm/include/asm/thread_info.h */

#define THREAD_SIZE_ORDER   1
#define THREAD_SIZE     (PAGE_SIZE << THREAD_SIZE_ORDER)

PAGE_SIZE的定义为

/* arch/arm/include/asm/page.h */

#define PAGE_SHIFT      12
#define PAGE_SIZE       (_AC(1,UL) << PAGE_SHIFT)

所以对于arm32平台,PAGE_SIZE大小为4kTHREAD_SIZE大小为8k;此时可以确定init_task的内核栈大小为8k

前面提到进程的创建是在内核中拷贝父进程的task_struct,来看一下这部分代码:

static struct task_struct *dup_task_struct(struct task_struct *orig)
{
    struct task_struct *tsk;
    struct thread_info *ti;
    int node = tsk_fork_get_node(orig);
    int err;

    tsk = alloc_task_struct_node(node);
    ...
    ti = alloc_thread_info_node(tsk, node);
    ...
    err = arch_dup_task_struct(tsk, orig);
    ...
    tsk->stack = ti;
    ...
    setup_thread_stack(tsk, orig);
    ...
}

在复制task_struct的时候,新的task_struct->stack通过alloc_thread_info_node来分配:

static struct thread_info *alloc_thread_info_node(struct task_struct *tsk,
                          int node)
{
    struct page *page = alloc_kmem_pages_node(node, THREADINFO_GFP,
                          THREAD_SIZE_ORDER);

    return page ? page_address(page) : NULL;
}

这里THREAD_SIZE_ORDER1,所以分配了2page,所以我们可以确定,进程的内核栈大小为8k

用户栈大小

用户栈虚拟地址空间最大值

通过ulimit命令可以查看当前系统的进程用户栈的虚拟地址空间上限,单位为kB

~ # ulimit -s
8192

即当前系统中,用户栈的虚拟地址空间上限为8M;为了确认这个值的出处,使用strace,确认ulimit执行过程中,使用了哪些系统调用:

-> % strace sh -c "ulimit -s"
...
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
...

接着到内核中查找该系统调用的实现,函数名为SYSCALL_DEFINE4(prlimit64, .......)

/* kernel/sys.c */

SYSCALL_DEFINE4(prlimit64, pid_t, pid, unsigned int, resource,
        const struct rlimit64 __user *, new_rlim,
        struct rlimit64 __user *, old_rlim)
{
    ...
    tsk = pid ? find_task_by_vpid(pid) : current;
    ...
    ret = do_prlimit(tsk, resource, new_rlim ? &new : NULL,
            old_rlim ? &old : NULL);
    ...
}

函数的第一个参数为pid,第二个参数为资源的索引;这里可以理解为查找pid0的进程中,RLIMIT_STACK的值;函数查找到pid对应的task_struct,然后调用do_prlimit

/* kernel/sys.c */

int do_prlimit(struct task_struct *tsk, unsigned int resource,
        struct rlimit *new_rlim, struct rlimit *old_rlim)
{
    struct rlimit *rlim;
    ...
    rlim = tsk->signal->rlim + resource;
    ...
}

do_prlimit的实现为我们指明了到何处去查找RLIMIT_STACK的值,即tsk->signal->rlim + resource;我们知道0号进程为init_task,所以找到init_task->signal->rlim进行确认

/* include/linux/init_task.h */

#define INIT_TASK(tsk)  \
{  
    ...
    .signal        = &init_signals,                \
    ...
}

...

#define INIT_SIGNALS(sig) {                     \
    ...
    .rlim       = INIT_RLIMITS,                 \
    ...
}

接着找到INIT_RLIMITS宏的定义

/* include/asm-generic/resource.h */

#define INIT_RLIMITS                            \
{                                   \
    ...
    [RLIMIT_STACK]      = {       _STK_LIM,  RLIM_INFINITY },   \
    ...
}

_STK_LIM即为当前系统中,进程用户栈的虚拟地址空间上限:

/* include/uapi/linux/resource.h */

#define _STK_LIM    (8*1024*1024)

当前用户栈虚拟地址空间大小

可以从proc文件系统中,查看进程的虚拟地址空间分布;以init进程为例,其pid为1,可以通过以下命令查看init进程的虚拟地址空间分布,在arm32平台,内核版本3.18.120init进程的用户栈空间大小为132kB

~ # cat /proc/1/smaps
...
beec2000-beee3000 rw-p 00000000 00:00 0          [stack]
Size:                132 kB
...

仔细观察会发现,任意进程在启动后,其栈空间大小基本都是132kB;在分析原因之前,我们先来看一下进程的虚拟地址空间分布:

进程的虚拟地址空间大小为4GB,其中内核空间1GB,用户空间3GB,在arm32平台上,二者之间存在一个大小为16M的空隙;用户空间的准确大小为TASK_SIZE

/* arch/arm/include/asm/memory.h */

#define TASK_SIZE       (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))

即用户空间的地址范围为0x00000000~0xBEFFFFFF

上图左侧为用户空间内的虚拟空间分布,分别为:用户栈(向下增长),内存映射段(向下增长),堆(向上增长)以及BSSDataText;我们关注的重点在用户空间中的栈空间。

在Linux系统中,运行二进制需要通过exec族系统调用进行,例如execveexeclexecv等,而这些函数最终都会切换到kernel space,调用do_execve_common(),我们从这个函数开始分析:

static int do_execve_common(struct filename *filename,
                struct user_arg_ptr argv,
                struct user_arg_ptr envp)
{
    ...
    file = do_open_exec(filename);      // 在内核中打开可执行文件
    ...
    retval = bprm_mm_init(bprm);        // 初始化进程内存空间描述符
    ...
    /* 拷贝文件名、环境变量和执行参数到bprm */
    retval = copy_strings_kernel(1, &bprm->filename, bprm);
    ...
    retval = copy_strings(bprm->envc, envp, bprm);
    ...
    retval = copy_strings(bprm->argc, argv, bprm);
    ...
    retval = exec_binprm(bprm);         // 处理bprm
    ...
}

函数中的bprm是类型为struct linux_binprm的结构体,主要用来存储运行可执行文件时所需要的参数,如虚拟内存空间vma、内存描述符mm、还有文件名和环境变量等信息:

struct linux_binprm {
    ...
    struct vm_area_struct *vma;
    ...
    struct mm_struct *mm;
    unsigned long p; /* current top of mem */
    ...
    int argc, envc;
    const char * filename;  /* Name of binary as seen by procps */
    ...
};

接着回到do_execve_common函数,在调用bprm_mm_init初始化内存空间描述符时,第一次为进程的栈空间分配了一个页:

/*
 * 文件:fs/exec.c
 * 函数调用关系:do_execve_common()->bprm_mm_init()->__bprm_mm_init()
 */

static int __bprm_mm_init(struct linux_binprm *bprm)
{
    ...
    vma->vm_end = STACK_TOP_MAX;
    vma->vm_start = vma->vm_end - PAGE_SIZE;
    ...
}

这里的vma就是进程的栈虚拟地址空间,这段vma区域的结束地址设置为STACK_TOP_MAX,大小为PAGE_SIZE;这两个宏的定义如下:

/* arch/arm/include/asm/processor.h */
#define STACK_TOP_MAX   TASK_SIZE

/* arch/arm/include/asm/memory.h */
#define TASK_SIZE       (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))       // CONFIG_PAGE_OFFSET定义为0xC0000000

/* arch/arm/include/asm/page.h */
#define PAGE_SHIFT      12
#define PAGE_SIZE       (_AC(1,UL) << PAGE_SHIFT)

此时,进程的栈空间如下图所示:

继续回到do_execve_common()函数,到目前为止,内核还没有识别到可执行文件的格式,也没有解析可执行文件中各个段的数据;在exec_binprm()中,会遍历在内核中注册支持的可执行文件格式,并调用该格式的load_binary方法来处理对应格式的二进制文件:

/*
 * 文件:fs/exec.c
 * 函数调用关系:do_execve_common()->exec_binprm()->search_binary_handler()
 */

int search_binary_handler(struct linux_binprm *bprm)
{
    struct linux_binfmt *fmt;
    ...
    list_for_each_entry(fmt, &formats, lh) {
        ...
        retval = fmt->load_binary(bprm);
        ...
    }
    ...
}

search_binary_handler()会依次调用系统中注册的可执行文件格式load_binary()方法;load_binary()方法中会自行识别当前二进制格式是否支持;以ELF格式为例,其注册的load_binary方法为load_elf_binary()

/* fs/binfmt_elf.c */

static int load_elf_binary(struct linux_binprm *bprm)
{
    ...
    for (i = 0; i < loc->elf_ex.e_phnum; i++) {
        ...
            retval = kernel_read(bprm->file, elf_ppnt->p_offset,      // 读取ELF中的各个段
                         elf_interpreter,
                         elf_ppnt->p_filesz);
        ...
    }
    ...
    retval = setup_arg_pages(bprm, randomize_stack_top(STACK_TOP),
                 executable_stack);
    ...
    current->mm->start_stack = bprm->p;
    ...
}

该函数的实现比较复杂,这里我们重点关注setup_arg_pages()函数。

int setup_arg_pages(struct linux_binprm *bprm,
            unsigned long stack_top,
            int executable_stack)
{
    ...
    stack_top = arch_align_stack(stack_top);
    stack_top = PAGE_ALIGN(stack_top);
    ...
    stack_shift = vma->vm_end - stack_top;
    ...
    /* Move stack pages down in memory. */
    if (stack_shift) {
        ret = shift_arg_pages(vma, stack_shift);        // 移动arg pages
        ...
    }
    ...
    stack_expand = 131072UL; /* randomly 32*4k (or 2*64k) pages */
    ...
    if (stack_size + stack_expand > rlim_stack)
        stack_base = vma->vm_end - rlim_stack;
    else
        stack_base = vma->vm_start - stack_expand;
    ...
    ret = expand_stack(vma, stack_base);
    ...
}

前面我们已经初始化了一个页的栈空间,用来存放二进制文件名、参数和环境变量等;在setup_arg_pages()中,我们把前面这一个页的栈空间移动到stack_top的位置;在调用函数时,stack_top的值是randomize_stack_top(STACK_TOP),即一个随机地址,这里是为了安全性而实现的栈地址随机化;函数通过shift_arg_pages()将页移动到新的地址,移动后的栈如下图所示:

接着回到setup_arg_pages()函数,关注如下代码:

stack_expand = 131072UL; /* randomly 32*4k (or 2*64k) pages */
...
if (stack_size + stack_expand > rlim_stack)
    stack_base = vma->vm_end - rlim_stack;
else
    stack_base = vma->vm_start - stack_expand;
...
ret = expand_stack(vma, stack_base);

expand_stack()函数用来扩展栈虚拟地址空间的大小,stack_base是新的栈基地址,这里的stack_expand是一个固定值,大小为128k,即此处将栈空间扩展128k的大小,扩展后栈空间如下:

所以扩展后的栈虚拟地址空间为4kB+128kB,刚刚好132kB.

栈顶地址随机化

前面介绍setup_arg_pages()函数移动栈顶的时候提到,出于安全原因,会将栈顶移动到一个随机的地址:

/*
 * 文件:fs/binfmt_elf.c
 * 函数调用关系:load_elf_binary()->setup_arg_pages()
 */

static int load_elf_binary(struct linux_binprm *bprm)
{
    ...
    retval = setup_arg_pages(bprm, randomize_stack_top(STACK_TOP),
                 executable_stack);
    ...
}

这里randomize_stack_top(STACK_TOP)就是将STACK_TOP进行随机化处理,在我们的平台上。STACK_TOPSTACK_TOP_MAX的值相同,为0xBF000000;我们来分析一下randomize_stack_top()函数:

/* fs/binfmt_elf.c */

#ifndef STACK_RND_MASK
#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12)) /* 8MB of VA */
#endif

static unsigned long randomize_stack_top(unsigned long stack_top)
{
    unsigned long random_variable = 0;

    if ((current->flags & PF_RANDOMIZE) &&
        !(current->personality & ADDR_NO_RANDOMIZE)) {
        random_variable = (unsigned long) get_random_int();
        random_variable &= STACK_RND_MASK;
        random_variable <<= PAGE_SHIFT;
    }
#ifdef CONFIG_STACK_GROWSUP
    return PAGE_ALIGN(stack_top) + random_variable;
#else
    return PAGE_ALIGN(stack_top) - random_variable;
#endif
}

函数整体非常好理解,就是获取一个随机值,再根据栈向上还是向下增长,将栈顶地址加上或减去这个随机值;我们重点关注下面两行:

``` C
random_variable &= STACK_RND_MASK;
random_variable <<= PAGE_SHIFT;

STACK_RND_MASK的值为0x7FFPAGE_SHIFT12;第一行将获取的随机值范围限制在0~0x7FF的范围内;第二行将该值左移12位,这样得到的随机数范围就变成了0~0x7FF000,可以理解为栈顶地址是在一个8MB的范围内取一个4kB对齐的随机值。

线程的用户栈

我们知道在Linux系统上,无论是进程还是线程,都是通过clone系统调用来创建,区别是传入的参数不同;为了确认创建线程时使用的参数,我准备了一个测试程序,然后使用strace来确认:

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

void *function(void *arg) {
    printf("function call\n");
}

int main() {
    pthread_t thread;
    pthread_create(&thread, NULL, function, NULL);
    pthread_join(thread,NULL);
    return 0;
}

该程序的strace部分输出(在x86平台上运行):

clone(child_stack=0x7fd2500d0fb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[36747], tls=0x7fd2500d1700, child_tidptr=0x7fd2500d19d0) = 36747

我们可以看到调用clone的时候传入的flags,其中与内存相关最重要的flagsCLONE_VM;接着我们来看内核部分的源码,仍然从copy_process()函数开始:

/* kernel/fork.c */

static struct task_struct *copy_process(unsigned long clone_flags,
                    unsigned long stack_start,
                    unsigned long stack_size,
                    int __user *child_tidptr,
                    struct pid *pid,
                    int trace)
{
    ...
    retval = copy_mm(clone_flags, p);
    ...
}

...

static int copy_mm(unsigned long clone_flags, struct task_struct *tsk)
{
    struct mm_struct *mm, *oldmm;
    ...
    oldmm = current->mm;
    ...
    if (clone_flags & CLONE_VM) {
        atomic_inc(&oldmm->mm_users);
        mm = oldmm;
        goto good_mm;
    }
    ...
}

copy_mm中,检查了clone_flags,如果设置了CLONE_VM,那么将当前task_struct->mm指针赋值给新的task_struct->mm;所以我们可以得到结论,通过pthread库创建的线程,其内存是与主线程共享的。

 

Linux内核学习资料、教学视频和学习路线图分享有需要的可以自行添加 学习交流群973961276

Linux内核源码/内存调优/文件系统/进程管理/设备驱动/网络协议栈 学习直播公开课

与[转帖]Linux进程栈空间大小相似的内容:

[转帖]Linux进程栈空间大小

https://zhuanlan.zhihu.com/p/530357476 内核栈 Linux上进程的相关属性在内核中表示为task_struct,该结构体中stack成员指向进程内核栈的栈底: struct task_struct { ... void *stack; ... } 我们知道Lin

[转帖]Linux 页表、大页与透明大页

一、 内存映射与页表 1. 内存映射 我们通常所说的内存容量,指的是物理内存,只有内核才可以直接访问物理内存,进程并不可以。 Linux 内核给每个进程都提供了一个独立的虚拟地址空间,并且这个地址空间是连续的。这样,进程就可以很方便地访问内存,更确切地说是访问虚拟内存。 虚拟地址空间的内部又被分为内

[转帖]Linux 页表、大页与透明大页

一、 内存映射与页表 1. 内存映射 我们通常所说的内存容量,指的是物理内存,只有内核才可以直接访问物理内存,进程并不可以。 Linux 内核给每个进程都提供了一个独立的虚拟地址空间,并且这个地址空间是连续的。这样,进程就可以很方便地访问内存,更确切地说是访问虚拟内存。 虚拟地址空间的内部又被分为内

[转帖]《Linux性能优化实战》笔记(八)—— 内存是怎么工作的

一、 内存映射 我们通常所说的内存容量,指的是物理内存。物理内存也称为主存,大多数计算机用的主存都是动态随机访问内存(DRAM)。只有内核才可以直接访问物理内存。那么,进程要访问内存时,该怎么办呢? Linux 内核给每个进程都提供了一个独立的虚拟地址空间,并且这个地址空间是连续的。这样,进程就可以

[转帖]Linux 写时复制技术

https://www.cnblogs.com/dwtfukgv/p/15125933.html 目录 Linux fork Linux exec Linux 进程虚拟地址空间 栈 内存映射段 堆 BSS段 数据段 代码段 分段的优点 页表 写时复制原理 非写时复制fork一个子进程 写时复制for

[转帖]Linux系统:page fault

Linux进程如何访问内存 Linux下,进程并不是直接访问物理内存,而是通过内存管理单元(MMU)来访问内存资源,原因后面会讲到。 为什么需要虚拟内存地址空间 假设某个进程需要4MB的空间,内存假设是1MB的,如果进程直接使用物理地址,这个进程会因为内存不足跑不起来。既然进程不是直接访问物理内存,

[转帖]Linux:页表中PGD、PUD、PMD、TLB等概念介绍

1、PGD: Page Global Directory Linux系统中每个进程对应用户空间的pgd是不一样的,但是linux内核 的pgd是一样的。当创建一个新的进程时,都要为新进程创建一个新的页面目录PGD,并从内核的页面目录swapper_pg_dir中复制内核区间页面目录项至新建进程页面目

[转帖]Linux性能调优之内存负载调优的一些笔记

https://zhuanlan.zhihu.com/p/548770928 写在前面 整理一些Linux内存调优的笔记,分享给小伙伴 博文没有涉及的Demo,理论方法偏多,可以用作内存调优入门 博文内容涉及: Linux内存管理的基本理论 寻找内存泄露的进程 内存交换空间调优 不同方式的内存回收

[转帖]Linux性能优化和内核观测 - 内存篇(一)

内存虚拟内存Linux 采用的是​​虚拟内存​​机制,每个进程都有自己的虚拟内存地址空间,仅当实际使用内存的时候才会映射到物理内存地址之上。这种设计提供了物理内存的超额分配,Linux 中的内存管理机制包括页换出守护进程(page out daemon)、物理换页设备(swap device),以及

[转帖]Linux下strace调试系统应用参数总结(附实例操作讲解)

文章目录 一、简介二、常用参数详解三、实例详解3.1 跟踪具体进程3.2 监控具体程序执行过程 四、其他相关知识链接 一、简介 strace命令是一个集诊断、调试、统计与一体的Linux 用户空间跟踪器,我们可以使用strace对应用的系统调用、信号传递和进程状态变更的监控结果来对应用进行分析,以达