[PATCH v4 2/2] server: Add USD support with timestamp updates.

[Alexandre Julliard]

Rémi Bernon <rbernon at codeweavers.com> writes:

> On 5/4/20 5:49 PM, Alexandre Julliard wrote:
>> Rémi Bernon <rbernon at codeweavers.com> writes:
>>
>>> @@ -1533,6 +1541,7 @@ void server_init_process_done(void)
>>>       signal_init_process();
>>>         /* Signal the parent process to continue */
>>> +    pthread_sigmask( SIG_BLOCK, &server_block_set, &old_set );
>>>       SERVER_START_REQ( init_process_done )
>>>       {
>>>           req->module   = wine_server_client_ptr( peb->ImageBaseAddress );
>>> @@ -1541,10 +1550,22 @@ void server_init_process_done(void)
>>>   #endif
>>>           req->entry    = wine_server_client_ptr( entry );
>>>           req->gui      = (nt->OptionalHeader.Subsystem != IMAGE_SUBSYSTEM_WINDOWS_CUI);
>>> -        status = wine_server_call( req );
>>> +        wine_server_add_data( req, user_shared_data, sizeof(*user_shared_data) );
>>> +        status = server_call_unlocked( req );
>>>           suspend = reply->suspend;
>>>       }
>>>       SERVER_END_REQ;
>>> +    if (!status) usd_fd = receive_fd( &usd_handle );
>>> +    pthread_sigmask( SIG_SETMASK, &old_set, NULL );
>>
>> It should be possible to use standard file mapping functions
>> (NtOpenSection, NtMapViewOfSection etc.) instead of adding custom
>> handling to the init_process_done request.
>>
>
> Well, there was actually an issue with the service implementation
> because it used standard section function to map the USD. The handle
> was allocated early and under some circumstances could collide with a
> console handle copied from a parent process. The details are a bit
> convoluted but it's also the reason behind Paul's recent mapping
> patches.

I see no reason that this would be an issue, unless you are leaking the
handle.

> With these patches, NtWriteFile should not be able to write to the
> section handle anymore, but the idea was also that maybe the USD
> should not use standard mapping functions to avoid such issues. Also,
> on Windows NtQueryVirtualMemory returns MEM_PRIVATE for the USD, where
> it would return MEM_MAPPED if a section is used (although unlikely
> that any application cares).

If it has to be MEM_PRIVATE we can use mmap(MAP_FIXED) to map it, but I
think it can still be a standard object.

-- 
Alexandre Julliard
julliard at winehq.org