最近在调试一个关于OpenVPN的程序，由于是远程支持的因此一些很奇怪的现象根本不好找切入点，比如OpenVPN客户端连接服务器正常，虚拟IP地址也已经分配了，tap设备已经打开并没有抱错，然而打开的tap设备不是tap0而是" "，也就是什么都没有，连个空格都不是，这是怎么回事呢？
为了问题简化，将引起问题的代码从OpenVPN中切出来，得到一个纯粹打开tap设备的代码：
int main(int argc, char *argv[])
{
struct ifreq ifr;
int fd, err;
char *clonedev = "/dev/net/tun";
if( (fd = open(clonedev , O_RDWR)) < 0 ) {
perror("Opening /dev/net/tun");
return fd;
}
memset(&ifr, 0, sizeof(ifr));
ifr.ifr_flags |= IFF_TUN;//或者IFF_TAP
printf("1:%s\n", ifr.ifr_name);
if( (err = ioctl(fd, TUNSETIFF, &ifr)) < 0 ) {
perror("ioctl(TUNSETIFF)");
close(fd);
return err;
}
printf("2:%s\n", ifr.ifr_name);
return fd;
}
编译为test执行后，发现第二次打印出"tun0"，正常，然后将此程序拷贝给远程的问题机器，却没有打印"tun0"。很多奇怪的问题都和系统相关，于是问到了对方的系统版本，由uname -a得到，发现其实它是一个64位的系统，于是安装了一个64位的Red Hat，版本是：2.6.9-78.EL x86_64 GNU/Linux。运行的test是一个在32位系统上编译的程序。由于linux的64位内核对32位程序提供了兼容服务，且x86-64体系也对32位的指令集和寄存器提供了最底层的兼容，想象而言不该出此问题的，在64位系统上检查到了/lib/libc以及/lib/ld-linux等32位的系统库和链接器就更加坚定了“问题不该有”的观念--64位系统兼容32位程序的简单性需要N多层次的支持，机器指令兼容了，操作系统层和编译器就不必再操心指令，操作系统只需要提供系统服务的兼容即可，编译器几乎什么都不需要做，再往上就是系统库了，比如glibc就需要提供两套，为32位程序和64位程序分别提供服务。然而虽然“问题不该有”，事实是问题确实出现了，机器指令是兼容的，操作系统也是兼容的，而系统中确实也有两套libc和ld，那么问题出在哪里呢？
十有八九是tun的驱动有问题，于是在drivers/net/tun.c的tun_chr_ioctl这个字符设备的ioctl函数中加入dump_stack()调用，编译之，insmod之，然后再次执行test，通过dmesg查看日志，以下是Call Trace：
<ffffffffa02c65b9>{:tun:tun_chr_ioctl+0} <ffffffffa02c65dd>{:tun:tun_chr_ioctl+36}
<ffffffff8019c341>{chrdev_open+952} <ffffffff801a7c86>{sys_ioctl+1006}
<ffffffff8012b355>{dev_ifsioc+228} <ffffffff801c65a4>{compat_sys_ioctl+379}
<ffffffff801279f7>{sysenter_do_call+27}
其中有一个dev_ifsioc很令人好奇，难道执行流不是通过sys_ioctl直接路由到tun_chr_ioctl的吗？为何还要有一个dev_ifsioc？最后只好看2.6.9内核的代码了。
搜索到了以下一行：
HANDLE_IOCTL(TUNSETIFF, dev_ifsioc)
HANDLE_IOCTL的定义：
#define HANDLE_IOCTL(cmd,handler) { (cmd), (ioctl_trans_handler_t)(handler) },
这明明是想构造一个ioctl_trans数组：
struct ioctl_trans {
unsigned long cmd;
ioctl_trans_handler_t handler;
struct ioctl_trans *next;
};
这个数组提供了内核层次系统调用的64位向32位的兼容性，整个系统所有需要提供兼容性的系统调用都会注册一个ioctl_trans，由此可见dev_ifsioc实际处理了TUNSETIFF这个ioctl命令。64位上的32位程序发起的ioctl系统调用被操作系统路由到了compat_sys_ioctl(具体原因一会儿说)：
asmlinkage long compat_sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
{
...
t = ioctl32_hash_table[ioctl32_hash (cmd)];
while (t && t->cmd != cmd)
t = t->next;
if (t) {
if (t->handler) {
lock_kernel();
error = t->handler(fd, cmd, arg, filp); //对于TUNSETIFF而言，这里调用dev_ifsioc
unlock_kernel();
up_read(&ioctl32_sem);
} else {
up_read(&ioctl32_sem);
error = sys_ioctl(fd, cmd, arg);
}
}
...
}
dev_ifsioc的实现如下，它只要提供“兼容性”服务，比如统一64位和32位的数据类型等：
static int dev_ifsioc(unsigned int fd, unsigned int cmd, unsigned long arg)
{
struct ifreq ifr;
struct ifreq32 __user *uifr32;
...
mm_segment_t old_fs;
int err;
uifr32 = compat_ptr(arg); //转换64位的unsigned long数据类型到32位的地址
...
switch (cmd) {
case SIOCSIFMAP:
...//不是我们关注的TUNSETIFF
default: //对于TUNSETIFF，掉入了default，顺利从uifr32所代表的32位地址处拷贝了ifr结构到内核
if (copy_from_user(&ifr, uifr32, sizeof(*uifr32)))
return -EFAULT;
break;
}
old_fs = get_fs();
set_fs (KERNEL_DS);
err = sys_ioctl (fd, cmd, (unsigned long)&ifr); //1
set_fs (old_fs);
if (!err) {
switch (cmd) { //后面的case明显没有TUNSETIFF
case SIOCGIFFLAGS:
case SIOCGIFMETRIC:
case SIOCGIFMTU:
case SIOCGIFMEM:
case SIOCGIFHWADDR:
case SIOCGIFINDEX:
case SIOCGIFADDR:
case SIOCGIFBRDADDR:
case SIOCGIFDSTADDR:
case SIOCGIFNETMASK:
case SIOCGIFTXQLEN:
if (copy_to_user(uifr32, &ifr, sizeof(*uifr32)))
return -EFAULT;
break;
case SIOCGIFMAP:
...//不是我们关注的TUNSETIFF
}
}
return err;
}
注意“1”处的sys_ioctl调用使用的ifr的地址调用sys_ioctl，而ifr的地址显然只是一个中间变量，它存储在发起系统调用的进程的内核栈上，明显是一个内核栈地址，由此可见，即使sys_ioctl将执行流路由到了tun_chr_ioctl，而tun_chr_ioctl正确地将信息拷贝到了它的参数arg，数据也仅仅填充到了内核栈上，而不是真正的用户进程的地址。如果需要真正将数据拷贝到用户进程空间，我们需要在后面的switch中加一个case，这个case即TUNSETIFF，这样结果就正确了。这明显是一个内核的bug，不知道哪个家伙加了HANDLE_IOCTL(TUNSETIFF, dev_ifsioc)这么一行，却忘记了在dev_ifsioc中处理TUNSETIFF，这几乎可以肯定不是一个人加的，有时间翻一下patchs确认一下。