zram的算法种类
LZ77 LZO LZ4 LZ4HC LZO-RLE 842 deflate zstd

压缩的任务是找出重复的字符。
关于LZ算法
分区--找匹配---编码---滑动窗口

lz4 匹配优化hash  编码优化，顺序访问，字节对齐    压缩率有牺牲，压缩速度快
lz4hc 匹配更深入   压缩速度慢
lzo  hash，变长编码   压缩率好
lzo-rle  连续重复字节优化  
deflate  常用于gzip
zstd  天生多线程  可加速

lz4m：基于lz4的内存数据压缩优化， 压缩速度提高，但是压缩率减少

lz4 benchmark: zram-perf

使用zram-perf测试，不是用户数据，没办法模拟用户场景

构造zram-dump来进行效率评估

使用zram-dump下的测试数据：
lz4m 速度快，压缩率劣化

压缩算法优劣：
压缩率：可用内存  压缩速度：slowpath/kswapd 解压速度: page fault 不卡

腾内存的速度，单位时间腾内存的速度，lz4m腾内存速度最快

zram_multi_comp：可以支持zram使用多种不同的压缩算法，取长补短
6.2合入
1. 配置

zram结构体从1个变成4个，1个主压缩算法，3个次压缩算法

目标：让zram重新压缩指定数据，减少zmalloc使用量，关注在压缩率上
遍历zram slot，根据echo的算法，先对slot解压，在按顺序用新算法压缩，直到新的数据大小比原数据小，则更新zram slot

也就是通过配置来实现重压缩

问题是：速度太慢，不可接受，压缩算法仅考虑了压缩率，不考虑压缩速度。不够完善

目标是：重载情况下，腾内存更快。

配置：将lz4作为主压缩算法，lz4m作为第二压缩算法
场景关联：kswapd和绝大部分slowpath，则lz4。 前台进程 lz4m，更快腾出内存

新增精准重压，增加线程，闲时主动压缩


展望：zram使用异构方向优化。


是不是按照不同场景来进行压缩


zram异构压缩技术 基于GPU加速的内存回收
lz4执行时间太长，占整个回收过程的30-40%，这是导致重载情况下CPU争抢和体验劣化的关键瓶颈。
社区patch zsmalloc/zram: there be preemption




cuda已经有lz4的并发实现































zram多压缩算法的效率

