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

RISC-V: Fix syscall_cp on riscv64/32 #3

Open
wants to merge 1 commit into
base: riscv-musl-1.1.20
from

Conversation

Projects
None yet
1 participant
@ddevault
Copy link
Collaborator

ddevault commented Dec 15, 2018

Thanks to Rich Felker for pointing out this error on the musl list. In
addition to fixing the labels, this loads the cancel flag with lw
instead of ld.

RISC-V: Fix syscall_cp on riscv64/32
Thanks to Rich Felker for pointing out this error on the musl list. In
addition to fixing the labels, this loads the cancel flag with lw
instead of ld.

@ddevault ddevault force-pushed the ddevault:fix-syscall_cp branch from 12563f9 to e33c15c Dec 15, 2018

michaeljclark pushed a commit to anarch128/riscv-musl that referenced this pull request Dec 21, 2018

fix race condition in file locking
The condition occurs when
- thread riscv#1 is holding the lock
- thread riscv#2 is waiting for it on __futexwait
- thread riscv#1 is about to release the lock and performs a_swap
- thread riscv#3 enters the __lockfile function and manages to grab the lock
  before thread riscv#1 calls __wake, resetting the MAYBE_WAITERS flag
- thread riscv#1 calls __wake
- thread riscv#2 wakes up but goes again to __futexwait as the lock is
  held by thread riscv#3
- thread riscv#3 releases the lock but does not call __wake as the
  MAYBE_WAITERS flag is not set

This condition results in thread riscv#2 not being woken up. This patch fixes
the problem by making the woken up thread ensure that the flag is
properly set before going to sleep again.

Mainainer's note: This fixes a regression introduced in commit
c21f750.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment