Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[HttpKernel] Resolve EBADP error on flock with LOCK_SH with NFS #52201

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

Merged
merged 1 commit into from
Oct 20, 2023

Conversation

driskell
Copy link
Contributor

Q A
Branch? 5.4
Bug fix? yes
New feature? no
Deprecations? no
Tickets Fix #52144
License MIT

When using NFSv3 (with rpc.statd with NLM) or NFSv4, or any other filesystem where flock is converted to fcntl, performing flock LOCK_SH due to a would-be-blocking LOCK_EX will trigger EBADP and return false, and bypass the cache lock, due to the lock file not being opened with read mode. This causes cache locking to not have any effect on these filesystems.

Changing the lock file open to w+ resolve this issue and makes cache locking effective on NFS and other similar filesystems which convert flock calls to fcntl.

As per fcntl documentation: In order to place a read lock, fd must be open for reading. In order to place a write lock, fd must be open for writing. To place both types of lock, open a file read-write.

When using NFSv3 (with rpc.statd with NLM) or NFSv4, or any other filesystem where flock is converted to fcntl, performing flock LOCK_SH due to a would-be-blocking LOCK_EX will trigger EBADP and return false, and bypass the cache lock, due to the lock file not being opened with read mode. This causes cache locking to not have any effect on these filesystems.

Changing the lock file open to w+ resolve this issue and makes cache locking effective on NFS and other similar filesystems which convert flock calls to fcntl.

As per fcntl documentation: In order to place a read lock, fd must be open for reading. In order to place a write lock, fd must be open for writing. To place both types of lock, open a file read-write.

Fixes symfony#52144
@carsonbot
Copy link

Hey!

Thanks for your PR. You are targeting branch "6.4" but it seems your PR description refers to branch "5.4".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

@carsonbot carsonbot added this to the 6.4 milestone Oct 20, 2023
@driskell driskell changed the base branch from 6.4 to 5.4 October 20, 2023 15:04
@fabpot fabpot modified the milestones: 6.4, 5.4 Oct 20, 2023
@fabpot
Copy link
Member

fabpot commented Oct 20, 2023

Thank you @driskell.

@fabpot fabpot merged commit c4558e7 into symfony:5.4 Oct 20, 2023
@fabpot fabpot mentioned this pull request Oct 21, 2023
@fabpot fabpot mentioned this pull request Oct 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[HttpKernel] Cache locking fails over NFS due to missing read on the lock file
4 participants