[PATCH] ntdll: Implement ProcessVmCounters for Linux.

[Ken Thomases]

On Mar 17, 2017, at 10:11 PM, Alex Henrie <alexhenrie24 at gmail.com> wrote:
> 
> So, I think Alexandre has been ignoring this patch because it only
> reports correct information for the current process, even though the
> Mac implementation has the same problem. I can think of a few ways to
> fix that:
> 
> 1. Do nothing if the handle passed to NtQueryInformationProcess is the
> handle of another process.
> 
> 2. Add a wineserver call such as get_process_unix_pid to get the
> process's Unix PID from its handle. Modify the Mac code to use
> task_for_pid and the Linux code to use /proc/%u/status.

task_for_pid() is essentially unavailable.  It has security implications, so Apple has put very severe restrictions on what processes can call it.

The wineserver has the Mach task ports for all Wine processes and your hypothetical call would have to inject the task port into the calling process rather than providing the PID.  Of course, that presents its own version of the same security concerns as task_for_pid(), although limited in scope to Wine processes.

For what it's worth, there have been other occasions when I've thought it would be useful to be able to get task and thread ports of other Wine processes.  For example, I have an implementation of using libunwind for StackWalk64() in dbghelp in a working tree, but it's limited.  It can only work on the calling process because it needs the task and thread ports.

> 3. Add a wineserver call such as get_process_vm_counters to get all
> the information that ProcessVmCounters needs without exposing the Unix
> PID. Move the Mac code into the wineserver and add the Linux code
> there too.

Because the wineserver has the task ports, this would probably be more sensible.

One concern is if programs call this very frequently, adding a wineserver call could add a lot of overhead.  I suspect that programs which call this frequently (if there are any) are probably calling it for themselves.  So, we'd want to skip the wineserver call in that case, although that would mean duplicating the code in case 3.

-Ken