在某车载项目上，因为其中多域使用了can总线通信，系统使用麒麟，在大负载的情况下，低概率会触发死机问题。死机伴随着rcu stall信息。很明显，这是一个典型的死核的问题，本文主要总结和分享此问题。
# 复现问题
根据描述的现象，首先就是需要针对现场问题寻找复现办法，可以了解到问题是can通信导致的rcu，所以可以简单通过脚本测试，如下
```
while true
do
cansend can0 1f602001#00000000D0570068
done
```
# 日志
根据上面的测试脚本，内核跑一段时间就出来rcu stall了，其日志如下
```
[ 815.850352] rcu: INFO: rcu_sched self-detected stall on CPU
[ 815.855942] rcu: 0-....: (17844 ticks this GP) idle=d1a/1/0x4000000000000004 softirq=29552/29558 fqs=6000
[ 815.865680] (t=18000 jiffies g=51353 q=2202)
[ 815.870039] Task dump for CPU 0:
[ 815.873269] task:kworker/0:0 state:R running task stack: 0 pid: 1131 ppid: 2 flags:0x0000000a
[ 815.883192] Workqueue: events_freezable input_dev_poller_work
[ 815.888937] Call trace:
[ 815.891389] dump_backtrace+0x0/0x1a8
[ 815.895052] show_stack+0x2c/0x38
[ 815.898370] sched_show_task+0x12c/0x148
[ 815.902299] dump_cpu_task+0x48/0x54
[ 815.905879] rcu_dump_cpu_stacks+0xec/0xf8
[ 815.909977] rcu_sched_clock_irq+0x274/0x6c8
[ 815.914254] update_process_times+0x68/0x90
[ 815.918437] tick_sched_handle.isra.16+0x50/0x64
[ 815.923050] tick_sched_timer+0x50/0x90
[ 815.926893] __hrtimer_run_queues+0x170/0x23c
[ 815.931254] hrtimer_interrupt+0xb4/0x1b8
[ 815.935267] arch_timer_handler_phys+0x38/0x50
[ 815.939713] handle_percpu_devid_irq+0x6c/0x124
[ 815.944243] generic_handle_irq_desc+0x10/0x18
[ 815.948688] __handle_domain_irq+0xbc/0xc4
[ 815.952785] gic_handle_irq+0x2c0/0x30c
[ 815.956627] el1_irq+0xcc/0x180
[ 815.959775] slab_free_freelist_hook+0x0/0xf0
[ 815.964136] skb_free_head+0x38/0x3c
[ 815.967716] skb_release_data+0x64/0xb4
[ 815.971558] skb_release_all+0x30/0x3c
[ 815.975306] __kfree_skb+0x20/0x34
[ 815.978705] consume_skb+0x38/0x44
[ 815.982117] can_receive+0x90/0xf8
[ 815.985526] can_rcv+0xac/0xbc
[ 815.988589] __netif_receive_skb_one_core+0x6c/0x94
[ 815.993466] __netif_receive_skb+0x78/0x80
[ 815.997562] process_backlog+0xac/0x15c
[ 816.001405] net_rx_action+0x148/0x328
[ 816.005152] __do_softirq+0x228/0x2d4
[ 816.008816] __irq_exit_rcu+0x48/0x94
[ 816.012479] irq_exit+0x14/0x20
[ 816.015626] __handle_domain_irq+0xc0/0xc4
[ 816.019721] gic_handle_irq+0x2c0/0x30c
[ 816.023563] el1_irq+0xcc/0x180
[ 816.026710] __schedule+0x40c/0x5d0
[ 816.030204] preempt_schedule_common+0x10/0x24
[ 816.034648] _cond_resched+0x20/0x38
[ 816.038227] mutex_lock+0x1c/0x44
[ 816.041544] iio_read_channel_processed+0x2c/0xd0
[ 816.046253] adc_keys_poll+0x40/0x130
[ 816.049917] input_dev_poller_work+0x28/0x3c
[ 816.054194] process_one_work+0x1d4/0x28c
[ 816.058205] worker_thread+0x1d0/0x260
[ 816.061954] kthread+0xf0/0x100
[ 816.065101] ret_from_fork+0x10/0x18
[ 900.973670] rcu: INFO: rcu_sched self-detected stall on CPU
[ 900.979258] rcu: 0-....: (17996 ticks this GP) idle=d1a/1/0x4000000000000004 softirq=29563/29765 fqs=6000
[ 900.988996] (t=18000 jiffies g=51361 q=715)
[ 900.993271] Task dump for CPU 0:
[ 900.996500] task:kworker/0:0H state:R running task stack: 0 pid: 6 ppid: 2 flags:0x0000000a
[ 901.006426] Workqueue: 0x0 (mmc_complete)
[ 901.010528] Call trace:
[ 901.012980] dump_backtrace+0x0/0x1a8
[ 901.016644] show_stack+0x2c/0x38
[ 901.019961] sched_show_task+0x12c/0x148
[ 901.023889] dump_cpu_task+0x48/0x54
[ 901.027468] rcu_dump_cpu_stacks+0xec/0xf8
[ 901.031565] rcu_sched_clock_irq+0x274/0x6c8
[ 901.035842] update_process_times+0x68/0x90
[ 901.040023] tick_sched_handle.isra.16+0x50/0x64
[ 901.044637] tick_sched_timer+0x50/0x90
[ 901.048480] __hrtimer_run_queues+0x170/0x23c
[ 901.052841] hrtimer_interrupt+0xb4/0x1b8
[ 901.056854] arch_timer_handler_phys+0x38/0x50
[ 901.061299] handle_percpu_devid_irq+0x6c/0x124
[ 901.065830] generic_handle_irq_desc+0x10/0x18
[ 901.070275] __handle_domain_irq+0xbc/0xc4
[ 901.074370] gic_handle_irq+0x2c0/0x30c
[ 901.078212] el1_irq+0xcc/0x180
[ 901.081359] trace_consume_skb+0x10/0x7c
[ 901.085286] consume_skb+0x30/0x44
[ 901.088687] can_receive+0x90/0xf8
[ 901.092086] can_rcv+0xac/0xbc
[ 901.095148] __netif_receive_skb_one_core+0x6c/0x94
[ 901.100025] __netif_receive_skb+0x78/0x80
[ 901.104122] process_backlog+0xac/0x15c
[ 901.107964] net_rx_action+0x148/0x328
[ 901.111712] __do_softirq+0x228/0x2d4
[ 901.115376] __irq_exit_rcu+0x48/0x94
[ 901.119039] irq_exit+0x14/0x20
[ 901.122186] __handle_domain_irq+0xc0/0xc4
[ 901.126281] gic_handle_irq+0x2c0/0x30c
[ 901.130123] el1_irq+0xcc/0x180
[ 901.133269] _cond_resched+0x10/0x38
[ 901.136848] mutex_lock+0x1c/0x44
[ 901.140163] set_pf_worker+0x24/0x5c
[ 901.143743] worker_thread+0x6c/0x260
[ 901.147406] kthread+0xf0/0x100
[ 901.150552] ret_from_fork+0x10/0x18
[ 1056.446969] rcu: INFO: rcu_sched self-detected stall on CPU
[ 1056.452557] rcu: 0-....: (17835 ticks this GP) idle=d1a/1/0x4000000000000004 softirq=29774/29878 fqs=6000
[ 1056.462294] (t=18003 jiffies g=51369 q=1254)
[ 1056.466655] Task dump for CPU 0:
[ 1056.469884] task:kworker/0:0H state:R running task stack: 0 pid: 6 ppid: 2 flags:0x0000000a
[ 1056.479806] Workqueue: 0x0 (mmc_complete)
[ 1056.483908] Call trace:
[ 1056.486360] dump_backtrace+0x0/0x1a8
[ 1056.490024] show_stack+0x2c/0x38
[ 1056.493342] sched_show_task+0x12c/0x148
[ 1056.497269] dump_cpu_task+0x48/0x54
[ 1056.500848] rcu_dump_cpu_stacks+0xec/0xf8
[ 1056.504945] rcu_sched_clock_irq+0x274/0x6c8
[ 1056.509222] update_process_times+0x68/0x90
[ 1056.513404] tick_sched_handle.isra.16+0x50/0x64
[ 1056.518017] tick_sched_timer+0x50/0x90
[ 1056.521860] __hrtimer_run_queues+0x170/0x23c
[ 1056.526221] hrtimer_interrupt+0xb4/0x1b8
[ 1056.530233] arch_timer_handler_phys+0x38/0x50
[ 1056.534679] handle_percpu_devid_irq+0x6c/0x124
[ 1056.539209] generic_handle_irq_desc+0x10/0x18
[ 1056.543654] __handle_domain_irq+0xbc/0xc4
[ 1056.547750] gic_handle_irq+0x2c0/0x30c
[ 1056.551592] el1_irq+0xcc/0x180
[ 1056.554740] __slab_free+0x124/0x2a0
[ 1056.558319] kfree+0x218/0x238
[ 1056.561380] skb_free_head+0x38/0x3c
[ 1056.564960] skb_release_data+0x64/0xb4
[ 1056.568803] skb_release_all+0x30/0x3c
[ 1056.572550] __kfree_skb+0x20/0x34
[ 1056.575949] consume_skb+0x38/0x44
[ 1056.579349] can_receive+0x90/0xf8
[ 1056.582759] can_rcv+0xac/0xbc
[ 1056.585821] __netif_receive_skb_one_core+0x6c/0x94
[ 1056.590698] __netif_receive_skb+0x78/0x80
[ 1056.594795] process_backlog+0xac/0x15c
[ 1056.598637] net_rx_action+0x148/0x328
[ 1056.602384] __do_softirq+0x228/0x2d4
[ 1056.606049] __irq_exit_rcu+0x48/0x94
[ 1056.609712] irq_exit+0x14/0x20
[ 1056.612858] __handle_domain_irq+0xc0/0xc4
[ 1056.616954] gic_handle_irq+0x2c0/0x30c
[ 1056.620796] el1_irq+0xcc/0x180
[ 1056.623942] __schedule+0x108/0x5d0
[ 1056.627436] preempt_schedule_common+0x10/0x24
[ 1056.631880] _cond_resched+0x20/0x38
[ 1056.635459] mutex_lock+0x1c/0x44
[ 1056.638774] set_pf_worker+0x24/0x5c
[ 1056.642353] worker_thread+0x6c/0x260
[ 1056.646016] kthread+0xf0/0x100
[ 1056.649162] ret_from_fork+0x10/0x18
```
# rcu_sched
这里借助内核的文档可以理解
    * https://www.kernel.org/doc/html/v5.10/RCU/stallwarn.html

简单理解就是： 内核在每个cpu上的任务，没有任何的机会调用schedule切出，一定时间后，抛出日志以及每个cpu上监听rcu的结构体的值。

那么所有的点都可以围绕到没有办法schedule的代码语义中，这种代码语义有如下场景：
1. 禁用中断
2. 禁用buttom half
3. 禁用抢占
4. 禁用timer
5. 中断风暴

当然，文中还提到一下corner cases，其中有一个如下
* 一些rt程序的优先级被强制设置，它会干扰了rcu stall的检测线程，从而导致问题出现

本文的问题在于中断风暴。
# 分析
根据日志，初步判断堆栈可以知道如下
1. 每次都是在netrx过程的堆栈
2. softirq的计数会变
3. cpu核心不变
4. 宽限期gp序号g会变

可以知道，这并不是完全在cpu0上停滞了，而是不断的有softirq在处理，并且softirq的数量特别多，也就意味着很可能有中断风暴。 结合日志，中断风暴来自can驱动。

