在原来配置的基础上,make menuconfig选中如下选项重新配置Linux,使之携带调试信息
1.概述 某年某月某日某项目的线上分布式文件系统服务器多台Linux系统kernel崩溃,严重影响了某项目对外提供服务的能力,在公司造成了不小影响。通过排查线上问题基本确定了是由于linux内核panic造成的原因,通过两个阶段的问题排查,基本上确定了linux内核panic的原因。排查问题的主要手段就是网上查找资料和根据内核错误日志分析并且构造条件重现。本文档就是对自己在整个问题排查过程中的总结。 2.第一阶段 因为刚出现问题的时候大家都比较紧急,每天加班都很晚,也制定了很多问题重现和定位原因的计划
前言: 在《[linux][pthread]qemu的一次pthread create失败的分析》中分析了pthread失败的原因以及解决方法。修改了pidmax之后,一直没有看到现象发生,但是不能证明问题被解决了,因为当时的环境只有coredump文件,没有找到固定的复现规律。继续观察中。 坏消息是问题又复现了。 好消息是问题能复现了。 分析: 1,clone fail 作者写了脚本,批量启动大量的qemu进程。在启动很大量的qemu之后,会有部分qemu进程crash。结合之前的分析过程,作者判断,
上一篇我们讲了 Linux 系统的启动流程,本文讲解一下 Andorid 系统的启动流程。
一个操作系统,最重要的部分无疑是内核。鸿蒙系统声称自研了内核,从之前开源的 OpenHarmony OS 代码中可以看到,是一款名为 LiteOS 的面向 IoT 领域构建的轻量级物联网操作系统。LiteOS 又有两个版本:LiteOS-A 和 LiteOS-M。而 OpenHarmony OS 2.0 针对手机、平板等富资源设备,则使用的是 Linux 操作系统。
前言: 前文《内存映射技术分析》描述了虚拟内存的管理、内存映射;《物理内存管理》介绍了物理内存管理。 本篇介绍一下内存回收。内存回收应该是整个Linux的内存管理上最难理解的部分了。 分析: 1,PFRA Page Frame Reclaim Algorithm,Linux的内存回收算法。 不过,PFRA和常规的算法不同。比如说冒泡排序或者快速排序具有固定的时间复杂度和空间复杂度,代码怎么写都差不多。而PFRA则不然,它不是一个具体的算法,而是一个策略---什么样的情况下需要做内存回收,什么样的page
大家周末好,本周给大家开始分享Linux内核系列的文章,Uboot的系列文章同时也更新。好了废话就不多说了,开始主题分享。
前言: 进程crash一般比较讨厌,尤其是segmentation fault,所谓的“踩内存”,是最讨厌的。 分析: 1,status 进程的状态,一般使用ps aux命令查看: 其中STAT列
第一种方法纵向或者横向来读都可以,因为代码量不是很大。《linux内核完全剖析》《linux内核完全注释》是引导你横向阅读的书,《linux内核设计的艺术》是引导你纵向阅读的书。建议横向纵向结合着来,纵向跟着bochs调试工具来是必不可少的,当遇到问题时进入到相应的功能模块横向拓展一下。
Linux操作系统在作为服务器的场景下应用最为广泛,但是在使用过程中也会遇到莫名崩溃的情况.这时我们就希望能对崩溃前一刻内存中的数据进行分析,从而找到崩溃的原因.本文将对整个过程所涉及到的技术做一个简单但是全面的介绍,包括:如何安装kdump,如何设置系统参数来捕获崩溃前的内存;如何使用crash做简单的分析;并且介绍如何使用更加简便的工具PyKdump来做crash文件的分析.通过了解这些知识, 可以帮助Linux运维人员更快更方便地排查问题.
perf工具集并不默认安装在系统中,需要进行安装。(找到你系统匹配的版本,我的是linux-tools-5.15.0-91-generic)
接上一篇分析: 《bootloader启动之【 Pre-loader -> Lk】》
我做的是linux本地提权漏洞的复现。但本地提权漏洞并不像其他web漏洞一样,可以直接pull一个docker镜像就ok了,提权的洞复杂在于配置环境,基本都是在虚拟机里复现,一个镜像的大小基本都是上G的,镜像安装时间又长,每个洞要求的kernnel版本号又不同,依赖的库也不一样。环境装好了,漏洞的exp还不一定能打成功,我太难了
本文旨在介绍下几种常见的调试方法gdb、crash、kgdb and kdb 以及dynamic debug. 关于在 Linux 内核上使用debuggers,Linus Torvalds 长期以来对它们不太喜欢。简短地解释这种态度是,依赖调试器可能鼓励用权宜之计而非深思熟虑来解决问题,这会导致代码质量恶化。详细解释可以参考https://lwn.net/2000/0914/a/lt-debugger.php3
电源管理(Power Management)在 Linux Kernel 中,是一个比较庞大的子系统,涉及到供电(Power Supply)、充电(Charger)、时钟(Clock)、频率(Frequency)、电压(Voltage)、睡眠/唤醒(Suspend/Resume)等方方面面。
未来是 AI 的时代,博主最近写代码都喜欢用 AI 写个草稿,修修改改就能用,大幅提高了工作效率。举个例子:
最近项目也和linux kernel技术有关,调试内核和内核模块、修改内核源码,是学习内核的重要技术手段之一。应用这些技术时,都有一本基本的要求,那就是编译内核。因此,在分析内核调试技术之前,本随笔给出内核的编译准备工作与具体实现过程。
第二次写这类博客,之前还是求职期间写的面试之类的经历。下面是做高通安卓驱动的感言。 同一时候献给择职想做驱动的參考。
目标: (1)创建Source Insight 工程,方便后面分析如何启动内核的 (2)分析uboot传递参数,链接脚本如何进入stext的 (3) 分析stext函数如何启动内核: (3.1
中 , 介绍了 调度类 sched_class 结构体的源码 , 重要的 字段 以及 函数指针 ;
作用: 确定用于启动的设备; 从启动的设备的位置搬移一小段代码(4k/8k/16k)到RAM中运行,即SPL;
前言: kvm-clock,tsc,hpet,acpi_pm,pit,rtc。。。这些词看着都晕了@@ 虚拟化场景下,容作者在这里一一道来。 分析: 1,Linux clocksource 以Li
从启动引导程序 bootloader(uboot)跳转到 Linux 内核后,Linux 内核开始启动,今天我们分析一下 Linux 内核启动入口。
上一篇文章 linux内核启动流程分析 - efi_stub_entry 中,为了叙述方便,我们只是粗略的讲了下efi_main函数,这里我们再具体看下。
分析makefile从顶层开始,顺藤摸瓜的分析下去,会涉及到所有的makefile文件。各级子目下的makefile完成的动作obj -y += obj -m += make uImage时,uImage在arch/arm/makefile中,顶层makefile中一定包含了底层的makefile。
上一次咱们分析了 Linux 的启动流程和初始化流程,今天主要分析一下内存方面的初始化和常见的内存分配方式。
国外的Qualys 研究团队在 sudo 发现了堆溢出漏洞,sudo是一种几乎无处不在的非常实用程序,可用于大型 Unix 类操作系统(类似与windows的UAC功能,但是功能更加强大,它还允许用户使用其他用户的安全权限运行程序,不仅限于管理员哟)。
在计算机系统中,CPU的功能是执行程序,总结起来就是我们在教科书上学到的:取指、译码、执行。那么问题来了,如果没有程序要执行,CPU要怎么办?也许您会说,停掉就是了啊。确实,是要停掉,但何时停、怎么停,却要仔细斟酌,因为实际的软硬件环境是非常复杂的。
start_kernel是内核启动阶段的入口,通过单步调试,可以发现它是linux内核执行的第一个init,我们单步进入看看它做了哪些操作:
在 Linux 内核 中 , " 进程控制块 " 是通过 task_struct 结构体 进行描述的 ; Linux 内核中 , 所有 进程管理 相关算法逻辑 , 都是基于 task_struct 结构体的 ;
作为一名程序员,肯定不仅仅限于使用API文档,因为浮于表面是远远不够的。进阶学习的阶段,需要我们保持一颗好奇的心,深入阅读Android源码,学习优秀的代码风格和设计思想,知其然并且知其所以然。
前言: qemu发生了crash。这种类型的问题比较少见,这里说一下这个问题的分析过程。 分析: 1,coredump 生成的coredump,一种是配置了/proc/sys/kernel/cor
前言 前文《[linux][redis]bgsave引起的latency突刺问题分析》中记录了在执行bgsave的时候,因为fork子进程之后,会出现page fault导致了redis的延迟受到了影响。 前文《[THP][redis]THP对redis的影响》中分析了THP(transparent hugepage)对redis的延迟突刺的影响。 大约两年半以前,作者给redis提了PR(https://github.com/redis/redis/pull/5124),但是maintainer并没有回复,一段时间后关闭。 几个月前,第二次提PR(https://github.com/redis/redis/pull/7381)希望解决这个问题,新任的maintainer Oran对THP问题比较感兴趣,同时也把三年多以前的另外一个PR(https://github.com/redis/redis/pull/4001)翻了出来。大约经过一周的讨论和修改,两个PR都已经合入了upstream。 分析 THP的内核逻辑 内核提供了THP开关可以控制,/sys/kernel/mm/transparent_hugepage/enabled,这个开关需要root权限,且是系统级别的影响。 always表示所有的进程都会被khugepaged扫描,尝试使用2M的透明大页。 madvise表示如果有进程调用了THP开关,则打开/关闭。 never表示khugepaged不会对任何进程生效,包括使用madvise的进程。 warning判断 redis的原有的逻辑是在启动阶段检查系统的THP配置,如果不是never,就会产生一个warning。redis自身并没有使用过madvise进行THP操作,即使使用了jemalloc,也不会对主要的内存进行THP操作。所以改成不是always就应该是安全的,所以,Oran接受了这个改动(https://github.com/redis/redis/pull/4001)。 关闭redis的进程THP 更加理想的做法是不管系统配置如何,redis都可以把自己进程的THP开关禁用掉,这样子不需要root权限控制,且不会影响其他的进程。Linux恰好提供了这样了一个syscall,所以在(https://github.com/redis/redis/pull/7381)中,会关闭掉。同时,根据Oran的意见,增加了配置项,在多数情况下,默认都是会自动关闭掉THP,除非用户强制指定了不关闭的配置。这样下来,在大多数情况下,用户都可以避免THP引起的fork之后的剧烈抖动问题。 关于conf的描述 在redis.conf中增加了一个新的配置项“disable-thp”,作者最初的描述是
题目给了 bzImage,core.cpio,start.sh 以及 vmlinux 四个文件,接下来简单介绍一下。
在 【Linux 内核】实时调度类 ③ ( 实时调度类 rt_sched_class 源码 | 调度类 sched_class 源码 ) 博客中 , 简单介绍了 实时调度类 rt_sched_class 结构体 , 下面开始分析该结构体的具体字段含义 ,
Greg Kroah-Hartman 是一名 Linux 内核主线分支的维护者,2021 年 4 月 22 日发布了一个申明,禁止一所美国大学试图以研究名义故意提交带有安全隐患和其他“实验”性质的可疑代码合并到 Linux 内核主线分支。因此,不再欢迎来自明尼苏达大学为上游 Linux 内核开发做出贡献。在后续消息中,确证了之前明尼苏达大学(University of Minnesota)对 Linux 内核的补丁将被还原。
Linux perf(性能剖析器)是一个功能强大的性能分析工具,用于帮助开发人员诊断、调优和监控 Linux 系统及应用程序的性能问题。它实现了基于硬件性能计数器(hardware performance counters),追踪点和软件测量等多种数据收集手段,以便分析系统中各种现象。perf 工具集成在 Linux 内核中,主要通过 perf_event 子系统实现。
Android OS由3层组成,最底层是Kernel,上面是Native bin/lib,最上层是Java层:
文章涉及的实验环境和代码可以到这个git repo获取: https://github.com/nevermosby/linux-bpf-learning
从上文可以得出,start_kernel 函数最后调用的是 rest_init 函数,其实 rest_init 函数不光产生了最重要的 kernel_init (PID=1)和 kthreadd (PID=2)内核进程。
memblock 分配器 中 , 内存块区域 使用 struct memblock_region 结构体进行描述 ,
前言: 想要修改Guest中的文件,第一种办法可以把虚拟机启动虚拟机,在虚拟机内部修改。 还有一种办法,使用qemu的nbd功能。准确来说,是使用linux提供的nbd(Network Block Device),加上qemu提供的qemu-nbd作为后端的server共同实现。 本文先提供使用qemu-nbd修改镜像文件的方法,再分析qemu-nbd的实现。 分析: 1,qemu-nbd 使用qemu-nbd之前,需要先确认当前环境上是不是支持linux nbd: ls /dev/nbd*来确认是不是
为什么会写这样一篇“无效水文”,我想是由于我的这样一种强迫症,对于任何的学习,在不理解原理,无法把他与我的已知知识架构产生联系的时候,我会本能地拒绝这种知识,所以由于这种偏执,很多情况下拖慢了自己的进度,因为很多时候无法有效收集到有用的资料,软件实训的时候,老师只会丢给一个配置文件,然后在此基础上做一些修改开发,可以除了可以勉强做一个垃圾出来,没有任何意义。就连再去做一个垃圾的能力都没有。这种情况直到毕业我才感觉无法再继续这样的生活了,于是开始大量学习,阅读专业书籍。这次就想对这些原本困扰我的东西进行一次小的抛砖引玉式的总结,当然也是把别人已经写过的一些文章综合一下,让入门的人对此好奇的人产生初步印象。 总之,人生没有白走的路。五年之前你正在梦想你今天的生活。 还有,当我们在经历冬季的时候,新西兰正被春风吹拂。所以做自己认为对的事情吧。
OpenHarmony OS 2.0 发布时,标准系统只支持 Hi3516DV300 一种硬件平台,而 Android、IOS 均提供了模拟器供开发人员使用。这也可以理解,毕竟华为长期以来都是设备供应商,专长是硬件,在软件开发方面缺少底蕴。鸿蒙应用开发提供了模拟器,但那是真机模拟器,需要接入到华为的开发平台才能使用。
本文总结了通过分析Linux内核编译过程,特别是vmlinux文件的生成过程,以及分析uImage和zImage的生成方式,深入了解了Linux内核编译的底层原理和过程,对于实际参与Linux内核开发和推广有很大帮助。
原创作品转载请注明出处https://github.com/mengning/linuxkernel/
Tcpdump 是Linux 平台常用的网络数据包抓取及分析工具,tcpdump 主要通过libpcap 实现,而libpcap 就是基于eBPF。
领取专属 10元无门槛券
手把手带您无忧上云