Diary 2016/11/27-2016/12/4 [DRAFT]
Created at 2016-12-06T06:55:15.000Z

2016/11/27

2016/11/28,29

2016/11/30,2016/12/1

2016/12/2,3,4

  • Kernel memory management

    • how to communicate with MMU
      • x86: cr0 (PG flag) and cr3
    • Documentation/x86/x86_64/mm.txt, Documentation/vm, arch/x86/include/asm/page_64_types.h
    • kernel virtual memory only accesable first 47 bit space + last 47 bit space = 48 bits = 9 + 9 + 9 + 9 + 12 bits
    • proc/pid/pagemap: https://lwn.net/Articles/230975/¨B¨K51K¨B
    • proc/meminfo, free(1)
    • LDD: chapter 15 (Memory Mapping and DMA)
    • Understanding Linux Kernel: chapter 2 (Memory Addressing), 8 (Memory Management)
      • this book use a term "linear address", which is not used in LDD.

    • Several memory management hierarchy
      • buddy system (page frame management)
        • struct page * alloc_pages(gfp_t gfp_mask, unsigned int order)
        • unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order)
        • does this always return memory from "direct mapping of all phys. memory"? (I think so)
      • slab allocator (smaller-than-single-page-frame memory management without messing with kernel page tables)
        • void *kmalloc(size_t size, gfp_t flags)
      • virtually-contiguous-but-not-physically-contiguous multi pages memory management by messing with kernel page tables
        • void *vmalloc(unsigned long size)
    • what kind of kernel things won't be swapped out? or is it even possible to swap kernel virtual address ? (depends)
    • could vmalloc swap out some kernel virtual address? (I think so, see do_page_fault)
    • ? why kernel text is not included in 64TB direct mapping starting from PAGE_OFFSET?
    • x86 mmu considers access rights depending on ring level?
      • there's a User/Superviser flag in page table
  • Kernel memory management for process

    • user process driven thing: do_mmap, do_brk (stack growth is handled expand_stack in do_page_fault)
      • we don't need to allocate page frame but isn't it necessary to update page tables? can we wait until page fault? (looks like so, see handle_mm_fault below)
      • Of course, do_munmap does free_pgtables though.

    • void __do_page_fault(struct pt_regs *regs, unsigned long error_code, unsigned long address)
      • int vmalloc_fault(unsigned long address)
      • void bad_area(struct pt_regs *regs, unsigned long error_code, unsigned long address)
      • int expand_stack(struct vm_area_struct *vma, unsigned long address)
      • int handle_mm_fault(struct vm_area_struct *vma, unsigned long address, unsigned int flags)
    • COW thing
      • share page tables and set write protection:unsigned long copy_one_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm, pte_t *dst_pte, pte_t *src_pte, struct vm_area_struct *vma, unsigned long addr, int *rss)
      • copy on write `int do_wp_page(struct fault_env *fe, pte_t orig_pte)'
  • C standard

    • The sizeof and _Alignof operators (ISO/IEC 9899:201x 6.5.3.4)

      The value of the result of both operators is implementation-defined, ...

  • Kernel process management

    • ? how stack is controlled (it's always in kernel virtual memory space right?)
      • ? should read Documentation/x86/kernel-stacks
      • CONFIG_THREAD_INFO_IN_TASK is unset on my machine
      • user mode stack and kernel mode stack ??

    • how "shutdown", "reboot" is defined?
      • read systemd-halt.service(8) and systemd/src/core/shutdown.c
      • but, there's a systemcall for reboot(2)
  • ? Kernel topics

    • bootup
    • (virtual) file system
    • smp
    • interrupt/exception/syscalls
    • virtualization

  • ? v8 interface

  • Chromium

  • Kernel program loading

    • ? execve(2)
    • ? dynamic link is not a kernel facility, right?
    • getauxval(3), vdso(7), ld-linux.so(8)
    • musl/ldso
    • execve(2)

    If the executable is a dynamically linked ELF executable, the interpreter named in the PT_INTERP segment is used to load the needed shared objects. This interpreter is typically /lib/ld-linux.so.2 for binaries linked with glibc.

    • getauxval(3)

    ... the auxiliary vector, a mechanism that the kernel's ELF binary loader uses to pass certain information to user space when a program is executed. ... The primary consumer of the information in the auxiliary vector is the dynamic linker ld-linux.so(8).

  • ? TCP intricates