# 结合现象
初步定位到是中断风暴，那么简单确认系统现象可以知道复现问题的时候，can的硬件中断异常升高，百万级到千万级，ksoftirq 100% kworker 100%。所以可以直接分析can驱动的中断判断问题了。

# 代码
分析到这，直接从代码找答案即可。关键函数在netif_receive_skb，其代码路径如下
```
devm_request_irq(rockchip_can_interrupt)
    rockchip_can_err
        netif_receive_skb
```
这些就比较明朗了，问题来自can总线发送了大量的中断，中断指向了can的错误帧，接下来解析错误帧内容即可。比较重点的寄存器如下
```
#define BUS_ERR_INT     BIT(6)
#define TX_LOSTARB_INT      BIT(5)
err_code = rockchip_canfd_read(rcan, CAN_ERR_CODE);
```
这里一个值是0x20，一个是0x40。

对于TX_LOSTARB_INT其原因是总线竞争失败错误，会重新竞争。这个不是问题的原因，只能代表当前总线上负载太高了。   
对于 BUS_ERR_INT 是rx接收crc校验错误，然后发送的bus err中断，这个中断特别多，问题出现在这。

# 根本问题
通过查阅寄存器手册，和不断的打印can的state寄存器，发现芯片存在如下现象：

1. 这个can的ip在发送扩展帧时候，内部寄存器状态值在特定组合条件下，触发load失败，从而最后按标准帧而非扩展帧的格式来发送id和dlc段。
2. 这个can的ip概率性出现CRC校验错误和ID段填充位错误，导致接收方会往总线发送错误帧，由发送方进行重发。

上面两个条件一组合，并且还是在车载多域融合的情况下使用的can通信，那么整个can的通信环境就会出现大量的错误帧，设备接受到错误帧，由控制器主动发送中断，驱动获取中断状态，进而产生中断风暴。

# 解决办法
到这里，已经知道问题的根本点在于can的控制器在特定情况下触发的中断风暴，所以解决也很简单，芯片问题，驱动只能workaround，也就是屏蔽，操作如下
```
rockchip_canfd_write(rcan, CAN_INT_MASK, BUS_ERR_INT);
```
当恢复到正常传输时，再打开 BUS_ERR_INT 中断，这样能够有效的解决此问题，代码如下
```
val &= ~BUS_ERR_INT;
rockchip_canfd_write(rcan, CAN_INT_MASK, val);
```

# 原厂方案
因为芯片已经量产了，这种问题只能规避。如果需要简单有效的办法，建议可以按照上面我的操作，针对此情况屏蔽BUS_ERR_INT中断，恢复后再开启BUS_ERR_INT中断。

反馈原厂后，原厂最后解决办法是禁用软件实现的can_bus_off，通过配置寄存器的方式，重新开关can控制器，这种方法默认代码已经同步了。代码如下
```
    if (rcan->can.state >= CAN_STATE_BUS_OFF ||
        ((sta_reg & CAN_BUSOFF_FLAG) == CAN_BUSOFF_FLAG)) {
        cancel_delayed_work(&rcan->tx_err_work);
        netif_stop_queue(ndev);
        rockchip_canfd_stop(ndev);
        can_free_echo_skb(ndev, 0);
        rockchip_canfd_start(ndev);
        netif_start_queue(ndev);
    }
```
无论哪种办法，都能解决问题。

# 总结
本文通过分享了一个中断风暴带来的rcu stall日志的具体问题，最后的原因还是芯片内部的已知缺陷，通过修改寄存器屏蔽中断或者重新开关can控制器都能解决问题。

通过这个问题的实战，也可以知道，如果一个驱动/硬件可能有缺陷，根据我个人的建议最好还是想办法绑定到其他核心上，如果问题出现在cpu0，那么带来的是系统死机，而问题出现在非cpu0，一切还有挽救的机会。 
```
irq_set_affinity_hint(irq, get_cpu_mask(num_online_cpus() - 1));
```



软中断导致的死机问题

关于kasan的基本原理都分析完了，本文介绍一个常见的kasan定位的错误，相当于实战一下。
# 错误日志
此问题的日志如下
```
[    9.523897] ==================================================================
[    9.523913] BUG: KASAN: global-out-of-bounds in of_match_node+0x120/0x13c
[    9.523922] Read of size 1 at addr ffffffd00bd92908 by task swapper/0/1

[    9.523938] CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.10.198 #91
[    9.523946] Hardware name: Firefly ROC-RK3588S-PC V13 MIPI(Linux) (DT)
[    9.523953] Call trace:
[    9.523964]  dump_backtrace+0x0/0x3bc
[    9.523973]  show_stack+0x1c/0x24
[    9.523983]  dump_stack_lvl+0x130/0x168
[    9.523994]  print_address_description.constprop.0+0x74/0x2b8
[    9.524003]  kasan_report+0x1e8/0x200
[    9.524012]  __asan_report_load1_noabort+0x30/0x54
[    9.524020]  of_match_node+0x120/0x13c
[    9.524029]  of_match_device+0x44/0x80
[    9.524038]  platform_match+0xa0/0x23c
[    9.524047]  __driver_attach+0x68/0x25c
[    9.524056]  bus_for_each_dev+0x10c/0x1a0
[    9.524065]  driver_attach+0x40/0x60
[    9.524073]  bus_add_driver+0x2d4/0x540
[    9.524081]  driver_register+0x1a0/0x3d0
[    9.524089]  __platform_driver_register+0xd0/0x110
[    9.524099]  ds1820_init+0x20/0x28
[    9.524107]  do_one_initcall+0xb0/0x4e0
[    9.524118]  kernel_init_freeable+0x47c/0x4e4
[    9.524126]  kernel_init+0x18/0x13c
[    9.524134]  ret_from_fork+0x10/0x18

[    9.524146] The buggy address belongs to the variable:
[    9.524156]  of_ds1820_match+0xc8/0x260

[    9.524167] Memory state around the buggy address:
[    9.524176]  ffffffd00bd92800: 00 00 00 07 f9 f9 f9 f9 00 00 00 00 00 00 00 00
[    9.524184]  ffffffd00bd92880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    9.524191] >ffffffd00bd92900: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 03 f9 f9 f9
[    9.524197]                       ^
[    9.524204]  ffffffd00bd92980: f9 f9 f9 f9 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
[    9.524211]  ffffffd00bd92a00: 00 00 00 00 00 01 f9 f9 f9 f9 f9 f9 00 00 05 f9
[    9.524217] ==================================================================

```
可以看到，kasan检测到了一个全局变量oob的问题，此问题出现在地址ffffffd00bd92908，这个地址下毒值是0xf9，查阅《KASAN(1)-简单实践》的下毒值的对于宏可以知道这是 KASAN_GLOBAL_REDZONE ，并且此变量为of_ds1820_match变量，报错是在`of_match_node+0x120/0x13c`处发生的load/store访问从而触发了错误。

我们挑取关键信息，如下
* of_ds1820_match 变量
* of_match_node+0x120/0x13c 处

# 分析
首先我们看看 of_ds1820_match 变量的当前定义，如下
```
static const struct of_device_id of_ds1820_match[] = {
    { .compatible = "firefly,ds1820" },
};
```
似乎没看出什么问题？  

然后我们查看of_match_node函数报错的位置，如下
```
(gdb)： disassemble of_match_node
Dump of assembler code for function of_match_node:
   0xffffffd00ab4b21c <+0>:     stp     x29, x30, [sp, #-96]!
   0xffffffd00ab4b220 <+4>:     mov     x29, sp
   0xffffffd00ab4b224 <+8>:     stp     x23, x24, [sp, #48]
   0xffffffd00ab4b228 <+12>:    adrp    x24, 0xffffffd00e6a1000
   0xffffffd00ab4b22c <+16>:    add     x24, x24, #0xb00
   0xffffffd00ab4b230 <+20>:    stp     x19, x20, [sp, #16]
   0xffffffd00ab4b234 <+24>:    mov     x19, x0
   0xffffffd00ab4b238 <+28>:    mov     x0, x24
   0xffffffd00ab4b23c <+32>:    stp     x21, x22, [sp, #32]
   0xffffffd00ab4b240 <+36>:    mov     x22, x1
   0xffffffd00ab4b244 <+40>:    stp     x25, x26, [sp, #64]
   0xffffffd00ab4b248 <+44>:    stp     x27, x28, [sp, #80]
   0xffffffd00ab4b24c <+48>:    bl      0xffffffd00b7efa30 <_raw_spin_lock_irqsave>
   0xffffffd00ab4b250 <+52>:    mov     x25, x0
   0xffffffd00ab4b254 <+56>:    cbz     x19, 0xffffffd00ab4b324 <of_match_node+264>
   0xffffffd00ab4b258 <+60>:    mov     x27, #0xffd000000000            // #281268818280448
   0xffffffd00ab4b25c <+64>:    add     x21, x19, #0x40
   0xffffffd00ab4b260 <+68>:    add     x20, x19, #0x20
   0xffffffd00ab4b264 <+72>:    mov     w26, #0x0                       // #0
   0xffffffd00ab4b268 <+76>:    mov     x28, #0x0                       // #0
   0xffffffd00ab4b26c <+80>:    movk    x27, #0xdfff, lsl #48
   0xffffffd00ab4b270 <+84>:    mov     w23, #0x0                       // #0
   0xffffffd00ab4b274 <+88>:    b       0xffffffd00ab4b2a4 <of_match_node+136>
   0xffffffd00ab4b278 <+92>:    mov     x3, x19
   0xffffffd00ab4b27c <+96>:    mov     x2, x20
   0xffffffd00ab4b280 <+100>:   mov     x1, x21
   0xffffffd00ab4b284 <+104>:   mov     x0, x22
   0xffffffd00ab4b288 <+108>:   bl      0xffffffd00ab4aa50 <__of_device_is_compatible>
   0xffffffd00ab4b28c <+112>:   cmp     w0, w26
   0xffffffd00ab4b290 <+116>:   csel    x28, x28, x19, le
   0xffffffd00ab4b294 <+120>:   add     x20, x20, #0xc8
   0xffffffd00ab4b298 <+124>:   add     x21, x21, #0xc8
   0xffffffd00ab4b29c <+128>:   csel    w26, w26, w0, le
   0xffffffd00ab4b2a0 <+132>:   add     x19, x19, #0xc8
   0xffffffd00ab4b2a4 <+136>:   lsr     x0, x19, #3
   0xffffffd00ab4b2a8 <+140>:   ldrsb   w2, [x0, x27]
   0xffffffd00ab4b2ac <+144>:   cmp     w2, #0x0
   0xffffffd00ab4b2b0 <+148>:   ccmp    w23, w2, #0x1, ne  // ne = any
   0xffffffd00ab4b2b4 <+152>:   b.ge    0xffffffd00ab4b32c <of_match_node+272>  // b.tcont
   0xffffffd00ab4b2b8 <+156>:   ldrb    w0, [x19]
   0xffffffd00ab4b2bc <+160>:   lsr     x1, x20, #3
   0xffffffd00ab4b2c0 <+164>:   cbnz    w0, 0xffffffd00ab4b278 <of_match_node+92>
   0xffffffd00ab4b2c4 <+168>:   ldrsb   w1, [x1, x27]
   0xffffffd00ab4b2c8 <+172>:   cmp     w1, #0x0
   0xffffffd00ab4b2cc <+176>:   ccmp    w0, w1, #0x1, ne  // ne = any
   0xffffffd00ab4b2d0 <+180>:   b.ge    0xffffffd00ab4b338 <of_match_node+284>  // b.tcont
   0xffffffd00ab4b2d4 <+184>:   ldrb    w0, [x19, #32]
   0xffffffd00ab4b2d8 <+188>:   lsr     x1, x21, #3
   0xffffffd00ab4b2dc <+192>:   cbnz    w0, 0xffffffd00ab4b278 <of_match_node+92>
   0xffffffd00ab4b2e0 <+196>:   ldrsb   w1, [x1, x27]
   0xffffffd00ab4b2e4 <+200>:   cmp     w1, #0x0
   0xffffffd00ab4b2e8 <+204>:   ccmp    w0, w1, #0x1, ne  // ne = any
   0xffffffd00ab4b2ec <+208>:   b.ge    0xffffffd00ab4b344 <of_match_node+296>  // b.tcont
   0xffffffd00ab4b2f0 <+212>:   ldrb    w0, [x19, #64]
   0xffffffd00ab4b2f4 <+216>:   cbnz    w0, 0xffffffd00ab4b278 <of_match_node+92>
   0xffffffd00ab4b2f8 <+220>:   mov     x1, x25
   0xffffffd00ab4b2fc <+224>:   mov     x0, x24
   0xffffffd00ab4b300 <+228>:   bl      0xffffffd00b7efa90 <_raw_spin_unlock_irqrestore>
   0xffffffd00ab4b304 <+232>:   mov     x0, x28
   0xffffffd00ab4b308 <+236>:   ldp     x19, x20, [sp, #16]
   0xffffffd00ab4b30c <+240>:   ldp     x21, x22, [sp, #32]
   0xffffffd00ab4b310 <+244>:   ldp     x23, x24, [sp, #48]
   0xffffffd00ab4b314 <+248>:   ldp     x25, x26, [sp, #64]
   0xffffffd00ab4b318 <+252>:   ldp     x27, x28, [sp, #80]
   0xffffffd00ab4b31c <+256>:   ldp     x29, x30, [sp], #96
   0xffffffd00ab4b320 <+260>:   ret
   0xffffffd00ab4b324 <+264>:   mov     x28, #0x0                       // #0
   0xffffffd00ab4b328 <+268>:   b       0xffffffd00ab4b2f8 <of_match_node+220>
   0xffffffd00ab4b32c <+272>:   mov     x0, x19
   0xffffffd00ab4b330 <+276>:   bl      0xffffffd0086579c0 <__asan_report_load1_noabort>
   0xffffffd00ab4b334 <+280>:   b       0xffffffd00ab4b2b8 <of_match_node+156>
   0xffffffd00ab4b338 <+284>:   mov     x0, x20
   0xffffffd00ab4b33c <+288>:   bl      0xffffffd0086579c0 <__asan_report_load1_noabort>
   0xffffffd00ab4b340 <+292>:   b       0xffffffd00ab4b2d4 <of_match_node+184>
   0xffffffd00ab4b344 <+296>:   mov     x0, x21
   0xffffffd00ab4b348 <+300>:   bl      0xffffffd0086579c0 <__asan_report_load1_noabort>
   0xffffffd00ab4b34c <+304>:   b       0xffffffd00ab4b2f0 <of_match_node+212>
```
可以看到，0x120也就是288，这里对于了一个bl跳转，那么谁让它跳转呢，如下汇编
```
   0xffffffd00ab4b2c8 <+172>:   cmp     w1, #0x0
   0xffffffd00ab4b2cc <+176>:   ccmp    w0, w1, #0x1, ne  // ne = any
   0xffffffd00ab4b2d0 <+180>:   b.ge    0xffffffd00ab4b338 <of_match_node+284>  // b.tcont
```
这里w1和0比较，如果不等于0，则继续将w0和w1比较，并设置状态为1。

这里解释需要理解上下文，我们可以对照源码，如下
```
(gdb)： disassemble /m of_match_node
1118            for (; matches->name[0] || matches->type[0] || matches->compatible[0]; matches++) {
   0xffffffd00ab4b294 <+120>:   add     x20, x20, #0xc8
   0xffffffd00ab4b298 <+124>:   add     x21, x21, #0xc8
   0xffffffd00ab4b29c <+128>:   csel    w26, w26, w0, le
   0xffffffd00ab4b2a0 <+132>:   add     x19, x19, #0xc8
   0xffffffd00ab4b2a4 <+136>:   lsr     x0, x19, #3
   0xffffffd00ab4b2a8 <+140>:   ldrsb   w2, [x0, x27]
   0xffffffd00ab4b2ac <+144>:   cmp     w2, #0x0
   0xffffffd00ab4b2b0 <+148>:   ccmp    w23, w2, #0x1, ne  // ne = any
   0xffffffd00ab4b2b4 <+152>:   b.ge    0xffffffd00ab4b32c <of_match_node+272>  // b.tcont
   0xffffffd00ab4b2b8 <+156>:   ldrb    w0, [x19]
   0xffffffd00ab4b2bc <+160>:   lsr     x1, x20, #3
   0xffffffd00ab4b2c0 <+164>:   cbnz    w0, 0xffffffd00ab4b278 <of_match_node+92>
   0xffffffd00ab4b2c4 <+168>:   ldrsb   w1, [x1, x27]
   0xffffffd00ab4b2c8 <+172>:   cmp     w1, #0x0
   0xffffffd00ab4b2cc <+176>:   ccmp    w0, w1, #0x1, ne  // ne = any
   0xffffffd00ab4b2d0 <+180>:   b.ge    0xffffffd00ab4b338 <of_match_node+284>  // b.tcont
   0xffffffd00ab4b2d4 <+184>:   ldrb    w0, [x19, #32]
   0xffffffd00ab4b2d8 <+188>:   lsr     x1, x21, #3
   0xffffffd00ab4b2dc <+192>:   cbnz    w0, 0xffffffd00ab4b278 <of_match_node+92>
   0xffffffd00ab4b2e0 <+196>:   ldrsb   w1, [x1, x27]
   0xffffffd00ab4b2e4 <+200>:   cmp     w1, #0x0
   0xffffffd00ab4b2e8 <+204>:   ccmp    w0, w1, #0x1, ne  // ne = any
   0xffffffd00ab4b2ec <+208>:   b.ge    0xffffffd00ab4b344 <of_match_node+296>  // b.tcont
   0xffffffd00ab4b2f0 <+212>:   ldrb    w0, [x19, #64]
   0xffffffd00ab4b2f4 <+216>:   cbnz    w0, 0xffffffd00ab4b278 <of_match_node+92>
```
可以看到，就是这句c源码
```
for (; matches->name[0] || matches->type[0] || matches->compatible[0]; matches++) {
```
到这里，我们结合这两个关键信息得出的信息点，再次对比分析一下
# 综合信息
1. 全局变量
```
static const struct of_device_id of_ds1820_match[] = {
    { .compatible = "firefly,ds1820" },
};
```
2. 报错位置
```
for (; matches->name[0] || matches->type[0] || matches->compatible[0]; matches++) {
```
可以看到，这个for循环会匹配of_ds1820_match里面的值，默认从0项开始，如果name/type/compatible中但凡一个值不为0，就进入循环，然后matchs自加。

按照语义，默认`matches->compatible[0]`的值是"firefly,ds1820"，进入循环，下一次matches自加后，会逐个寻找`matches->name[1] || matches->type[1] || matches->compatible[1];`， 很明显of_ds1820_match没有第一项，所以全局变量越界。

所以，关于of_device_id的编写，我们需要一个哨兵项，这样能够在这个for循环上，遇到哨兵的时候主动退出，而不是越界访问。

所以修改代码如下
```
static const struct of_device_id of_ds1820_match[] = {
    { .compatible = "firefly,ds1820" },
    {}，
};
```
# 总结
本文以一个实际的例子介绍了kasan定位全局变量oob的问题，这个问题看起来很简单，也很不起眼。

对于编写驱动时的of_device_id的数组，是否需要哨兵的小知识点实在是微不足道了。所以才会不断的遗留在内核中一直不被发现。 

关于kasan本身，我阅读了内核大部分实现代码，可以发现其是一个不错的代码增强工具，有助于提高大家编写内核的代码质量。

KASAN(10)-实战

kasan也能够定位全局变量和栈区局部变量的oob问题，本文分析kasan如何实现全局变量和栈区变量的oob问题
# 全局变量的实现原理
关于kasan如何实现全局变量定位oob问题，我借助ppt的一页内容，如下图

![image.png](/static/img/87d88c2d9ca00f62b505510c789014d3.image.webp)

可以看到，默认情况下，对于全局变量，通过编译器插入构造器的方式插入的红区。这个不禁让我想起了《使用ASAN定位全局变量构造顺序问题》，关于全局变量构造顺序，可以转而了解此文章。本文主要说明kasan在内核上检测全局变量问题。

通过ppt的内容，我可以大概了解到其检测步骤如下
1. 为全局变量生成构造函数
2. 为全局变量按照32字节对齐
3. 多出来的字节用来下毒红区
4. 当代码触碰影子红区则报错

