Home Linux Linux中的PIPE_SIZE与PIPE_BUF,管道最大写入值问题

    简单来说,在Linux下,pipe的PIPE_BUF长度限制了它在原子操作中一次写入的大小,为4096字节。而PIPE_SIZE则限制了pipe缓冲区的最大长度,为64K=65536字节。在使用write()向pipe中写入数据时,若写入长度小于4096字节,则此次写入动作为原子操作,否则会分批写入。若write()的字节数大于了pipe中空闲空间大小,则write()会被阻塞,直到pipe中的数据被读取出去。当然也可以设置为非阻塞模式,此时write()则会返回-1,errno被置为EAGAIN错误。以下是转载的一篇。

现在开发的项目是从solaris到linux的应用移植。经常用到popen函数,使用8192字节的数组读取popen输出,但没有进行溢出判断。

刚开始认为是一个简单的内存越界,但对popen和PIPE调查以后,疑惑越来越多了。

1)问题的引出

popen使用管道来记录被调用命令的输出,那么popen的最大写入字节数必然是管道的最大值。

使用linux的ulimit -a来查看系统限制:

  1. [syscom@sysbase0-0 linux]$ ulimit -a  
  2. core file size          (blocks, -c) 0  
  3. data seg size           (kbytes, -d) unlimited  
  4. scheduling priority             (-e) 0  
  5. file size               (blocks, -f) unlimited  
  6. pending signals                 (-i) 16204  
  7. max locked memory       (kbytes, -l) 64  
  8. max memory size         (kbytes, -m) unlimited  
  9. open files                      (-n) 1024  
  10. pipe size            (512 bytes, -p) 8  
  11. POSIX message queues     (bytes, -q) 819200  
  12. real-time priority              (-r) 0  
  13. stack size              (kbytes, -s) 8192  
  14. cpu time               (seconds, -t) unlimited  
  15. max user processes              (-u) 1024  
  16. virtual memory          (kbytes, -v) unlimited  
  17. file locks                      (-x) unlimited  

查看solaris的系统限制:

  1. bash-3.00$ ulimit -a  
  2. core file size        (blocks, -c) unlimited  
  3. data seg size         (kbytes, -d) unlimited  
  4. file size             (blocks, -f) unlimited  
  5. open files                    (-n) 256  
  6. pipe size          (512 bytes, -p) 10  
  7. stack size            (kbytes, -s) 8192  
  8. cpu time             (seconds, -t) unlimited  
  9. max user processes            (-u) 29995  
  10. virtual memory        (kbytes, -v) unlimited  

可以看到在linux系统上pipe size 为512bytes * 8= 4096bytes。solaris系统上pipe size为512bytes * 10= 5120bytes。

无论是4096还是5120都是远远小于8912的。因此使用8912字节的buf来读取popen的输出时绝对不会出现内存越界问题了。

2)问题的深入

通过ulimit看似得到了正确的结果,但在实际测试中却让人大跌眼镜!

测试程序:

test_popen.c

  1. #include<stdio.h>  
  2. int main()  
  3. {  
  4.     FILE        *fp;  
  5.     int i;  
  6.     char        *p;  
  7.     char        buf[128];  
  8.     fp = popen(“./test_print”, “r”);  
  9.     if(fp ==NULL) {  
  10.         printf(“NG\n”);  
  11.         return -1;  
  12.     }  
  13.     fgets(buf, 128, fp);  
  14.     pclose(fp);  
  15.     return 0;  
  16. }  

test_print.c

  1. #include <stdio.h>  
  2. int main()  
  3. {  
  4.     unsigned int i;  
  5.     for(i=0; i<0xffffffff;i++)  
  6.         printf(“a”);  
  7.     return 0;  
  8. }  



将test_popen.c 和test_print.c分别编译为test_popen和test_print,运行test_popen,程序竟然正常运行!test_print明明输出了4G的字符啊

3)探究原理。

通过man 7 pipe来理解PIPE(我的man版本是1.6f)

  1. PIPE_BUF  
  2.       POSIX.1-2001 says that write(2)s of less than PIPE_BUF  bytes  must  be  
  3.       atomic:  the  output  data  is  written  to  the  pipe  as a contiguous  
  4.       sequence.  Writes of more than PIPE_BUF bytes may  be  non-atomic:  the  
  5.       kernel  may  interleave  the data with data written by other processes.  
  6.       POSIX.1-2001 requires PIPE_BUF to be at least 512  bytes.   (On  Linux,  
  7.       PIPE_BUF  is  4096 bytes.)  The precise semantics depend on whether the  
  8.       file descriptor is non-blocking (O_NONBLOCK), whether there are  multi-  
  9.       ple writers to the pipe, and on n, the number of bytes to be written:  



PIPE_BUF确实为4096,但PIPE_BUF是指原子写的最大值,4kb刚好是1page size,并不是指PIPE SIZE

在谷歌上搜索内核源码,在3.10的内核中有如下:

133 /* Differs from PIPE_BUF in that PIPE_SIZE is the length of the actual 
134    memory allocation, whereas PIPE_BUF makes atomicity guarantees.  */  
135 #define PIPE_SIZE               PAGE_SIZE  
明确说明了PIPE_BUF和PIPE_SIZE的不同 进一步调查,发现在2.6.11之前,PIPE_SIZE为4k,之后内核中PIPE_SIZE为64k,那为何能写入多达4G的字符呢? 
这时我想到了popen的源码,查看了popen在BSD的实现,除了使用pipe函数外,与system调用并无区别。

点我查看popen源代码

4)结论

依赖linux的pipe特性的程序并不是好的设计,非常容易出乱子(目前还未发生),最好还是老老实实地做内存越界判断,降低与系统的耦合性。

http://blog.csdn.net/judwenwen2009/article/details/44134415

by judwenwen2009

打赏
0 comment

You may also like

Leave a Comment

*

code

error: Alert: Content is protected !!