On 6/3/21 5:16 PM, Mike Christie wrote: > On 6/3/21 9:37 AM, Stefan Hajnoczi wrote: >> On Tue, May 25, 2021 at 01:05:51PM -0500, Mike Christie wrote: >>> The following patches apply over linus's tree or mst's vhost branch >>> and my cleanup patchset: >>> >>> https://urldefense.com/v3/__https://lists.linuxfoundation.org/pipermail/virtualization/2021-May/054354.html__;!!GqivPVa7Brio!P55eslnMW_iZkoTUZckwhnSw_9Z35JBScgtSYRh4CMFTRkSsWwKOYqY0huUfBfIPM8BV$ >>> >>> These patches allow us to support multiple vhost workers per device. I >>> ended up just doing Stefan's original idea where userspace has the >>> kernel create a worker and we pass back the pid. This has the benefit >>> over the workqueue and userspace thread approach where we only have >>> one'ish code path in the kernel during setup to detect old tools. The >>> main IO paths and device/vq setup/teardown paths all use common code. >>> >>> The kernel patches here allow us to then do N workers device and also >>> share workers across devices. >>> >>> I've also included a patch for qemu so you can get an idea of how it >>> works. If we are ok with the kernel code then I'll break that up into >>> a patchset and send to qemu-devel. >> >> It seems risky to allow userspace process A to "share" a vhost worker >> thread with userspace process B based on a matching pid alone. Should >> they have ptrace_may_access() or similar? >> > > I'm not sure. I already made it a little restrictive in this posting, but Made a mistake here. In this posting I did not make it restrictive and I was allowing any old 2 processes to share. So we would need something like ptrace_may_access if go this route. If we restrict sharing workers with the same owner, then I'm not sure if need anything.
