用 mmap 将某些 struct 存放到文件中 (map virtual memory to a file)

背景

在 RHEL7 中, dovecot 在运行的过程中其中一个 imap 进程挂掉,出来这么一个 coredump.

Program terminated with signal 7, Bus error.

(gdb) f 0
#0  0x00007fbb15868c17 in mail_cache_transaction_open_if_needed (ctx=ctx@entry=0x7fbb173c1430)
    at mail-cache-transaction.c:218
218				if (ext->reset_id == cache->hdr->file_seq || i == 2)

(gdb) p cache
$1 = (struct mail_cache *) 0x7fbb173af2d0

(gdb) p cache->hdr
$3 = (const struct mail_cache_header *) 0x7fbb15ce5000

(gdb) p cache->hdr->file_seq
Cannot access memory at address 0x7fbb15ce5008

# cat maps | grep 7fbb15ce5000
7fbb15ce5000-7fbb15ced000 r--s 00000000 00:2c xxxxxxxxx    /xxxxxxx/dovecot.index.cache

挂掉的原因是 "signal 7, bus error" ((bad memory access)). 从 gdb 中可以看到,进程挂的时候在尝试访问 ext->reset_id 和 cache->hdr->file_seq, 而从 maps 可以看出 cache->hdr 指向的是 file-backend 的地址空间。

那么问题来了,怎样可以把一个结构体,映射到一个文件,而不是匿名页?另外一个问题是,在 gdb 中看到 “Cannot access memory at address” 是意味着这段地址存在问题吗?

测试环境

Debian 8 - jessie
继续阅读“用 mmap 将某些 struct 存放到文件中 (map virtual memory to a file)”

Linux Kernel 的双向链表实现

在一个太阳毒辣的周五,刚到公司的我还没吃完手里的面包,肯尼斯把我抓到他的屏幕前:“你来说说这段代码什么意思。”

#define container_of(ptr, type, member) ({                      \
        const typeof( ((type *)0)->member ) *__mptr = (ptr);    \
        (type *)( (char *)__mptr - offsetof(type,member) );})

我凝视屏幕一分钟,问道:“这...有注释吗?”
见状,肯尼斯渐渐露出笑容。我仿佛从肯尼斯的笑脸中,看到了下一分钟认怂的我。

一分钟后,肯尼斯从 Kernel 的双向链表给我讲起...

测试环境

下面的 Kernel 源码以及测试环境均为 RHEL7.3:
kernel-3.10.0-514.el7.x86_64
gcc-4.8.5-11.el7.x86_64
继续阅读“Linux Kernel 的双向链表实现”

为什么不同的 LC_ALL 设定会导致 sort 命令输出顺序不一样?

在使用 sort 命令对文本进行排序时,如果语言环境不同,得到的排序结果也会不同。

[root@rhel674 tmp]# export LC_ALL=C; sort test.txt 
1234
AAA
BBB
aaa
aab

[root@rhel674 tmp]# export LC_ALL=en_US; sort test.txt 
1234
aaa
AAA
aab
BBB

如果用 C (POSIX) 作为语言环境,得到的排序结果是按照字符对应的 ascii 码大小来排序的。而如果用 en_US 等语言环境,得到的排序结果会不同(从上可以看到,先按字母顺序排序,字母都一样的时候才区分大小写)。
继续阅读“为什么不同的 LC_ALL 设定会导致 sort 命令输出顺序不一样?”

比较 kdump makedumpfile 中的压缩方法

背景

在出现 Kernel Panic 的时候,kdump 可以帮助我们收集 vmcore, 以便后续对故障原因进行分析。然而,近些年的服务器动辄上百G的内存,转储一个 vmcore 所耗费的时间显得相对较长,增加了 down time.

在 RHEL7/CentOS7 中, kdump 提供了三种压缩方法(zlib, lzo, snappy),我们可以选择一种较快速的压缩方法来节省收集 vmcore 的时间。

压缩方法可以在 kdump.conf 中的 makedumpfile 一行里设置。

# man makedumpfile

-c,-l,-p
  Compress dump data by each page using zlib for -c option, lzo for -l option or snappy for -p option.  (-l option needs USELZO=on and -p option needs USESNAPPY=on when building)
  A user cannot specify this option with -E option, because the ELF format does not support compressed data.
  Example:
  # makedumpfile -c -d 31 -x vmlinux /proc/vmcore dumpfile

zlib 是 gzip 所使用的压缩方法,通常而言它比 lzo 和 snappy 慢,而压缩比稍微高于 lzo 和 snappy.
继续阅读“比较 kdump makedumpfile 中的压缩方法”