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

Implement process_vm_readv and process_vm_writev for the same user only #158

Open
amscanne opened this issue Mar 25, 2019 · 6 comments
Open

Implement process_vm_readv and process_vm_writev for the same user only #158

amscanne opened this issue Mar 25, 2019 · 6 comments
Assignees
Labels
area: mm exported priority: p3 type: cleanup type: enhancement

Comments

@amscanne
Copy link
Collaborator

@amscanne amscanne commented Mar 25, 2019

(We can disregard the cases were cap_sys_ptrace is required)

@amscanne amscanne added type: cleanup type: enhancement exported priority: p3 platform: ptrace and removed platform: ptrace labels Mar 25, 2019
@prattmic prattmic added the area: mm label Apr 3, 2020
@prattmic prattmic removed their assignment Apr 3, 2020
@alexdesmet
Copy link

@alexdesmet alexdesmet commented Dec 10, 2020

Hi,

Just in case you need a real-world example, I have been troubleshooting this for the last couple of days:

I built a Nginx + PHP-FPM container to run Laravel apps on Google Cloud Run. We saw that some requests took very long to complete. Upon inspection, those requests returned a bigger payload then others and were chunked as separate tasks. The first part would complete almost instantly and then wait up until the PHP-FPM slowlog timeout. After that the second part of the response was delivered. If we set the timeout to 10s, it would takes that long for the page to load.

I ran the container locally and put the code on a cloud VM. Neither one showed the same symptoms.

I then strace'd the syscalls in gvisor and Cloud Run output this message:

Container Sandbox: Unsupported syscall process_vm_readv(0xf,0x3ede59f9c830,0x1,0x3ede59f9c840,0x1,0x0). It is very likely that you can safely ignore this message and that this is not the cause of any error you might be troubleshooting. Please, refer to https://gvisor.dev/c/linux/amd64/process_vm_readv for more information.

I believe that the PHP-FPM processes use this syscall to communicate with each other or the PHP-FPM master process. For the time being, we use strace as a MITM for all the syscalls coming from PHP-FPM in order to catch the unsupported one and report it instead of waiting for it to timeout.

@prattmic
Copy link
Member

@prattmic prattmic commented Dec 10, 2020

I then strace'd the syscalls in gvisor and Cloud Run output this message:

This message only appeared when running strace, if I understand correctly? strace itself actually uses process_vm_readv (with a fallback to PTRACE_PEEKDATA when it's not supported in gVisor), so this is expected and unrelated to your application.

@alexdesmet
Copy link

@alexdesmet alexdesmet commented Dec 10, 2020

Yes, that's right. Only when running strace I see the error in the Cloud Run logging. Thanks for clarifying. It's the only syscall I see that is unsupported according to the logs, so I'll look elsewhere. Still odd that putting strace in between resolves the issue.

@prattmic
Copy link
Member

@prattmic prattmic commented Dec 10, 2020

Still odd that putting strace in between resolves the issue.

I missed that part, it is odd indeed. To me that seems to suggest some sort of race condition for which strace is slowing things down enough to usually come out on the lucky side of.

@zkoopmans zkoopmans self-assigned this Apr 24, 2022
@fvoznika
Copy link
Member

@fvoznika fvoznika commented Apr 25, 2022

.Net debugger requires process_vm_readv to work. @impl, it would be great if you could share a repro case with us to make sure that .Net debugger works correctly once we implement process_vm_readv.

@impl
Copy link
Contributor

@impl impl commented Apr 25, 2022

Hi @fvoznika, I actually found that this was an error in their implementation (at least for createdump -- I think more substantial debugging with e.g. lldb requires a lot more work). I opened a PR at dotnet/runtime#67544 to fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: mm exported priority: p3 type: cleanup type: enhancement
Projects
None yet
Development

No branches or pull requests

6 participants