Skip to content

Preserve original fd blocking state in TLS I/O operations#1298

Merged
ranshid merged 1 commit intovalkey-io:unstablefrom
xbasel:restoreBlockingModeOnTls
Nov 21, 2024
Merged

Preserve original fd blocking state in TLS I/O operations#1298
ranshid merged 1 commit intovalkey-io:unstablefrom
xbasel:restoreBlockingModeOnTls

Conversation

@xbasel
Copy link
Member

@xbasel xbasel commented Nov 13, 2024

This change prevents unintended side effects on connection state and improves consistency with non-TLS sync operations.

For example, when invoking connTLSSyncRead with a blocking file descriptor, the mode is switched to non-blocking upon connTLSSyncRead exit. If the code assumes the file descriptor remains blocking and calls the normal read expecting it to block, it may result in a short read.

This caused a crash in dual-channel, which was fixed in this PR by relocating connBlock():
#837

@codecov
Copy link

codecov bot commented Nov 13, 2024

Codecov Report

Attention: Patch coverage is 44.44444% with 5 lines in your changes missing coverage. Please review.

Project coverage is 70.70%. Comparing base (2df56d8) to head (aa0db5c).
Report is 21 commits behind head on unstable.

Files with missing lines Patch % Lines
src/anet.c 44.44% 5 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##           unstable    #1298      +/-   ##
============================================
+ Coverage     70.69%   70.70%   +0.01%     
============================================
  Files           114      115       +1     
  Lines         63161    63185      +24     
============================================
+ Hits          44650    44678      +28     
+ Misses        18511    18507       -4     
Files with missing lines Coverage Δ
src/tls.c 100.00% <ø> (ø)
src/anet.c 73.23% <44.44%> (-0.87%) ⬇️

... and 26 files with indirect coverage changes

---- 🚨 Try these New Features:

@xbasel xbasel force-pushed the restoreBlockingModeOnTls branch from a2e1b22 to f69607a Compare November 13, 2024 16:11
@xbasel
Copy link
Member Author

xbasel commented Nov 13, 2024

Please note that timeouts are still not restored. Not sure we should worry about timeouts.

@madolson madolson requested a review from ranshid November 14, 2024 06:02
Copy link
Member

@ranshid ranshid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that the timeout is not the thing we should keep track of, however I wonder why we cannot just flag the connection with indication that it is blocked instead of going through the fcntl all the time?

@xbasel
Copy link
Member Author

xbasel commented Nov 18, 2024

I agree that the timeout is not the thing we should keep track of, however I wonder why we cannot just flag the connection with indication that it is blocked instead of going through the fcntl all the time?

Using an app-level flag adds complexity and risks desync with the kernel. fcntl is lightweight, reliable, and avoids duplication.

@ranshid
Copy link
Member

ranshid commented Nov 21, 2024

@xbasel can you please signoff your commit?

Also please elaborate more on the top comment. provide some example etc...

@xbasel xbasel self-assigned this Nov 21, 2024
This change prevents unintended side effects on connection state
and improves consistency with non-TLS sync operations.

Signed-off-by: xbasel <[email protected]>
@xbasel xbasel force-pushed the restoreBlockingModeOnTls branch from f69607a to aa0db5c Compare November 21, 2024 08:26
@ranshid ranshid merged commit b486a41 into valkey-io:unstable Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants