Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Oops on HTTP parser error #8

Closed
krizhanovsky opened this issue Sep 8, 2014 · 2 comments
Closed

Oops on HTTP parser error #8

krizhanovsky opened this issue Sep 8, 2014 · 2 comments
Assignees
Labels

Comments

@krizhanovsky
Copy link
Contributor

If HTTP parser returns TFW_BLOCK (bad HTTP message), then we get Oops:

    [tempesta]   parser: Req_HdrDone(77:0): c=0xa(.)
    [tempesta]   request parsed: len=280 parsed=280 res=-2
    [tempesta]   Block bad HTTP request
    [sync_socket] Warning: can't process app data on socket ffff88003d152700
    [tempesta]   Close socket ffff88003d152700, conn=ffff88003d26e648
    ------------[ cut here ]------------
    WARNING: at net/core/stream.c:201 sk_stream_kill_queues+0xf5/0x11d()
    Modules linked in: tempesta_fw(O) tempesta_db(O) sync_socket(O) i2c_piix4 floppy
    CPU: 1 PID: 11 Comm: ksoftirqd/1 Tainted: G           O 3.10.10+ #7
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
     ffffffff8280d1d1 ffff88003dcd9828 ffffffff824d2d9c ffff88003dcd9868
     ffffffff82028e25 ffff88003d152700 0000000000000000 ffff88003d152700
     ffff88003d152858 0000000000000005 0000000000000000 ffff88003dcd9878
    Call Trace:
     [<ffffffff824d2d9c>] dump_stack+0x19/0x1b
     [<ffffffff82028e25>] warn_slowpath_common+0x62/0x7b
     [<ffffffff82028e53>] warn_slowpath_null+0x15/0x17
     [<ffffffff823b6559>] sk_stream_kill_queues+0xf5/0x11d
     [<ffffffff823f72ba>] inet_csk_destroy_sock+0x7c/0x107
     [<ffffffff823fa4e5>] tcp_done+0x74/0x79
     [<ffffffff8240c61f>] tcp_time_wait+0x1de/0x1ed
     [<ffffffff824038b8>] tcp_rcv_state_process+0x89a/0x9e2
     [<ffffffff824094e0>] tcp_v4_do_rcv+0x2a0/0x2e0
@krizhanovsky krizhanovsky self-assigned this Sep 8, 2014
@krizhanovsky
Copy link
Contributor Author

The problem is in WARN_ON(sk->sk_forward_alloc) in sk_stream_kill_queues() called from inet_csk_destroy_sock() which is called in turn from ss_do_close() of sync_socket. It seems we should call sock_rfree() for each freed skb which is linked with TCP socket.

@keshonok
Copy link
Contributor

keshonok commented Sep 8, 2014

My understanding is that sock_rfree()/sock_wfree() IS called automagically from kfree_skb() via skb->destructor. The only case it might not be called is when the SKB is shared and the memory is not actually released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants