forked from zephyrproject-rtos/zephyr
-
Notifications
You must be signed in to change notification settings - Fork 0
WIP: HTTP server connection cleanup #4
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
Closed
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Change the TCP send_cb call to be done after we have received ACK to sent packet. This makes sure that any API user will have a proper connection cleanup done after the ACK. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
We currently terminate the connection from client immediately after sending the TCP response. This is too fast for the client which will re-send the final ACK many times. In order to make the connection shutdown more cleaner, terminate the connection AFTER we have received ACK to our HTTP response or after a timeout if the ACK is lost. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
jukkar
pushed a commit
that referenced
this pull request
Jun 22, 2020
This makes the gatt metrics also available for gatt write-without-rsp-cb so it now prints the rate of each write: uart:~$ gatt write-without-response-cb 1e ff 10 10 Write #1: 16 bytes (0 bps) Write #2: 32 bytes (3445948416 bps) Write #3: 48 bytes (2596929536 bps) Write #4: 64 bytes (6400 bps) Write #5: 80 bytes (8533 bps) Write #6: 96 bytes (10666 bps) Write #7: 112 bytes (8533 bps) Write #8: 128 bytes (9955 bps) Write #9: 144 bytes (11377 bps) Write #10: 160 bytes (7680 bps) Write #11: 176 bytes (8533 bps) Write #12: 192 bytes (9386 bps) Write Complete (err 0) Write #13: 208 bytes (8533 bps) Write #14: 224 bytes (9244 bps) Write #15: 240 bytes (9955 bps) Write #16: 256 bytes (8000 bps) Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
jukkar
pushed a commit
that referenced
this pull request
Nov 10, 2020
The _ldiv5() is an optimized divide-by-5 function that is smaller and
faster than the generic libgcc implementation.
Yet it can be made even smaller and faster with this replacement
implementation based on a reciprocal multiplication plus some tricks.
For example, here's the assembly from the original code on ARM:
_ldiv5:
ldr r3, [r0]
movw ip, zephyrproject-rtos#52429
ldr r1, [r0, #4]
movt ip, 52428
adds r3, r3, #2
push {r4, r5, r6, r7, lr}
mov lr, #0
adc r1, r1, lr
adds r2, lr, lr
umull r7, r6, ip, r1
lsr r6, r6, #2
adc r7, r6, r6
adds r2, r2, r2
adc r7, r7, r7
adds r2, r2, lr
adc r7, r7, r6
subs r3, r3, r2
sbc r7, r1, r7
lsr r2, r3, #3
orr r2, r2, r7, lsl #29
umull r2, r1, ip, r2
lsr r2, r1, #2
lsr r7, r1, #31
lsl r1, r2, #3
adds r4, lr, r1
adc r5, r6, r7
adds r2, r1, r1
adds r2, r2, r2
adds r2, r2, r1
subs r2, r3, r2
umull r3, r2, ip, r2
lsr r2, r2, #2
adds r4, r4, r2
adc r5, r5, #0
strd r4, [r0]
pop {r4, r5, r6, r7, pc}
And here's the resulting assembly with this commit applied:
_ldiv5:
push {r4, r5, r6, r7}
movw r4, zephyrproject-rtos#13107
ldr r6, [r0]
movt r4, 13107
ldr r1, [r0, #4]
mov r3, #0
umull r6, r7, r6, r4
add r2, r4, r4, lsl #1
umull r4, r5, r1, r4
adds r1, r6, r2
adc r2, r7, r2
adds ip, r6, r4
adc r1, r7, r5
adds r2, ip, r2
adc r2, r1, r3
adds r2, r4, r2
adc r3, r5, r3
strd r2, [r0]
pop {r4, r5, r6, r7}
bx lr
So we're down to 20 instructions from 36 initially, with only 2 umull
instructions instead of 3, and slightly smaller stack footprint.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
jukkar
pushed a commit
that referenced
this pull request
Jan 25, 2021
With classic volatile pointer access gcc something generates access instructions with immediate offset value, like str w4, [x1], #4 Such instructions produce invalid syndrome in HSR register when are trapped by hypervisor. This leads to inability to emulate device access in hypervisor. So we need to make sure that any access to device memory is done with plain str/ldr instructions without offset. Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
jukkar
pushed a commit
that referenced
this pull request
Oct 25, 2024
hci_packet_complete(buf, buf_size) should check whether buf_size is
enough.
For instance, hci_packet_complete can receive buf with buf_size 1,
leading to the buffer overflow in cmd->param_len, which is buf[3].
This can happen when rx_thread() receives two frames in 512 bytes
and the first frame size is 511. Then, rx_thread() will call
hci_packet_complete() with 1.
==5==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68
READ of size 2 at 0x000000ad81c2 thread T6
#0 0x5279b2 (/root/zephyr.exe+0x5279b2)
#1 0x4d697d (/root/zephyr.exe+0x4d697d)
#2 0x7ffff60e5daa (/lib/x86_64-linux-gnu/libc.so.6+0x89daa)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)
0x000000ad81c2 is located 2 bytes to the right of global variable
'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c'
(0xad7fc0) of size 512
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/zephyr.exe+0x5279b2)
Thread T6 created by T2 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x530192 (/root/zephyr.exe+0x530192)
#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22)
Thread T2 created by T1 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x530192 (/root/zephyr.exe+0x530192)
#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22)
Thread T1 created by T0 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x52f36c (/root/zephyr.exe+0x52f36c)
#2 0x5371dc (/root/zephyr.exe+0x5371dc)
#3 0x5312a6 (/root/zephyr.exe+0x5312a6)
#4 0x52ed7b (/root/zephyr.exe+0x52ed7b)
#5 0x52eddd (/root/zephyr.exe+0x52eddd)
#6 0x7ffff6083c89 (/lib/x86_64-linux-gnu/libc.so.6+0x27c89)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)
==5==ABORTING
Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is saved in case we need it later. Its purpose is to delay connection tear down so that we receive ACK to sent HTTP response before tearing connection down. Without this patch, the client re-sends several packets before believing that the connection is really down.