<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[u014089131的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/u014089131</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; u014089131]]></copyright><item><title><![CDATA[cpuset参数说明]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/77099770</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/77099770</guid><author>u014089131</author><pubDate>Fri, 11 Aug 2017 16:30:14 +0800</pubDate><description><![CDATA[cpuset下面参数：
-rw-r--r-- 1 root   root   0 1970-01-01 19:15 cgroup.clone_children
-rw-r--r-- 1 root   root   0 1970-01-01 19:15 cgroup.procs
-rw-r--r-- 1 root   root   0 1970-01-01 19:15 cpu_exclusiv]]></description><category></category></item><item><title><![CDATA[几个调度器参数说明：]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/77097357</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/77097357</guid><author>u014089131</author><pubDate>Fri, 11 Aug 2017 14:40:01 +0800</pubDate><description><![CDATA[1. /proc/sys/kernel/sched_short_sleep_ns


调度器在任务运行短暂峰值时总是试图避免唤醒idle cpu。
如果任务平均峰值小于sysctl_sched_short_burst纳秒，并且睡眠
平均时间大于sysctl_sched_short_sleep纳秒，那么此任务倾向被打包。


提高这个值会导致任务更频繁被打包，有利于功耗，但是会损害性]]></description><category></category></item><item><title><![CDATA[perf工具使用]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/76410327</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/76410327</guid><author>u014089131</author><pubDate>Mon, 31 Jul 2017 09:07:13 +0800</pubDate><description><![CDATA[perf用法：


1.编译perf：
直接在android下执行make perf


2.perf支持的命令如下：
root:# perf


 usage: perf [--version] [--help] COMMAND [ARGS]


 The most commonly used perf commands are:
   annotate      ]]></description><category></category></item><item><title><![CDATA[优先级反转及解决方法探讨]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/74011084</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/74011084</guid><author>u014089131</author><pubDate>Fri, 30 Jun 2017 17:41:18 +0800</pubDate><description><![CDATA[1. 什么是优先级反转(Priority Inversion)
    由于多进程共享资源，具有最高优先权的进程被低优先级进程阻塞，反而使具有中优先级的进程先于高优先级的进程执行，导致系统的崩溃。这就是所谓的优先级反转(Priority Inversion)。


2. 产生原因
      其实,优先级反转是在高优级(假设为A)的任务要访问一个被低优先级任务(假设为C)占有的资源时,被]]></description><category></category></item><item><title><![CDATA[一则利用内核漏洞获取root权限的案例]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/73933649</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/73933649</guid><author>u014089131</author><pubDate>Fri, 30 Jun 2017 10:02:00 +0800</pubDate><description><![CDATA[kernel 最近出了一个新的本地提权安全漏洞CVE-2013-1763，影响范围比较广泛，ubuntu，Arch，fedora都受到其影响，漏洞刚公布就有牛人发布了利用该漏洞获取root权限的攻击代码，下面会分析该代码是如何获取root权限的。
首先对CVE-2013-1763这个安全漏洞简单介绍一下。

1. 漏洞描述
在net/core/sock_diag.c中，__sock_dia]]></description><category></category></item><item><title><![CDATA[linux tracepoint用法]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/73907995</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/73907995</guid><author>u014089131</author><pubDate>Thu, 29 Jun 2017 14:53:50 +0800</pubDate><description><![CDATA[在kernel中经常会看到trace_XX形式的函数，但是又找不到它的定义。
这个其实是kernel的tracepoint，定义在include/linux/tracepoint.h中。


#define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) \
extern struct tracepoint ]]></description><category></category></item><item><title><![CDATA[binder驱动代码注释下]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/73866315</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/73866315</guid><author>u014089131</author><pubDate>Thu, 29 Jun 2017 08:49:21 +0800</pubDate><description><![CDATA[//将new_buffer插入proc 的allocated_buffers rb tree中
static void binder_insert_allocated_buffer(struct binder_proc *proc,
  struct binder_buffer *new_buffer)
{
struct rb_node **p = &proc->allocated_buf]]></description><category></category></item><item><title><![CDATA[binder驱动源码全注释上]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/73866262</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/73866262</guid><author>u014089131</author><pubDate>Thu, 29 Jun 2017 08:42:32 +0800</pubDate><description><![CDATA[本文主要是自己阅读binder驱动时的注释。
大概会先描述下数据结构，然后贴上主要的代码部分。


 //描述一个binder对象
struct flat_binder_object {
	/* 8 bytes for large_flat_header. */
	__u32		type;//binder类型，如BINDER_TYPE_BINDER
	__u32		flags;//只对第一]]></description><category></category></item><item><title><![CDATA[UEFI在高通平台实现]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/73617716</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/73617716</guid><author>u014089131</author><pubDate>Fri, 23 Jun 2017 11:42:22 +0800</pubDate><description><![CDATA[UEFI(Unified extensible firmware interface)统一的可扩展固件接口，是一种详细描述类型接口的标准。
可扩展固件接口（Extensible Firmware Interface，EFI）是
 Intel 为 PC
固件的体系结构、接口和服务提出的建议标准。其主要目的是为了提供一组在 OS
加载之前（启动前）在所有平台上一致的、正确指定的启动服务，被看做]]></description><category></category></item><item><title><![CDATA[selinux在android中用法以及内核中代码实现]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/72965122</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/72965122</guid><author>u014089131</author><pubDate>Fri, 09 Jun 2017 17:05:18 +0800</pubDate><description><![CDATA[selinux(security enhance linux)是由美国国家安全局开发的，
用来进行强制访问控制，增强linux系统安全性。

传统的linux访问控制采用的是DAC(Discretionary Access Control)模型，
这里面主要用的是uid控制。
在linux系统里，对于文件的操作，只有「所有者」，「所有组」，「其他」这3类的划分。
文件所有者对文件有所有]]></description><category></category></item><item><title><![CDATA[slub分配器实现]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/72782624</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/72782624</guid><author>u014089131</author><pubDate>Sat, 27 May 2017 16:32:40 +0800</pubDate><description><![CDATA[slub分配器对外主要提供几个接口：


//创建一个高速缓冲区
struct kmem_cache *kmem_cache_create(const char *, size_t, size_t,
unsigned long,
void (*)(void *));
//销毁高速缓冲区
void kmem_cache_destroy(struct kmem_cache *);
/]]></description><category></category></item><item><title><![CDATA[slub数据结构]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/72779780</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/72779780</guid><author>u014089131</author><pubDate>Sat, 27 May 2017 11:24:40 +0800</pubDate><description><![CDATA[手机测试过程中，发现某个场景下，手机会概率性死机，初步调试
分析发现内核打开CONFIG_SLUB_DEBUG后，死机问题消失。
最终经过分析定位确定内核某个模块使用内存时越界了一个字节，
导致了kernel panic。
这里面就涉及到了slub在内存中存储结构。

        slub可以认为是一块内存，在内核中除了大块内存按页框从伙伴系统获取外，
内核中还有大量频繁使用的数]]></description><category></category></item><item><title><![CDATA[linux待机流程]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/72477981</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/72477981</guid><author>u014089131</author><pubDate>Thu, 18 May 2017 17:38:13 +0800</pubDate><description><![CDATA[linux待机是通过上层应用往sysfs节点/sys/power/state中写入mem，
从而执行整个系统的待机流程。
待机过程首先是冻结用户进程，内核线程，workqueue，接着依次
执行各种设备的suspend操作，最后cpu core进入low power模式，
等待外部中断或者事件唤醒整个系统。
恢复的过程跟待机过程刚好相反，首先cpu core收到中断后，唤醒cpu cor]]></description><category></category></item><item><title><![CDATA[arm 待机指令 WFI和WFE]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/72473238</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/72473238</guid><author>u014089131</author><pubDate>Thu, 18 May 2017 16:30:43 +0800</pubDate><description><![CDATA[百度百科上对于待机的解释：
待机是将当前处于运行状态的数据保存在内存中，机器只对内存供电，而硬盘、屏幕和CPU等部件则停止供电。由于数据存储在速度快的内存中，因此进入等待状态和唤醒的速度比较快。
对于手机而言，待机就是除了DDR保持低频刷新，维护DDR中数据以外，其他的外围设备都断电，cpu core也进入low power 模式，
停止工作，等待外部事件唤醒。


arm core进]]></description><category></category></item><item><title><![CDATA[linux CONFIG_DEBUG_OBJECTS 用法]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/72236906</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/72236906</guid><author>u014089131</author><pubDate>Tue, 16 May 2017 11:15:11 +0800</pubDate><description><![CDATA[该选项用来开启debugobjects模块，对应内核代码中的debugobjects.c，
这个模块是个通用的调试框架，用来跟踪object的生命周期。
kernel中已有的应用该功能的object有timer，workqueue等，
当然自己也可以定义自己的模块使用这个调试功能。


一个object有下面几种状态：
enum debug_obj_state {
ODEBUG_S]]></description><category></category></item><item><title><![CDATA[内核栈溢出保护]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/70908499</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/70908499</guid><author>u014089131</author><pubDate>Fri, 28 Apr 2017 14:37:40 +0800</pubDate><description><![CDATA[linux内核中有个编译选项CC_STACKPROTECTOR用来开启GCC的stack-protector功能，
这个功能是在GCC4.1版本中引入，用来检测栈是否遭到溢出攻击。


目前我们用的版本中开启了这两个选项CONFIG_CC_STACKPROTECTOR、CONFIG_CC_STACKPROTECTOR_REGULAR。


编译器栈溢出保护原理：
函数栈存储结构，从]]></description><category></category></item><item><title><![CDATA[linux module解析]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/70155977</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/70155977</guid><author>u014089131</author><pubDate>Thu, 13 Apr 2017 11:05:16 +0800</pubDate><description><![CDATA[内核模块操作主要在kernel/module.c中，首先我们看下几个主要的宏定义：
module_init，module_exit。
这两个宏定义取决于是否有定义MODULE，没定义的话，表示模块静态编译进内核中。
我们看下宏定义展开后的表示。


#define module_init(x) __initcall(x);


#define __initcall(fn) dev]]></description><category></category></item><item><title><![CDATA[objdump用法]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/70145370</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/70145370</guid><author>u014089131</author><pubDate>Wed, 12 Apr 2017 17:28:09 +0800</pubDate><description><![CDATA[objdump是个gcc的工具，用于解析二进制目标文件。
具体的用法可以man objdump查看。


下面简单介绍几个常用的用法，以kernel ko文件为例：


-d 反汇编


mmc_block_test.ko:     file format elf64-littleaarch64




Disassembly of section .text:
]]></description><category></category></item><item><title><![CDATA[cpu 拓补结构]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/68922510</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/68922510</guid><author>u014089131</author><pubDate>Fri, 31 Mar 2017 10:39:22 +0800</pubDate><description><![CDATA[1. 前言

在“Linux CPU core的电源管理(1)_概述”中，我们多次提到SMP、CPU core等概念，虽然硬着头皮写下去了，但是蜗蜗对这些概念总有些似懂非懂的感觉。它们和CPU的进化过程息息相关，最终会体现在CPU topology（拓扑结构）上。因此本文将以CPU
 topology为主线，介绍CPU有关（主要以ARM CPU为例）的知识。

另外，CPU topolo]]></description><category></category></item><item><title><![CDATA[linux cpufreq interactive调频代码实现下]]></title><link>https://blog.youkuaiyun.com/u014089131/article/details/68490573</link><guid>https://blog.youkuaiyun.com/u014089131/article/details/68490573</guid><author>u014089131</author><pubDate>Thu, 30 Mar 2017 17:32:31 +0800</pubDate><description><![CDATA[上一篇文章简单介绍了cpufreq初始化过程，最后会调用到cpufreq_init_policy，
在这里面会启动对应的governor。
static void cpufreq_init_policy(struct cpufreq_policy *policy)
{
	struct cpufreq_policy new_policy;
	int ret = 0;

	memcpy(&new_]]></description><category></category></item></channel></rss>