元芳：为什么在tcp_ipv4.c函数中用到了crypto_alloc_comp不打招呼开机直接卡住

SCDXMOE

各位高手大虾们：
我做的这个需求是：
在发送方在传输层 把数据给压缩之后在接收方解压 tcp头部不压缩
发送方做好了
我准备在接收方的tcp和ip的借口tcp_ipv4.c文件的tcp_v4_rcv（）函数 做解压处理用的是crypto_comp_decompress解压
所以解压我想分配一个中转的空间（我用了kmalloc）
先是因为kmalloc函数的flag不对造成奔溃http://bbs.chinaunix.net/thread-4058155-2-1.html
最后我排除这个问题之后还是出现奔溃
我开始怀疑我用到了tfm=crypto_alloc_comp("deflate",0,0);和crypto_comp_decompress 这个东西 我想在这个地方用是不是有什么禁忌......
故：我专门在tcp_v4_rcv（）函数中加了如下代码
tcp_v4_rcv（struct sk_buff *skb）
｛
......
struct crypto_comp *tfm;
tfm=crypto_alloc_comp("deflate",0,0);
crypto_free_comp(tfm);
｝
来测试：果不其然开不了机这是何道理？？ 元芳你怎么看.....

cool2003_cu

压缩数据为什么不在上层压缩好之后再交给协议栈？

SCDXMOE

谢谢cool2003_cu的回复
发送方是这样做的
接收方就要在解压之后交给tcp啊
回复 2# cool2003_cu


   

whaaat

crypto_alloc_comp-->crypto_alloc_base-->__crypto_alloc_tfm-->kzalloc(..., GFP_KERNEL)

SCDXMOE

whaaat感谢您的回复 您说得对  crypto_alloc_comp-->crypto_alloc_base-->__crypto_alloc_tfm-->kzalloc(..., GFP_KERNEL)
罪魁祸首就是kzalloc(..., GFP_KERNEL)的GFP_KERNEL  有是它....
怎么老和我过不去呢 这该怎么办.....哎
回复 4# whaaat


   

SCDXMOE

whaaat大侠您好：有没有办法避免kzalloc(..., GFP_KERNEL) 中的GFP_KERNEL呢？
我要用这个函数...该怎么办？？我前面做的所有工作都毁于一旦吗.....
期待您的回复
谢谢
回复 4# whaaat


   

justlinux2010

怎么修改tcp_v4_rcv还会导致开不了机？不太理解。内核崩溃的问题，建议使用kdump+crash来分析，要比猜好很多，能够清晰看到内核崩溃时的执行路径，还能看到崩溃时的日志信息。

whaaat

回复 6# SCDXMOE
这个标志是在代码中写死的，表明这个函数只能用作进程上下文，这个API我也没用过，只能提个建议：
1： 修改这个函数的代码，将GFP_KERNEL改为GFP_ATOMIC，重新编译内核。
2： 改用其他的压缩算法，如内核的lib\zlib_inflate lib\zlib_deflate


   

SCDXMOE

whaaat大侠：谢谢你的回复
就像你说的的“这个标志是在代码中写死的，表明这个函数只能用作进程上下文”
您的第一个建议“1： 修改这个函数的代码，将GFP_KERNEL改为GFP_ATOMIC，重新编译内核。”重新编译内核的话是不是
会出现其他的问题...？？？？
回复 8# whaaat


   

SCDXMOE

谢谢您的回复：
我以前尝试了使用kdump+crash来分析  
我的是ubutun10.10 一直配置不成功  不知道why？
可不可以给点相信的指点....感激不尽..



回复 7# justlinux2010