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

[Rémi Bernon]

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.

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).
-- 
Rémi Bernon <rbernon at codeweavers.com>