# 测试代码
为了演示此问题，我又贴上了一份检测全局变量的代码如下
```
static char global_array[10];

static noinline void kasan_global_oob(void)
{
    char *volatile array = global_array;
    char *p = &array[ARRAY_SIZE(global_array) + 3];
    *(volatile char *)p;

    return ;
}
```
可以看到，这里申请了10字节的全局变量，而越界的地方是第13个字节，所以相关日志如下
```
[   10.447271] Memory state around the buggy address:
[   10.447326]  ffffffd00ea7ca00: 04 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
[   10.447382]  ffffffd00ea7ca80: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
[   10.447438] >ffffffd00ea7cb00: f9 f9 f9 f9 f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9
[   10.447484]                                               ^
[   10.447539]  ffffffd00ea7cb80: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9
[   10.447595]  ffffffd00ea7cc00: 00 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
```
因为ppt中提到是编译器的指令插桩，根据c语言全局变量的构造概念，我们可以反汇编o文件，从o文件中找答案(参考 《使用ASAN定位全局变量构造顺序问题》)，结果如下
```
# objdump -d lib/test_kasan_kylin.o
Disassembly of section .text.exit:

0000000000000000 <_sub_D_65535_0>:
   0:   a9bf7bfd        stp     x29, x30, [sp, #-16]!
   4:   90000000        adrp    x0, 0 <_sub_D_65535_0>
   8:   91000000        add     x0, x0, #0x0
   c:   910003fd        mov     x29, sp
  10:   91004000        add     x0, x0, #0x10
  14:   d2800041        mov     x1, #0x2                        // #2
  18:   94000000        bl      0 <__asan_unregister_globals>
  1c:   a8c17bfd        ldp     x29, x30, [sp], #16
  20:   d65f03c0        ret

Disassembly of section .text.startup:

0000000000000000 <_sub_I_65535_1>:
   0:   a9bf7bfd        stp     x29, x30, [sp, #-16]!
   4:   90000000        adrp    x0, 0 <_sub_I_65535_1>
   8:   91000000        add     x0, x0, #0x0
   c:   910003fd        mov     x29, sp
  10:   91004000        add     x0, x0, #0x10
  14:   d2800041        mov     x1, #0x2                        // #2
  18:   94000000        bl      0 <__asan_register_globals>
  1c:   a8c17bfd        ldp     x29, x30, [sp], #16
  20:   d65f03c0        ret
```
可以看到，和标准c语言的全局变量一致，默认会在o文件生成构造函数，其构造调用`__asan_register_globals`，析构调用`__asan_unregister_globals`，我们翻阅一下内核代码，分析一下
# 全局变量下毒
首先分析代码流程如下
```
__asan_register_globals
    register_global
```
这里重点函数是`register_global`，代码如下
```
static void register_global(struct kasan_global *global)
{
    size_t aligned_size = round_up(global->size, KASAN_GRANULE_SIZE);

    kasan_unpoison(global->beg, global->size, false);

    kasan_poison(global->beg + aligned_size,
             global->size_with_redzone - aligned_size,
             KASAN_GLOBAL_REDZONE, false);
}
```
这个函数有如下几个重要信息
* 被编译器生成的结构体struct kasan_global
* 先对global->beg到global->beg+global->size区域解毒为0
* 再将global->beg + aligned_size到global->size_with_redzone - aligned_size下毒为0xf9

所以一切重要的事情都在于结构体`struct kasan_global`，翻阅代码，其定义如下
```
struct kasan_global {
    const void *beg;        /* Address of the beginning of the global variable. */
    size_t size;            /* Size of the global variable. */
    size_t size_with_redzone;   /* Size of the variable + size of the red zone. 32 bytes aligned */
    const void *name;
    const void *module_name;    /* Name of the module where the global variable is declared. */
    unsigned long has_dynamic_init; /* This needed for C++ */
#if KASAN_ABI_VERSION >= 4
    struct kasan_source_location *location;
#endif
#if KASAN_ABI_VERSION >= 5
    char *odr_indicator;
#endif
};
```
这个注释还是非常详细的，我逐个解释一下
1. beg: 全局变量地址
2. size: 全局变量大小
3. size_with_redzone: 加上红区的大小
4. name: 全局变量名字
5. module_name: 对于文件名字
6. location: 结构体kasan_source_location指针

这里还需要kasan_source_location结构体，其定义如下
```
struct kasan_source_location {
    const char *filename;
    int line_no;
    int column_no;
};
```
这个更显而易见了，如下
1. 文件名
2. 行号
3. 列号

再根据kasan的报错堆栈，我们知道这个全局变量的地址是`ffffffd00ea7cb40`.

结合上面所有的信息，那么可以在编译器插桩的函数上加上一句打印，从而打印这个kasan_global结构体指针，打印如下
```
# git diff mm/kasan/generic.c
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index 53cbf28859b5..2a7e4d8ac0f7 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -219,6 +219,10 @@ void __asan_register_globals(struct kasan_global *globals, size_t size)
 {
        int i;

+    if(globals->beg == (void *)0xffffffd00ea7cb40) {
+        printk("tf: kasan_global=%px \n", globals);
+    }
+
        for (i = 0; i < size; i++)
                register_global(&globals[i]);
 }
```
此时重编译内核，运行得到日志如下
```
[    6.335641] tf: kasan_global= ffffffd00e0b60e0
```
我们拿到了这个kasan_global结构体指针，借助crash可以打印信息如下
```
crash> struct kasan_global 0xffffffd00e0b60e0
struct kasan_global {
  beg = 0xffffffd00ea7cb40 <global_array>, 
  size = 10, 
  size_with_redzone = 64, 
  name = 0xffffffd00c607110, 
  module_name = 0xffffffd00c6070f8, 
  has_dynamic_init = 0, 
  location = 0xffffffd00e0b60d0, 
  odr_indicator = 0x0
}
```
再打印location，如下
```
crash> struct kasan_source_location 0xffffffd00e0b60d0
struct kasan_source_location {
  filename = 0xffffffd00c6070f8 "lib/test_kasan_kylin.c", 
  line_no = 16, 
  column_no = 13
}
```
# 栈区变量实现原理
这里还是根据ppt的文档解析，如下

![image.png](/static/img/1cc1e00ee16932d8d4127255d665f798.image.webp)

根据文档，可以知道默认栈分配的变量，编译器在编译的时候会直接插入红区变量，然后根据整体栈的布局设置红区内容。

所以根据ppt的内容，这部分工作量全部在编译器，无需代码实现。

