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

BUG in sock.c #2178

Closed
EvgeniiMekhanik opened this issue Jul 23, 2024 · 2 comments · Fixed by #2182
Closed

BUG in sock.c #2178

EvgeniiMekhanik opened this issue Jul 23, 2024 · 2 comments · Fixed by #2182
Assignees
Milestone

Comments

@EvgeniiMekhanik
Copy link
Contributor

11483.898309] [tempesta fw] Warning: frang: http_resp_code_block limit exceeded for 127.0.0.2: 2 (lim=1)
[11483.900427] [tempesta fw] Warning: frang: http_resp_code_block limit exceeded for 127.0.0.2: 3 (lim=1)
[11483.900431] [tempesta fw] Warning: response blocked: filtered out: 127.0.0.2
[11483.901084] [tempesta fw] Warning: response blocked: filtered out: 127.0.0.2
[11483.902606] [tempesta tls] Warning: Cannot send TLS alert 0:1, -9
[11483.903024] [tempesta fw] Warning: Close TCP socket w/o sending alert to the peer: 127.0.0.2
[11483.903667] ------------[ cut here ]------------
[11483.903994] kernel BUG at /home/evgeny/workdir/tempesta/fw/sock.c:517!
[11483.904472] invalid opcode: 0000 [#1] SMP NOPTI
[11483.904843] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G OE 5.10.35+ #298
[11483.905717] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[11483.906479] RIP: 0010:ss_send+0x2c4/0x320 [tempesta_fw]

I catch this BUG during testing #2139, but it seems that it is not problem in this branch. Test from tempesta-tech/tempesta-test@1f7290e http_resp_code_block_2 (reproduced only once)

@EvgeniiMekhanik
Copy link
Contributor Author

I reproduce this BUG on current master. Just run this test in the loop

@EvgeniiMekhanik
Copy link
Contributor Author

It seems we have two problems here:

  1. When we process response tfw_http_resp_process and catch error we call tfw_http_req_block we close client connection in this function. We can also receive FIN from the client during calling tfw_http_req_block and totally destroy connection. If we processing another response for this connection on other CPU we can catch a lot of bugs in different places.
  2. Another problem that after calling ss_conn_drop_guard_exit we call tfw_classify_conn_close immediatly even if connection still have reference counter, so if we call some frang functions for this connection on other cpu we catch a bug

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

Successfully merging a pull request may close this issue.

1 participant