# 局部变量下毒
我们知道局部变量都是编译器做的，那么解析这个步骤就可以直接反汇编即可，这里还是利用上面的测试代码，反汇编kasan_global_oob函数，如下
```
crash> dis kasan_global_oob
0xffffffd0094d0de0 <kasan_global_oob>:	stp	x29, x30, [sp,#-96]!
0xffffffd0094d0de4 <kasan_global_oob+4>:	mov	x1, #0xffd000000000     
   	// #281268818280448
0xffffffd0094d0de8 <kasan_global_oob+8>:	movk	x1, #0xdfff, lsl #48
0xffffffd0094d0dec <kasan_global_oob+12>:	add	x0, sp, #0x20
0xffffffd0094d0df0 <kasan_global_oob+16>:	mov	x29, sp
0xffffffd0094d0df4 <kasan_global_oob+20>:	mov	x5, #0x8ab3             
   	// #35507
0xffffffd0094d0df8 <kasan_global_oob+24>:	stp	x19, x20, [sp,#16]
0xffffffd0094d0dfc <kasan_global_oob+28>:	lsr	x19, x0, #3
0xffffffd0094d0e00 <kasan_global_oob+32>:	add	x4, x19, x1
0xffffffd0094d0e04 <kasan_global_oob+36>:	adrp	x3, 0xffffffd00c607000
0xffffffd0094d0e08 <kasan_global_oob+40>:	adrp	x2, 0xffffffd0094d0000 <
kstrtos16_from_user+416>
0xffffffd0094d0e0c <kasan_global_oob+44>:	add	x3, x3, #0xe0
0xffffffd0094d0e10 <kasan_global_oob+48>:	add	x2, x2, #0xde0
0xffffffd0094d0e14 <kasan_global_oob+52>:	movk	x5, #0x41b5, lsl #16
0xffffffd0094d0e18 <kasan_global_oob+56>:	stp	x5, x3, [sp,#32]
0xffffffd0094d0e1c <kasan_global_oob+60>:	mov	w3, #0xf1f1f1f1         
   	// #-235802127
0xffffffd0094d0e20 <kasan_global_oob+64>:	str	x2, [sp,#48]
0xffffffd0094d0e24 <kasan_global_oob+68>:	mov	w2, #0xf300             
   	// #62208
0xffffffd0094d0e28 <kasan_global_oob+72>:	str	w3, [x19,x1]
0xffffffd0094d0e2c <kasan_global_oob+76>:	movk	w2, #0xf3f3, lsl #16
0xffffffd0094d0e30 <kasan_global_oob+80>:	str	w2, [x4,#4]
0xffffffd0094d0e34 <kasan_global_oob+84>:	adrp	x0, 0xffffffd00ea7c000 <
bounce_bio_set+192>
0xffffffd0094d0e38 <kasan_global_oob+88>:	add	x0, x0, #0xb40
0xffffffd0094d0e3c <kasan_global_oob+92>:	str	x0, [sp,#64]
0xffffffd0094d0e40 <kasan_global_oob+96>:	ldr	x20, [sp,#64]
0xffffffd0094d0e44 <kasan_global_oob+100>:	add	x0, x20, #0xd
0xffffffd0094d0e48 <kasan_global_oob+104>:	and	w2, w0, #0x7
0xffffffd0094d0e4c <kasan_global_oob+108>:	lsr	x3, x0, #3
0xffffffd0094d0e50 <kasan_global_oob+112>:	ldrsb	w1, [x3,x1]
0xffffffd0094d0e54 <kasan_global_oob+116>:	cmp	w1, #0x0
0xffffffd0094d0e58 <kasan_global_oob+120>:	ccmp	w2, w1, #0x1, ne
0xffffffd0094d0e5c <kasan_global_oob+124>:	b.ge	0xffffffd0094d0e7c <kasa
n_global_oob+156>
0xffffffd0094d0e60 <kasan_global_oob+128>:	mov	x0, #0xffd000000000     
   	// #281268818280448
0xffffffd0094d0e64 <kasan_global_oob+132>:	ldrb	w1, [x20,#13]
0xffffffd0094d0e68 <kasan_global_oob+136>:	movk	x0, #0xdfff, lsl #48
0xffffffd0094d0e6c <kasan_global_oob+140>:	str	xzr, [x19,x0]
0xffffffd0094d0e70 <kasan_global_oob+144>:	ldp	x19, x20, [sp,#16]
0xffffffd0094d0e74 <kasan_global_oob+148>:	ldp	x29, x30, [sp],#96
0xffffffd0094d0e78 <kasan_global_oob+152>:	ret
0xffffffd0094d0e7c <kasan_global_oob+156>:	bl	0xffffffd0086579c0 <__as
an_report_load1_noabort>
0xffffffd0094d0e80 <kasan_global_oob+160>:	b	0xffffffd0094d0e60 <kasa
n_global_oob+128>
```
这里关于load/store插桩的汇编我们可以跳过分析，已经在《KASAN(4)-INLINE插桩分析》介绍过了，我们只关心栈区如何设置红区的。主要步骤如下
1. 整个栈大小96字节
2. 设置shadow offset
3. 分配32字节作为栈左
4. 获取影子内存地址
5. 下毒栈左影子值
6. 下毒可访问区
7. 下毒栈右

上面关于汇编的分析同时也忽略了全局变量判断oob的指令。可以看到，通过汇编可以知道其在栈上的前32字节下毒了0xf1，中间8字节是可访问区域，栈后面24字节作为栈右下毒0xf3。组合起来的值是`f1 f1 f1 f1 00 f3 f3 f3`

# 总结
到这里，全局变量和局部变量的下毒流程已经分析完毕了。

对于全局变量，其依赖gcc给代码插桩，默认让所有的全局变量执行构造函数，而这个构造函数固定名字为`__asan_register_globals`，同时初始化了结构体`kasan_global`用于传递这个全局变量的基本信息。在内核中需要实现`__asan_register_globals`这个钩子，并正常给影子内存下毒。当下次load/store访问变量的时候，继续由插桩指令判断影子内存。从而判断访问是否oob。

对于局部变量，其全部来自gcc插桩，对栈区访问的变量进行栈左和栈右的预留栈区和下毒。当下次load/store访问变量的时候，继续由插桩指令判断影子内存。从而判断访问是否oob。

# 参考文档
谷歌三篇关于asan的文章讲解还是比较权威的，可以阅读一下
> https://docs.google.com/presentation/d/10V_msbtEap9dNerKvTrRAzvfzYdrQFC8e2NYHCZYJDE/edit?slide=id.g8b31c59a9b_0_0#slide=id.g8b31c59a9b_0_0   
> https://docs.google.com/presentation/d/1IpICtHR1T3oHka858cx1dSNRu2XcT79-RCRPgzCuiRk/edit?slide=id.gee201659dd_0_308#slide=id.gee201659dd_0_308   
> https://docs.google.com/presentation/d/1qA8fqRDHKX_WM_ZdDN37EQQZwSTNJ4FFws82tbUSKxY/edit?pli=1&slide=id.g154fcb2683b_1_151#slide=id.g154fcb2683b_1_151   

KASAN(9)-全局变量和栈变量的实现

在《KASAN(7)-基于slab的实现》中已经分析了slab的情况了，但是还有一部分情况是基于buddy系统的，kasan在buddy上的实现是比较特殊的，本文分析伙伴系统下的kasan实现。
# initail buddy
初始化伙伴系统的时候系统中未占用的内存全部调用buddy系统的free接口初始化，初始化代码流程如下
```
start_kernel
    mm_init
        mem_init
            memblock_free_all
                free_low_memory_core_early
                    __free_memory_core
                        __free_pages_memory
                            memblock_free_pages
                                __free_pages_core
                                    __free_pages_ok
                                        free_pages_prepare
                                            kernel_poison_pages
                                            
```
如下代码可以看到`kernel_poison_pages`的代码实现依赖于CONFIG_PAGE_POISONING，此配置用于代表是否对page下毒，如下
```
#ifdef CONFIG_PAGE_POISONING
static inline bool page_poisoning_enabled_static(void)
{
    return static_branch_unlikely(&_page_poisoning_enabled);
}
static inline void kernel_poison_pages(struct page *page, int numpages)
{
    if (page_poisoning_enabled_static())
        __kernel_poison_pages(page, numpages);
}
#else
static inline bool page_poisoning_enabled_static(void) { return false; }
static inline void kernel_poison_pages(struct page *page, int numpages) { }
static inline void kernel_unpoison_pages(struct page *page, int numpages) { }
#endif
```
比较遗憾的是，我的设备并没有打开CONFIG_PAGE_POISONING，所以默认情况下buddy系统的影子区域并不会下毒，而且根据之前的分析，我们知道默认影子的值是0(KASAN_SHADOW_INIT=0)，所以可以得到结论，对于buddy系统初始化过程中没有下毒。

关于这点分析，其实从测试用例中已经得到解释了，如下
```
static void pagealloc_oob_right(struct kunit *test)
{
    char *ptr;
    struct page *pages;
    size_t order = 4;
    size_t size = (1UL << (PAGE_SHIFT + order));

    /*
     * With generic KASAN page allocations have no redzones, thus
     * out-of-bounds detection is not guaranteed.
     * See https://bugzilla.kernel.org/show_bug.cgi?id=210503.
     */
    KASAN_TEST_NEEDS_CONFIG_OFF(test, CONFIG_KASAN_GENERIC);

    pages = alloc_pages(GFP_KERNEL, order);
    ptr = page_address(pages);
    KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);

    KUNIT_EXPECT_KASAN_FAIL(test, ptr[size] = 0);
    free_pages((unsigned long)ptr, order);
}
```
# alloc_pages
根据分析，CONFIG_KASAN_GENERIC下的kasan是不能检测buddy的oob问题的，那么是不是sw-tag/hw-tag能够检测呢。我们还是继续分析，alloc_page代码流程
```
alloc_pages
    alloc_pages_current
        __alloc_pages_nodemask
            get_page_from_freelist
                prep_new_page
                    post_alloc_hook
                        kasan_alloc_pages
```
我们查看kasan_alloc_pages的实现，如下
```
#ifdef CONFIG_KASAN_HW_TAGS

void kasan_alloc_pages(struct page *page, unsigned int order, gfp_t flags);
void kasan_free_pages(struct page *page, unsigned int order);

#else /* CONFIG_KASAN_HW_TAGS */

static __always_inline void kasan_alloc_pages(struct page *page,
                          unsigned int order, gfp_t flags)
{
    /* Only available for integrated init. */
    BUILD_BUG();
}

static __always_inline void kasan_free_pages(struct page *page,
                         unsigned int order)
{
    /* Only available for integrated init. */
    BUILD_BUG();
}

#endif /* CONFIG_KASAN_HW_TAGS */
```
也就是如果是HW_TAGS下的kasan是支持在伙伴系统内下毒的，由于本机器不支持hw tags，接下来就不做分析了。

那么总结一下就是，默认内核提供了 CONFIG_PAGE_POISONING 调试接口给伙伴系统的所有页面进行下毒，但此配置默认不开，所以伙伴系统初始化之后其影子页面是值为0的页面，再者通过alloc_pages调用下的页面，只有是 CONFIG_KASAN_HW_TAGS 才提供标记值来下毒，而我的设备是 CONFIG_KASAN_GENERIC 的配置，所以alloc_pages下的内存，kasan相当于什么也没做。也就意味着 **CONFIG_KASAN_GENERIC 下的伙伴系统，kasan无法检测其oob问题**。
# free_pages
除了oob问题，还有uaf的问题，所以关于free_pages还是需要分析，首先基于代码流程分析，如下
```
free_pages
    __free_pages
        free_the_page
            __free_pages_ok
                free_pages_prepare
```
这里有段逻辑，如下
```
static inline bool kasan_has_integrated_init(void)
{
    return kasan_hw_tags_enabled();
}
---------------------------------------------------
    if (kasan_has_integrated_init()) {
        if (!skip_kasan_poison)
            kasan_free_pages(page, order);
    } else {
        bool init = want_init_on_free();

        if (init)
            kernel_init_free_pages(page, 1 << order, false);
        if (!skip_kasan_poison)
            kasan_poison_pages(page, order, init);
    }
```
其逻辑解析如下
1. 如果是hw tags，则调用kasan_free_pages
2. 如果不是hw tags，内核配置了init_on_free，那么free时会清空页面
3. 默认调用kasan_poison_pages

我们查看kasan_poison_pages的代码如下
```
static __always_inline void kasan_poison_pages(struct page *page,
                        unsigned int order, bool init)
{
    if (kasan_enabled())
        __kasan_poison_pages(page, order, init);
}
void __kasan_poison_pages(struct page *page, unsigned int order, bool init)
{
    if (likely(!PageHighMem(page)))
        kasan_poison(page_address(page), PAGE_SIZE << order,
                 KASAN_FREE_PAGE, init);
}
```
可以看到，虽然kasan在伙伴系统alloc的时候什么也没有做，但是在free的时候还是下毒成了KASAN_FREE_PAGE，也就是0xff， 这也就意味着，在 CONFIG_KASAN_GENERIC 下kasan可以检测 伙伴系统的uaf问题。

我们可以根据《KASAN(3)-测试分析》的`pagealloc api test uaf`章节的日志分析，如下
```
[ 5510.618665] BUG: KASAN: use-after-free in pagealloc_uaf+0xb4/0xcc [test_kasan_kylin]
[ 5510.618679] Write of size 1 at addr ffffff80a4080000 by task insmod/3253
[ 5510.619044] page:000000009a7015d6 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0xa4080
[ 5510.619058] flags: 0x0()
[ 5510.619133]  ffffff80a407ff00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5510.619146]  ffffff80a407ff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5510.619159] >ffffff80a4080000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5510.619170]                    ^
[ 5510.619183]  ffffff80a4080080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5510.619196]  ffffff80a4080100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
```
可以看到，伙伴系统下的页面，如果被free后，会设置值为0xff，其目的是检测伙伴系统下的uaf问题
# 总结
本文介绍了伙伴系统下的kasan实现，由于本文主要讨论是 CONFIG_KASAN_GENERIC 下的kasan，所以伙伴系统初始化的情况下，并没有下毒，并且在调用alloc_pages时，也没有下毒，所以 CONFIG_KASAN_GENERIC 下的kasan无法检测伙伴系统的oob问题，但是kasan会在free_pages时下毒，所以 CONFIG_KASAN_GENERIC 下的kasan还是能够检测uaf的问题的。



